近ごろ話題の coding agents は、開発の景色をかなり変えつつあります。
coding agent とは、ざっくり言うと「人が細かく手を動かさなくても、コード生成や修正をやってくれるAI」のことです。以前なら数時間かかった実装を、プロンプトを少し書いて待つだけで、かなりのところまでやってくれる。これは確かにすごい。
元記事の著者も、実験を後回しにしていたところ、Codexに30分ほど説明したら数時間後には動く初版ができていたと書いています。ここだけ見ると、「もうエンジニア要らないのでは？」みたいな空気すら出てきそうです。正直、このスピード感はかなり痛快です。
でも著者は、そこで素直に「じゃあ業界全体も爆速になるはず」とは考えていません。むしろ、その見方に強い疑問を持っています。
著者の主張はかなり骨太です。
影響力のあるソフトウェアは、多くの人間の協力によって作られる。だから本当に難しいのは、コードを書くことよりも、人間同士が何を作るかで合意することだ、というのです。
これは新しい発想ではありません。
Fred Brooks の The Mythical Man-Month や、Gerald Weinberg の The Psychology of Computer Programming でも、すでに「ソフトウェア開発は人間のコミュニケーションの問題だ」と語られていました。要するに、コードは完成品ではあるけれど、その前にある議論、調整、合意、衝突のほうが本体だ、という見方です。
この指摘、かなり刺さります。
私たちはつい「コードを書くのが遅い」「実装が大変」と思いがちですが、実際の現場では「仕様が固まらない」「誰も本当の要求を正確に言えていない」「あの人とあの人で解釈が違う」といった話のほうが詰まりやすい。著者は、coding agents によってそこが露出したのだと言います。
agent が実装を肩代わりしてくれると、チームのボトルネックは変わります。
以前は「コードを書く人」が詰まりどころでしたが、いまはagent が理解できるほど正確な仕様を作ることが重要になる。たとえば：
つまり、**“何を作るべきか”を言葉にする仕事**が中心になるわけです。
著者は、これをかなり率直に「ボトルネックは management だ」と言っています。
ここは少しギクッとしますね。コードを書くより、決めるほうが大変。しかも決めるには、責任・優先順位・トレードオフまで含めて整理しないといけない。AIが進化すればするほど、人間の曖昧さが目立つようになる、というのはすごく納得感があります。
著者はここで Jevons Paradox（ジェボンズのパラドックス） を持ち出します。
これは、あるものが安く効率的になると、消費が減るどころかむしろ使う量が増えるという考え方です。
コードを書くコストが10倍下がったとしても、人はその分を単純に節約するわけではありません。
むしろ、
という方向に進みます。
ここで著者が言う
“Every vibe-coded product with 12 features is 11 features away from being great.”
という一文は、かなり本質的で笑ってしまいました。
要するに、機能はたくさんあればいいわけじゃない。むしろ削る力こそが大事だ、という話です。
個人的にも、これはとても重要だと思います。AIで機能を増やすのは簡単になる一方で、何を足さないかを決める難しさはむしろ増すはずです。
記事の中で一番重要だと思ったのが、この context の話です。
ここでいう context は、単なる「前後の文脈」ではなく、組織が共有している背景知識のことです。
たとえば：
こういうものは、実は文書に全部は残りません。
人間のチームは、会議の空気、Slack の雑談、深夜の障害対応、PRレビューの一言みたいなものから、少しずつ context を身につけます。これはかなり“空気を読む”に近い話です。
でも agent は、そういう暗黙の学習ができません。
prompt に書かれていないこと、ファイルに入っていないこと、ツールから取れないことは、基本的に持っていないのと同じです。だから、もっともらしいけれど少しズレた答えを出しやすい。ここはAIの強さでもあり、弱さでもあります。
著者は、agent でうまくいったときでも、実際には人間側が context を整備した結果だと見るべきだと言います。
つまり、agent が賢いというより、人間が事前に「わかる形」にしていたわけです。
ここが面白いところです。
著者は「人間は context を明文化するのが苦手だ」と言います。これ、すごくわかる。
わざわざ全部書いても読まれないし、書くのも面倒。結果、暗黙知のまま放置される。
そこで期待されるのが、逆に agent が context を読むのが異常に得意 だという点です。
PRコメント、closed issue、commit message、古い design doc、Slack の履歴まで全部読んで、そこから「このシステムはなぜこうなっているのか」を抽出してくれる。著者の会社 .txt では、まさにそういう仕組みを作っているそうです。
これはかなり面白い発想です。
人間が苦手な「読むのが面倒な膨大な痕跡」を agent が拾い、そこから知識ベースを作る。
たとえば、
といった説明を、あとから来た人や別の agent が使えるようにする。
これは、組織の「空気」を少しずつ文章化していく試みだと言えます。
ここで著者は、かなり重要な注意点も入れています。
Michael Polanyi の有名な言葉に
“We know more than we can tell”
があります。つまり、私たちは言葉にできる以上のことを知っている、ということです。
これ、現場感があります。
実際、ベテランが持っている感覚の中には、文書化しようとすると壊れてしまうものがある。
だから context を全部書き出すのは不可能で、agent が拾えるのもその一部にすぎない。著者も「完全回収ではなく、役に立つ出発点くらい」とかなり慎重です。ここは誠実だと思います。
記事の後半で著者は、かなり大胆だけど納得感のある結論に進みます。
次の10年を勝つ会社は、必ずしも最高のモデルや最高の agent 基盤を持つ会社ではない。
むしろ、少人数でも大人数でも、組織の認識を揃えながら高いアウトプットを出せる会社だ、と。
つまり、新しい moat（競争優位）は、技術そのものではなく組織の整合性にある、という話です。
これはかなり重要な視点です。
これまでのツール——IDE、version control、CI、microservices、devops——も、結局は「協力をやりやすくする道具」でした。でも実際には、道具が組織の弱さを消してくれるわけではなく、もともとの強さを増幅するだけだった。
良い組織はもっと良くなり、悪い組織はもっと速く壊れる。
agent はその増幅率がさらに大きい、と著者は見ています。
これは厳しいけれど、たぶん本当です。
小さなチームが agent と相性がいいのは、そもそも context が共有されやすいから。
逆に大きい組織では、context を維持する仕組みがないと、速く動けば動くほどズレも速く増えるはずです。
この文章のいちばん良いところは、coding agents を「開発者の代替」としてではなく、組織の知識を外に出す装置として捉えている点だと思います。
もちろん、agent がすべてを解決するわけではありません。
むしろ、
という、人間が一番苦手な部分が前に出てくる。
でもそこにこそ、本当の変化がある。私はそう思います。
「コードを書くのが速くなった」と聞くと、つい実装競争の話に見えます。
でも著者の見方では、もっと本質的なのは組織の記憶と合意形成をどう扱うかです。
この視点はかなり新鮮で、しかも実務に直結しています。派手さはないけれど、たぶんこちらのほうがずっと大きい。そんな記事でした。
