正確性に計算リソースを投資せよ

AIエージェントを完全に採用した開発者にとって、生産性はもはやボトルネックではない。エージェントは人間よりも速く、しばしばより良いコードを生成する。真のボトルネックは正確性である：コードが問題を解決しているか、アーキテクチャが成長する機能セットを保持できるか、実装が正しい前提をコード化しているか。実際のシフトとして、エージェントの計算リソースのかなりの部分を、より多くのコードを生成するのではなく、検証（テスト、レビュー、スコープチェック）に充てるべきである。

1年前、エージェントプログラミングの主張はスループットだった：エージェントはより短時間でより多くのコードを出荷できる。これはもはや議論の余地がない。現在の世代のモデル（Claude Code、Codexなど）をエージェントハーネスで使用すると、1人の開発者が1つのエージェントを監督することで、手書きの小規模チームを凌駕する成果を上げられる。このワークフローに完全に浸っている人々にとって、問題は「どうやってより多く生産するか？」ではなく、「どうやって自分が生産したものが正しいと確信するか？」である。

正確性は3つの層で失敗する可能性がある。第1に製品層：コードはユーザーの望みに合致しているか？これは依然として人間の判断が必要である。実際のユーザーが実行中の製品を見て、本当に必要なことをしているかどうかを判断しなければならない。エージェントの計算でこれを代替することはできない。できる最善のことは、この人間の仕事を容易にすることである：実際の環境に素早く出荷し、実際のデータを提供して、人間が触って反応できるようにする。

第2にアーキテクチャ層：コードの形状は適切か？これは最も難しい層であり、現在のエージェントが最も弱い分野である。経験豊富なソフトウェアエンジニアが行う多くの作業はアーキテクチャ判断である：未来の機能に対応できるようにコードを構造化すること、どの機能を実装すべきでないかを知ること、機能セットが元のアーキテクチャを超えたときにコードベースを再形成する必要性を認識すること。エージェントはこれらのいずれも得意としない。要求された機能を最も適さない場所に追加し、次の3つの機能を難しくする抽象化を行う。要求された構成可能性を実装するが、本当に必要かどうかを問い直さない。前提を超えた構造を拡張し続ける。この層の対策は人間主導のアーキテクチャレビューであり、各差分をソースオブトゥルース文書と照合するエージェントが支援する。

第3に実装層：コードは主張通りに動作しているか？この失敗モードは最も見逃しやすい：コードは正しく見え、テストに合格するが、実際には間違っている。コード化された前提が少しずれている。テストが偶然実行しないワークアラウンドが中間にある。「エッジケースを処理する」ヘルパーが実際には伝播されるべきエラーを飲み込んでいる。これは作成エージェント自身が見ることができない失敗モードである。別のペアの目（レビューエージェント、新しいコンテキストのサブエージェント、またはまったく異なる種類のエージェント）が必要である。

対策は簡単に述べられるが、コミットするのは難しい：エージェント予算のかなりの部分を検証に充てる。コーディングエージェントのチームを運用する目的は、もはやより速くより多くのコードを生成することではない。コードが正しい可能性を高めることである。実際には、検証は複数のことを一度に意味する：テスト（高価なものも含む：実際のデータベースに対するエンドツーエンドテスト、Playwrightを使ったブラウザテスト、代表的なデータに対する実行）、コードレビュー（PR時だけでなく、アーキテクチャ文書とタスクリストをコンテキストに含むレビューエージェントが各差分を読む）、そしてスコープの再チェック（差分が元の要求から逸脱していないか、エージェントが静かにスコープを拡大していないか、SOTが明示的に禁止したことを実装していないか）。

検証を生産性への課税と見なすのは誤りである。検証された1つのコーディングエージェントの出力は、検証されていない2つのコーディングエージェントの出力よりも明らかに価値がある。

検証計算を展開するにはいくつかのパターンがある。これらは排他的ではない。

(1) 同じエージェント内のコードレビューサブエージェント。Claude CodeとCodexは両方とも強力なコードレビューサブエージェントを搭載している。作成者はタスクの途中でそれを生成し、ローカルフィードバックを得て適用する。バグ、欠落したエッジケース、スタイル違反を捕捉する。安価で簡単な最初のステップ。

(2) 異なる種類のエージェントによるレビュー。Claude CodeにCodexを生成させる（またはその逆）。異なる訓練、異なる事前知識により、わずかに異なるクラスの問題を捕捉する。機能するが、(1)と質的に近い。

(3) 永続的な専門レビューエージェント。重要なタスクごとに2つのエージェント：1人のプログラマーと1人のレビューアー。それらは永続化し、タスクリストを共有し、各TDDサイクル後にコミュニケーションする。著者が最も有用だと感じたパターンである。この記事のフレーミングでは、最も高いコンテキスト、最も高価で、最も有用な検証計算の形態である。

シフト：エージェントプログラミングの初期の主張は、注意の1時間あたりにより多くのコードを生成できるというものだった。それは今でも真実で有用である。しかし、すでにこのワークフローの中にいる人々にとってより重要な主張は、計算を正確性に費やせば、注意の1時間あたりにより多くの正しいコードを生成できるということである。ボトルネックは移動した。予算もそれに応じて移動すべきである。