終わってから確認するのではなく、やりながら確認する：実行中の継続的フィードバック

Test FirstとTrophy Testingにより、検証のアンカーとゲートが確立された。しかし、もう一つ時間軸の問いが残る。いつ検証するのか？

Agentがすべてのコードを書き終えるまで待ってからテストを実行すると、数十の失敗テストケースに直面する可能性があり、それぞれが異なる問題を指し示す。これらの問題の追跡と修正のコストは高い。なぜなら、エラーはAgentのagentic loopの初期段階で発生している可能性があり、その後のすべてのコードが欠陥のある基盤の上に構築されているからだ。

より効果的なアプローチは、実行中の継続的検証だ。Agentが小さなステップを完了するたびに、関連するテストを即座に実行する。テストが失敗すれば、逸脱が伝播する前にすぐに問題を修正する。これがred-green-refactorのインナーループだ。テストを書く（red）、テストをパスするコードを書く（green）、品質を維持するためにコードをリファクタリングする（refactor）、そして次のテストに進む。

継続的フィードバックの価値は、逸脱の生存時間を短縮することにある。第1章で分析したように、Agentは長い推論チェーンの中で初期の決定から徐々にドリフトしていく。逸脱がイテレーション5で発生してもイテレーション50まで発見されなければ、間の45イテレーション分のアウトプットをすべて破棄する必要があるかもしれない。逸脱がイテレーション5でテストによって検出され修正されれば、被害範囲は最小化される。

フェーズゲートは、より粗い粒度の継続的フィードバックだ。コーディングフェーズに入る前に、機械可読な受け入れ基準とTrophy Testの少なくともスケルトンが存在しなければならない。統合フェーズに入る前に、すべてのモジュールレベルのテストがパスしていなければならない。マージフェーズに入る前に、すべてのTrophy Testがパスしていなければならない。各フェーズゲートは明確な前提条件を定義し、Agentは条件を満たした場合にのみ次のフェーズに進むことができる。

いずれかのフェーズのテストで仕様の曖昧さやギャップが明らかになった場合、プロセスは仕様フェーズにロールバックする。コーディングを一時停止し、仕様を更新し、レビューで確認してから続行する。このロールバックメカニズムにより、問題は下流で回避策を講じるのではなく、根本で修正される。