著者：Mario Zechner — Pi-Mom 開発者、オープンソースゲームフレームワーク libGDX 創設者。独立開発者、テクニカルコーチ。近年は AI とエージェント型プログラミングに注力。
およそ一年前、ゼロからプロジェクト全体を構築できる coding agents が登場した。Aider や初期の Cursor のような先駆けはもっと前からあったが、それらは agent というよりアシスタントに近かった。新しい世代のツールは魅力的で、多くの人が趣味の時間を割いて、ずっと作りたかったが手が回らなかったプロジェクトを実装し始めた。
これ自体は何の問題もない。趣味で何かを作るのは本来楽しいし、たいていコード品質や保守性なんて気にする必要がない。新しい技術スタックを学ぶ良い方法でもある。
クリスマス休暇、Anthropic と OpenAI がいくつか特典を配り、人々を逃げ場のないスロットマシンに釣り込んだ。多くの人にとって、これが agentic なプログラミングの魔力を初めて体験する機会となり、コミュニティは急速に拡大していった。
今や、coding agents はプロダクションのコードベースにも入っている。十二ヶ月が過ぎ、これらの「進歩」の結果が浮き彫りになりつつある。以下は私の現時点での見方だ。
すべてが壊れている
これは伝聞に過ぎないが、ソフトウェアは確実に泥沼化している — 大規模サービスの稼働率でさえ 98% を割るのが当たり前になり、例外ではなく常態になりつつある。ユーザーインターフェースに現れるバグは、QA チームが見て見ぬふりをしているとしか思えないほどお粗末だ。エージェントが登場する前からこういう状態だったことは認めるが、私たちは深淵への転落を加速しているようだ。
企業の内部で何が起きているかは見えないが、噂は必ず漏れてくる。たとえば、報じられたAIが引き起こしたと疑われる AWS 障害。AWS はすぐに「訂正」を発表したが、その後こっそりと内部で九十日間のリセット計画を進めた。
マイクロソフトの CEO Satya Nadella は、マイクロソフトのコードのどれだけが AI で書かれているかを盛んに吹聴している。直接の証拠はないが、Windows は確実に劣化していて、マイクロソフト自身もそれを自覚しているようだ — このブログ記事を見ればわかる。
プロダクションコードの 100% を AI で生成していると主張する企業は、想像しうる最悪のものを納品し続けている。名前は出さないが、数 GB のメモリリーク、UI の描画崩れ、機能の完全な停止、クラッシュ — これは彼らが思っている品質の勲章ではないし、「agent に全部任せる」という白昼夢の良い広告でも決してない。
小道消息はますます増えている。大小さまざまなソフトウェア企業が、agentic なプログラミングで袋小路に追い込まれている — コードレビューなし、設計判断を agent に丸投げ、数え切れないほどの誰も必要としない機能を積み上げる。ただそれだけだ。
agent をどう使うべきでないか、そしてなぜか
私たちは基本的に、あらゆる規律と主導権を放棄し、その代わりに一つの依存を手に入れた — 最短時間で最多のコードを生成することが最高の目標で、結果は知ったことではない。
オーケストレーション層を構築し、自律的な agent 軍団を指揮している。Beads（AIエージェントオーケストレーションツール）をインストールし、それが基本的にアンインストール不可能なマルウェアであることに全く気づいていない。ネット上ではみんなそう言っている、それが正しい働き方だ、そうでなければお前は ngmi（not gonna make it — 負け組確定）。あなたは ralphing the loop している（vibing のもじり — agent に無限ループさせて自分は何もしない状態）。見ろよ、Anthropic が agent 群で C コンパイラを組み立てた。ちょっと問題はあるが、次世代の LLM がきっと直してくれる。なんと、Cursor が agent の群れでブラウザを組み立てた。もちろん、動作は不安定で、たまに人間がハンドルを回す必要がある。でも次世代の LLM がきっと直してくれる、約束する！分散型、分割統治、自律化、無人工場。ソフトウェアの問題は六ヶ月で解決する。SaaS は死んだ。うちのおばあちゃんが Clawn で自分専用の Shopify を作った！
もう一度言う。このやり方が、ほぼ誰も使っていないサイドプロジェクトには機能するかもしれない — あなた自身のものも含めて。本当にこの仕組みを、ゴミじゃなくて実際のユーザーがいるソフトウェアプロダクトで使いこなせている人がいるのかもしれない。
もしあなたがその人なら、脱帽する。だが、少なくとも私の周囲のコミュニティでは、これが本当に機能しているという証拠を一つも見つけられていない。もしかしたら私たち全員に技術的な問題があるのかもしれない。
ゼロ学習、ボトルネックなし、遅延露見 — 小さなミスの蓄積
agent の問題は、ミスをするということだ。これは正常だ。人間だってミスをする。機能的なバグであれば発見と修正は容易で、ついでに回帰テストを追加すれば得点になる。あるいはコードスメル — linter が検出できない種類のもの。使われていないメソッドが一つ増えている、謎の型が定義されている、あちらに重複コードがある。個別に見れば大したことない。人間が書くコードにもこういう小さなミスはある。
だが clanker（AIの奴）は人間ではない。人間は同じミスを何度かすれば、最終的には直す — 誰かに怒られて学ぶか、自ら真の学習の道を歩むかして。
agent にはこの学習能力がない。少なくとも、そのままでは。同じミスを何度でも繰り返す。学習データ次第では、小さなミスを素材にして、まったく新しいミスの変異体を生み出すことさえある。
agent を「教える」ことはできる。AGENTS.md に特定のミスをしないよう書いたり、過去のエラーとベストプラクティスを参照させる複雑な記憶システムを構築したり。これは特定のカテゴリのエラーには確かに効果がある — だが前提として、あなたが agent がそのミスを犯すのを目撃していなければならない。
人間と clanker の間には、もっと重要な違いがある。人間はボトルネックである。 人間は数時間で二万行のコードを吐き出すことなどできない。人間が高い頻度で小さなミスを作り出したとしても、一日にコードベースにねじ込めるミスの量には限界があり、複利的な増加スピードは非常に遅い。しかも通常、小さなミスによる苦痛が耐えがたいほど大きくなれば、人間は直しにかかる — 結局、人間は苦痛を嫌うからだ。あるいはその人が解雇され、別の人が後を引き継げば苦痛は消える。
agent の大軍に置き換えれば、ボトルネックは消え、人間の苦痛も消える。本来無害だった小さなミスが、突然、持続不可能な速度で雪だるま式に膨れ上がる。あなたは自分をループの外に置いたので、無垢な小ミスたちがコードの怪物に合流していることなど知る由もない。苦痛を感じた時には、もう手遅れだ。
そしてある日、新機能を追加しようとする。だがコードアーキテクチャ — この時点で基本的に小さなミスの山 — は、agent 大軍が正常に動作する方法で変更を行うことを許さない。あるいは、最新バージョンで問題が発生し、ユーザーデータが一部削除されたため、ユーザーがあなたに怒鳴り始める。
コードベースがもう信頼できないことに気づく。さらに悪いことに、clanker に書かせた数え切れない単体テスト、スナップショットテスト、エンドツーエンドテストも、同じく信頼できない。「これが動くかどうか」を確実に判断できる唯一の方法は、手動でプロダクトをテストすることだ。おめでとう、あなたは自分を掘った穴に落ちた（会社も一緒に道連れだ）。
複雑性の売人
あなたは何が起きているのか全く理解していない。なぜなら、すべての主導権を agent に渡したからだ。あなたはそれらを自由に走らせた — そして彼らは複雑性の売人である。彼らは学習データと強化学習の過程で、あまりにも多くのひどいアーキテクチャ決定を見てきた。彼らにアプリケーションアーキテクチャを設計させて、結果がどうなるか想像してみろ？
無数の複雑性。カーゴカルト式の「業界ベストプラクティス」が杂多に混ざったひどい代物。統制を取ろうと気づいた時には、手遅れだ。それだけではない。
あなたの agent は、互いの動作状況を決して見られない。コードベース全体を見られない。自分が変更を加える前に、あなたや他の agent が下したすべての決定も見られない。したがって、agent のすべての決定は局所的だ — これこそが前述の小さなミスの根源である。大量のコード重複、抽象化のための抽象化。
これらすべてが、最終的に取り返しのつかない複雑性の泥沼へと積み重なる。これは、人間が作り出したエンタープライズコードベースの悲惨な状況と全く同じだ — そういうコードベースが今日の状態に至ったのは、苦痛が膨大な人数に分散され、誰一人として「これを直さなきゃ」という閾値を超える苦痛を感じず、個人にはそもそも直す能力がなかったからだ。組織の苦痛に対する許容度は極めて高い。だがそういうコードベースでさえ、人間には数年かけてそこまで腐るのだ — 組織はある種の歪んだ協調方式で、複雑性とともにゆっくり進化し、共存する方法を少しずつ学んでいく。
agent と二人のチームがあれば、数週間で同レベルの複雑性に到達できる。
agentic search の再現率の低さ
さて、あなたは agent がこの混乱を修復し、リファクタリングで生まれ変わらせてくれると期待する。だが agent もお手上げだ。コードベースが大きすぎ、複雑性が高すぎて、彼らが見られるのは常に局所的なビューに過ぎない。
私が言っているのは、コンテキストウィンドウのサイズの問題や、百万行のコード怪物を前にした長コンテキストのアテンション機構の崩壊だけではない。そういうものは明白な技術的限界だ。問題はもっと根深い。
agent が混乱を修復しようとする前に、修正すべきすべてのコードと、再利用可能な既存コードを見つけなければならない。これは agentic search と呼ばれる。agent がどうやるかは、どのツールを持っているかに依存する。Bash ツールを与えて ripgrep でコードベースを検索させたり、コードベースインデックス、LSP サーバー、ベクトルデータベースを与えたり。最終的な結果はだいたい同じだ。コードベースが大きくなるほど再現率は下がる。そして低い再現率は、agent が必要なコードを実際には見つけられず、まともな仕事ができないことを意味する。
これこそが、コードスメルの小さなミスが最初から現れる理由でもある。agent が既存のコードを見落とし、車輪を再発明し、不整合を持ち込み、そしてそれらのミスが壮大な複雑性の花として咲き誇る。
では、どうやってこれらすべてを避けるのか？
agent をどう使うべきか（現時点での私の考え）
coding agents はセイレーンだ（Sirens — ギリシャ神話で歌声で船員を岩礁へ誘う魔物）。彼らはコード生成スピードと、ギザギザの知性（jagged intelligence）であなたを誘惑する。単純なタスクでは確かに驚異的な速度で高品質な結果を出す。あなたが「なんてこった、これ強すぎる、コンピュータ、仕事して！」と思い始めた時 — そこから事態は歪み始める。
agent にタスクを任せるのはもちろん問題ない。良い agent タスクにはいくつか共通の特徴がある。タスクの範囲が明確に定義でき、agent がシステム全体を理解する必要がない。ループが閉じている — つまり、agent が自分の仕事を評価する手段がある。出力がミッションクリティカルではなく、単なる一時ツールや内部ソフトウェアで、人の命や収入がそれに依存していない。あるいは、単にアイデアをぶつけるラバーダックが必要なだけ — 本質的には、自分のアイデアをインターネットの圧縮された知恵と合成された学習データに弾かせている。これらのどれか一つでも満たせば、agent の完璧なタスクだ — ただし、あなたが人間として最終的な品質の関門であることが前提だ。
Karpathy の auto-research を使ってアプリの起動時間を高速化する？素晴らしい！ただし、それが吐き出すコードがプロダクションレディではないことは理解しておく。auto-research が機能するのは、評価関数を与えることで、agent がある指標（起動時間や損失値など）で自分の仕事を測定できるからだ。だがこの評価関数は非常に狭い指標しか捉えない。評価関数自体に問題があれば、agent はそれが捉えていない他のすべての指標 — コード品質、複雑性、さらには正確性 — を喜んで無視する。
ポイントはこうだ。agent に退屈な仕事、あなたが新しいことを学べない仕事、あるいは、さもなければ試す時間がないようなアプローチを色々試させる。そして、あなたがその結果を評価し、本当に合理的で正しいアイデアを採用し、実装を完成させる。もちろん、この最後のステップも agent にやらせてもいい。
言いたいことはこうだ。くそったれ、減速しろ。それが正解だ。 何を構築しているのか、なぜそれを構築するのか、考える時間を自分に与えろ。「くそ、これ本当に必要ないな」と言える機会を自分に与えろ。毎日 clanker に生成させるコード量を、あなたが実際にレビューできる量を超えないように、自分に上限を設けろ。
システム全体の形を決定するすべてのもの — アーキテクチャ、API など — は自分の手で書け。Tab 補完で少しノスタルジーを感じてもいいし、agent とペアプログラミングしてもいい。コードの中に留まれ。自分の手でコードを書く、あるいはそれが一歩一歩組み上がるのを自分の目で見るという単純な行為が、摩擦を生み出す — そしてその摩擦が、あなたが何を構築したいのか、システムがどう「感じられる」のかをより明確に理解させてくれる。こここそが、あなたの経験とセンスが活きる場所であり、最先端のモデルでも未だに代わりできないものだ。減速し、摩擦を受け入れること — それこそがあなたを学ばせ、成長させる。
最終的な結果は、持続的に保守可能なシステムとコードベースになる。少なくとも、agent 時代以前の古いシステムと同じくらい保守可能だ。そう、それらも完璧ではなかった。あなたのユーザーは感謝するだろう。なぜなら、あなたのプロダクトは今や心地よいものであり、ひどい代物ではないから。あなたはより少ない機能を作るが、それらは正しい機能だ。ノーと言うことを学ぶこと、それ自体が一つの機能だ。
あなたはぐっすり眠れる。なぜなら、何が起きているのかをまだ理解しており、主導権を握っているからだ。まさにこの理解が、agentic search の低い再現率を補うことを可能にし、結果としてより良い clanker の出力を得て、より少ない手直しで済む。本当に事態が壊れたとしても、あなたは中に入って直せる。当初の設計が最適でなかったとしても、なぜそうなったか、どうすればより良いものにリファクタリングできるかを理解できる。agent がいようがいまいが、そんなことはどうでもいい。
これにはすべて、規律が必要だ。主導権が必要だ。
これにはすべて、人間が必要だ。