数ヶ月かけて、コーディングエージェントを使って実際のソフトウェア開発を行うための、モデルに依存しないハーネスを構築しました。最終的に、機能面は思っていたほど重要ではありませんでした。実際に重要だったのは、エージェントに単にプロンプトを与えるのではなく、エージェントと 共に 構築する方法についての考え方を変えた、いくつかのアイデアでした。
これらが、最も重要なアイデアです。最初の3つは、私の思考モデルを根本から変えました。残りは、ほぼすぐに使い始められる実践的な内容です。
1. エージェントが作業を開始する前に、受け入れ基準を確定する
そして、エージェントが編集できない場所に置くこと。
おそらく、これが私にとって最大の変化です。後から考えると当然のことのように思えますが、実際に動いているところを見るまで、その重要性を本当に理解していませんでした。
作業が完了した後でも受け入れ基準が変更可能だと、それらは徐々に実際に生成された成果物に合わせて変化していきます。エージェントが不誠実なわけではなく、単にまだ動かせる目標に対して作業を評価しているだけです。ゴールポストが動かせるものであれば、結局は動いてしまうのです。
これはプロンプティングの問題ではなく、構造上の問題です。したがって、解決策も構造的なものでなければなりません。
最初に受け入れ基準を書きます。それらを編集可能なワークスペースの外部に保存し、編集しようとする試みを自動的にブロックします。そうすれば、エージェントは再交渉できない契約に向かって作業することになります。タスクが完了したかどうかは、エージェントが言うからではなく、元の契約を満たしたからです。
2. 誰も自分の作業を自分で評価するべきではない
コードを書いたモデルは、それが正しいかどうかを判断するのに最も不適切な評価者です。書き終える頃には、その解決策は理にかなっていると、すでに自分自身で確信しています。
そこで、責任を分割します。
機械的なことはすべて、決定論的なスクリプトに検証させます。スクリプトが成功の終了コードをでっち上げることはありません。コーディングモデルをレビュアーではなく、エンジニアとして扱います。そして、結果を 新しいコンテキスト のレビュアー、つまりコードが書かれるのを見ていないレビュアーに渡し、設計、意図、全体的な品質を評価させます。
この単純な分離だけで、予想以上に多くの問題を発見できます。しかも、驚くほど低コストで実現できます。
3. 強制は簡単。調整こそが難しい部分だ。
この気づきが、ハーネス全体に対する考え方を変えました。
ほとんどのエージェントシステムは、私の初期のバージョンも含めて、すべてのタスクをほぼ同じように扱います。1行のタイポ修正も、大規模なアーキテクチャの再設計も同じプロセスを経ます。これは時間の無駄か、リスクが高すぎるかのどちらかです。
鍵となるのは、比例した労力です。
まず作業を分類します。何にも依存しない小さな変更なのか、すべてが依存する中核的なインフラなのか。ビジネスロジックなのか、汎用的なユーティリティコードなのか。
次に、その分類に基づいて、どれだけのレビューを受けるか、どのモデルが処理するか、どの程度の自律性を許可するかを決定します。
強制を導入するのは簡単です。労力を一致させる ことこそが、価値が真に複利効果を生み出す部分です。
実践的なレイヤー
これらの大きなアイデアが整うと、いくつかの小さなプラクティスがすぐに効果を発揮しました。
- ルールはプロンプトではなく、ハーネスに記述する。「メインリポジトリを編集しないでください」というプロンプトは、単なるアドバイスに過ぎません。同じルールでも、ブロックされたツール呼び出しとして強制されれば、無視することは不可能になります。重要なルールは、モデルが従うことを選択することに依存するべきではありません。
- 状態を会話の外部に保持し、タスクごとに新しいワーカーを使用する。 タスクレコードを外部に保存し、分離されたワークツリーを使用し、変更をマージキューを通じて処理します。状態がチャットの外部に存在すれば、コンテキスト制限は最大の制約ではなくなります。タスクは並列化、再開可能になり、はるかに推論しやすくなります。
- プロバイダー間でのレビューは、同一プロバイダー内でのレビューよりも優れている。 モデルは他人の作品よりも自分の作品に寛大である可能性があります。異なるプロバイダーのモデルを使用することは、そのバイアスを減らすためのシンプルで効果的な方法です。
なぜこれらの原則が機能するのか
これらのアイデアは、特定のモデルに依存するものはありません。これらはハーネスエンジニアリング、すなわちプロトコル、検証、レビューパイプライン、責任の分離に関するものです。
ベンチマークのトップに立つモデルは常に変化し続けるでしょう。
しかし、原則はおそらく変わりません。
永続的な価値はモデルにあるのでも、機能にあるのでもありません。それは、それらの周りに構築する足場（スキャフォールディング）にあります。
