この論文は、AI コーディングエージェントは実装を加速させる一方で、既存の仕様駆動アプローチでは完全には解決されないと著者が考える 2 つの構造的な失敗モードをもたらすと論じる。1 つ目はコンテキストの爆発である。範囲を限定しなければ、エージェントに関連するものをすべて与えることはリポジトリ全体を与えることを意味し、著者によれば、それによってエージェントは無関係なモジュールの関心事を混同し、変更を求められていない境界にまで手を入れるグローバルな修正を生み出してしまう。2 つ目は、仕様とコードの静かなドリフトである。開発者はコードを更新して仕様の更新を無期限に先送りし、テストは通り続け、乖離を指摘するものが何もないため、将来のエージェントの実行は古くなった仕様に導かれることになる。ドリフトについて論文は、この観察自体は新しくないと強調し、リフレクションモデルやアーキテクチャの侵食に関する先行研究を挙げている。そのうえで、新しいのはそのコストだと論じる。古い仕様から毎分数百行を生成するエージェントは、従来の開発よりもはるかに速く損害を蓄積するからである。
これに応えて提案されるフレームワークである Spec Growth Engine は、コードより前に完全な仕様を生成するスペックファーストのアプローチと、仕様からコードを生成するスペック・アズ・ソースのシステムとの間の、意図的に軽量な中間点として位置づけられている。著者によれば、後者は非決定性と脆い単一の真実の源をもたらし、チームは実際にはそれを拒否する。論文はこのエンジンを、5 つの連動するコンポーネント、すなわち仕様グラフ、コンテキストアセンブラ、ドリフトバリデータ、ガバナンスゲート、そして水平方向の再利用軸を提供するケイパビリティレジストリとして説明しており、それらは異なる権限を持つ 4 つのアクターによって運用され、定められた一連の成長ルールによって変更される。なお、論文の結論部の要約では、レジストリの代わりに垂直スライスの成長プロトコルがメカニズムの 1 つに数えられている。
論文はこの設計を新しいパラダイムではなく統合として提示し、各メカニズムを確立された起源に対応づけている。契約と設計の分離には情報隠蔽、ズームレベルには C4 モデル、アーキテクチャ決定記録（ADR）、垂直スライスには Walking Skeleton とトレーサーバレットのパターン、最難関優先の順序づけにはスパイラルモデル、ドリフト検証にはリフレクションモデル、自動チェックにはフィットネス関数、という具合である。そして貢献は統合レイヤーにあると主張する。すなわち、機械可読なアーティファクトとマージを阻止するゲートを通じて、日常的に使えるほど低いオーバーヘッドで、これらすべての性質を一度に強制する単一のフレームワークである。
要点
- コンテキストの爆発の根本原因はモデルの限界ではなくアーキテクチャにあると論じる。あるコンポーネントに取り組むエージェントが何を知ってよいかを定める境界がなければ、開発者はすべてを与える（高コストでノイズが多い）か、何が関連するかを推測する（脆く一貫性がない）かのどちらかを選ばざるを得ない。
- 実務者のヒューリスティックとその背後にあるエビデンスを区別している。論文は、コンテキストウィンドウの使用率がおよそ 40% を超えたら注意すべきだという、よく引用される経験則を紹介し、これはコーディングエージェントの実践から来た経験則であって、正確な値がモデルやタスクに依存する実証済みの閾値ではないと明言したうえで、根底にある性能劣化そのものは十分に裏づけられていると述べている。その教訓は数値的なものではなく方向性を示すものとしてまとめられている。すなわち、よく選ばれた少ないコンテキストは、多いコンテキストに勝る。
- 正反対の 2 つの失敗を防ぐための 2 層の成長ルールを提案している。レイヤー 1 は、ルートの不変条件と主要なコンテナ境界（永続化、セキュリティ、外部連携、エラー分類）を、あらゆる機能より前に、意図的にジャストインタイムではなく確定させる。レイヤー 2 は、それ以外のすべてを最難関優先の垂直スライスとして成長させる。著者は、幅優先の順序づけは難しい問題を最後までスタブの中に隠してしまい、一方で下限のない純粋なアジャイルでは、たまたまそれを強いる機能がなかったために必要な境界が一度も現れないことがあると論じている。
- フロンティアスタブを、実装の一種ではなく、位置とガバナンスの組み合わせとして定義している。技術的にはごく普通のプレースホルダーだが、現在のスライスのアクティブパスから外れた位置にあり、後続のスライスを名指しする明示的な例外として追跡されているからこそフロンティアスタブとみなされ、完成した作業と取り違えられることがない。アクティブパス上にある同じアーティファクトは、禁止された偽物となる。
- 情報隠蔽をエージェントのコンテキストに適用している。エージェントが受け取るバンドルは、ルートの不変条件、所有パスに沿った契約、そのノード自身の完全な仕様、そのノード自身のコード、そして宣言された依存関係の契約（1 ホップのみ）からなる。兄弟コンポーネント、依存先の設計とコード、推移的な依存関係、アドホックな検索結果は明示的に除外される。エージェントが何を読むかはアセンブラが決定し、エージェントが自由に検索することはない。
- 仕様とコードの整合を、規律ではなく構造的な性質にしている。エンジンは仕様ファイルから意図グラフを、静的コード解析からエビデンスグラフを導出し、孤立したコード、宣言されていない依存関係、契約を迂回する依存関係、依存関係の契約の欠落があればマージを完全に阻止する。より弱いシグナルは、マージを阻止しない警告として報告する。
- 3 段階のゲートレベル、すなわち人間の承認が必要、エージェントが進めて非同期にレビュー、人間は一切関与しない、を通じて、レビューのオーバーヘッドを影響範囲に結びつけている。その原則は、外部に向けた表面への変更は元に戻しにくいのに対し、内部設計への変更は局所的で元に戻せる、というものである。
- 4 つのアクターの間で権限を分離している。エンジンは決定論的で意図を作成せず、プランナーエージェントとコーディングエージェントは意図を作成するがゲートの対象となり、外部に向けた表面への変更を承認できるのは人間のアーキテクトだけである。著者は、この分離こそが、エージェントが同じコミットで仕様を更新することを安全にするものだと述べている。
補足
この論文は評価済みのシステムではなく設計提案である。実験、ベンチマーク、ユーザー調査は含まれておらず、その作業例は小規模な EC サイトのチェックアウト処理を仕組み全体にわたってたどるもので、メカニズムを測定するためではなく例示するためのものである。著者は、Spec Growth Engine は社内の設計文書群として維持されており、公開リリースが予定されていて、文書は著者に依頼すれば入手できると述べている。
2 つの限界が述べられている。この設計はソースファイルから導出可能な静的な依存関係グラフを必要とするため、実行時の依存性注入やプラグインアーキテクチャのような高度に動的なシステムでは、遅延束縛される依存関係を明示的に注釈する必要がある。また、ガバナンスゲートのオーバーヘッドは動きの速いチームにとっては現実の負担であり、中間のゲートレベルによって軽減されるものの解消はされないとされている。
著者はまた、エンジンをソフトウェアエンジニアリング知識体系に照らして位置づけ、仕様グラフをアーキテクチャと設計の領域に、ドリフト検証をテストと品質に、ガバナンスモデルをエンジニアリングマネジメントに、垂直スライスのプロトコルをプロセスに対応づけている。そして、この知識体系を、エンジンの位置づけを検証するための背景となる枠組みとして説明している。