この記事は、コーディングエージェントを構築する人ではなく使う人の視点から、ハーネスエンジニアリング のメンタルモデルを示している。出発点は信頼の問題である。コーディングエージェントにより少ない監督で作業させるには、その結果への確信を高める手段が必要であり、著者は AI 生成コードには自然な信頼の障壁があると述べる。LLM は非決定論的であり、私たちのコンテキストを知らず、コードを本当に理解しているわけではない、というのである。記事は、著者がハーネスエンジニアリングについての第一印象を記録した以前のメモを更新し、それに取って代わるものだと述べている。
ハーネスとは AI エージェントのうちモデルそのもの以外のすべてである、という簡略な言い方を受けて、著者はこの用語をコーディングエージェントを使うという限定されたコンテキストに絞り込む。そのハーネスの一部は、構築者によってすでにエージェントに組み込まれている。ユーザーは自分のユースケースとシステムのために、独自の外側のハーネスを追加する。その外側のハーネスについての記事のモデルは ガイドとセンサー のシステムであり、記事はさらに、それらをいつ実行するか、何を制御するか、どのようなコードベースがそれらに適しているか、そして人間にどのような役割が残るかを論じていく。
要点
- よく構築された外側のハーネスは 2 つの目標に役立つとされる。エージェントが最初から正しく物事を行う確率を高めることと、人間の目に届く前にできるだけ多くの問題を自己修正するフィードバックループを提供することであり、それによってレビューの労苦が減り、システムの品質が上がり、無駄になるトークンも少なくなる。
- ガイド（フィードフォワード制御）はエージェントが行動する前にそれを方向づけ、センサー（フィードバック制御）は行動した後に観察して自己修正を助ける。著者の主張によれば、別々に使うと、誤りを繰り返し続けるエージェント（フィードバックのみ）か、ルールを組み込みはするがそれが機能したかどうかを決して学ばないエージェント（フィードフォワードのみ）になる。
- ガイドもセンサーも、実行の種類として 2 つがある。計算的なもの（テスト、リンター、型チェッカーのように決定論的で高速なもの）と推論的なもの（意味解析、AI によるコードレビュー、LLM-as-a-Judge）であり、後者はより遅く、より高価で、より非決定論的である。
- ユーザーのハーネスのエンジニアリングは コンテキストエンジニアリング の特定の形態であると説明され、コンテキストエンジニアリングがガイドとセンサーをエージェントに利用可能にする手段を提供する。
- 人間の仕事は、ハーネスを反復改善することでエージェントの舵を取ることである。ある問題が複数回起きるたびに、それが起きにくくなるよう、あるいは起きないよう制御を改善すべきである。ここでもエージェントが手助けできる。構造テストを書いたり、観察されたパターンからルールを起草したり、カスタムリンターの雛形を作ったりである。
- 継続的インテグレーションと継続的デリバリーを踏まえ、記事は品質を左に保つべきだと論じる。センサーはコストと速度に応じてライフサイクル全体に分散させるべきであり、高速なチェックはインテグレーションの前やコミットの前にさえ置き、より高価なもの（ミューテーションテストやより広範なコードレビューなど）はインテグレーションの後に置き、継続的なセンサーがコードベースの緩やかなドリフトや、劣化する SLO のようなランタイムのシグナルを監視する。
- 著者は 3 つの制御カテゴリーを区別する。保守性ハーネス（内部のコード品質。多くのツールが存在するため現時点で最も容易）、アーキテクチャ適合性ハーネス（アーキテクチャ特性のためのガイドとセンサーで、本質的にはフィットネス関数）、そして振る舞いハーネス（アプリケーションが機能的に必要どおりに振る舞うかどうか）であり、著者は最後のものを「部屋の中の象」と呼んでいる。
- 著者が以前にまとめたコーディングエージェントの失敗モードに保守性の制御を対応づけてみると、計算的センサーは構造的な問題を確実に捉え、LLM は意味的な判断を要する問題を部分的に、しかも高いコストをかけて捉え、誤診断、過剰設計、指示の誤解といった、より影響の大きい問題のいくつかはどちらも確実には捉えられないことがわかった。
- 振る舞いについては、エージェントに高い自律性を与えている人々の間で著者が最もよく目にするアプローチ、すなわちフィードフォワードとしての機能仕様と、フィードバックとしてのグリーンでカバレッジの高い AI 生成テストスイートおよび手動テストという組み合わせは、著者の見方では AI 生成テストを信頼しすぎている。
- すべてのコードベースが等しくハーネスに適しているわけではない。記事はこれを ハーネサビリティ と呼び、一般的なサービストポロジーのための ハーネステンプレート が将来登場するかもしれないと示唆している。
- 人間の開発者は自らのスキルと経験を暗黙のハーネスとして持ち込むが、コーディングエージェントにはそれが欠けている。ハーネスはそれを外部化して明示的にしようとするが、それにも限界がある。したがって、良いハーネスは人間の関与をなくすことではなく、それが最も重要な場所に振り向けることを目指すべきである。
- 記事が提起する未解決の問いには、成長していくハーネスの一貫性をどう保つか、指示とフィードバックが矛盾するときにトレードオフの判断をどこまでエージェントに任せられるか、一度も発火しないセンサーは品質の高さを示すのか検出の弱さを示すのか、そしてコードカバレッジやミューテーションテストがテストに対して果たしているのと同等の、ハーネスのカバレッジと品質を評価する方法の必要性が含まれる。
背景
著者はこのモデルを、すでに実践の中で行われている手法を記述するものとして、また、スキルや MCP サーバーのような個々の機能から、制御のシステムの設計へと議論を引き上げる手段として提示している。3 つの制御カテゴリーは「現時点で私には有用だと思える」ものとして示されている。現在の議論からの例として、著者は OpenAI のチームと Stripe が公開した記述や、Thoughtworks のチームの事例を挙げている。記事の謝辞には、調査、既存のメモからのアイデアの取り込み、そして文章の推敲に GenAI（Claude と Claude Code）が使われたと記されている。