技術要約：AIコーディングエージェントによる仕様優先の収束（Specification-First Convergence）
問題提起
本ケーススタディは、従来の増分的なリファクタリングでは不可能と判断される、大規模なアーキテクチャのリファクタリング・タスクを取り扱う。対象は、AIコーディングエージェント用のVS Code拡張機能として機能している、独自のクローズドソースのTypeScriptコードベース（3,648ファイル、717,725行）である。
具体的な課題は、コアとなる「生存期間の不変条件（lifetime invariant）」、すなわち「UIパネルはAIのリクエスト中、開かれた状態を維持しなければならない」という保証を解体することであった。目的は、ストリーミング生成中にパネルが閉じられても生成を継続させ、アクティビティサイドバー内でアクティブな状態を維持し、パネルを再開した際に、データの損失、重複、またはレースコンディションなしに、同一のライブストリームに再アタッチできるようにすることである。極めて重要な点として、このタスクには既存のテストオラクルが存在しなかった。すなわち、目標とする振る舞い（パネルを閉じた状態での生存）は以前は存在しなかったため、既存のテストスイートでは新しい実装の正当性を検証できなかった。さらに、このプロセスは生成されたコードに対する人間によるレビューなしで行われた。
手法：仕様優先プロトコル（The Specification-First Protocol）
本研究では、AIコーディングエージェント（OpenAI ChatGPT 5.6 Solモデルを実行）を用いた「仕様優先の収束」プロトコルを採用している。ワークフローは5つのフェーズで構成され、コード実行前に正当性に収束させるための2つの反復ループが含まれる。
- イデア（Ideation）: エージェントは自然言語によるリクエストを分析し、言語化された意図と制約を生成する。
- 仕様策定（Specification）: エージェントは、コードベース全体にわたる変更の詳細を示す形式的な仕様を生成する。
- 精緻化ループ（Refinement Loop - 14サイクル）: エージェントは、実際のソースコードに対して形式的な仕様を繰り返し監査し、欠陥、曖昧さ、または不足している依存関係を特定する。仕様は、仕様がソースに対して「検出事項ゼロ」となるまで修正される。本研究では14サイクルを要し、約85件の仕様エラーを修正し、対象範囲を110ファイルから160ファイルへと拡大した。
- 実装（Implementation）: エージェントは、凍結された（frozen）仕様に対してコードパッチを生成する。エージェントは原子性を維持するために部分的な変更の適用を拒否し、分解された実行計画を提案した。
- 検証ループ（Verification Loop - 17サイクル）: 新しいセッションのエージェントが、生成されたコードを（ソースコードではなく）凍結された仕様に対して監査し、アーキテクチャの逸脱や微細な欠陥を検出する。このループは、2回連続のパスで検出事項がゼロになるまで継続される。本研究では、17サイクルの過程で116件のコードの欠陥を修正した。
重要な設計上の選択は、関心の分離である。コードを書くエージェントと、それをチェックするエージェントは同一のセッションではない。むしろ、「チェッカー」は、生成前に作成・凍結された文書と比較を行う新しいインスタンスである。これにより、外部の参照対象を持たない自己修正によるバイアスを回避している。
主要な貢献と結果
- 変更の規模: 最終的なリファクタリングにおいて、189ファイル（新規31ファイル）に影響を与え、抽出およびリファクタリングのコミット全体で計288ファイルを変更した。変更内容は34,770行の挿入と16,422行の削除に及んだ。
- 欠陥除去: 合計31回の監査パス（精緻化14回 ＋ 検証17回）を通じて、プログラムが人間に実行される前に201件の欠陥が特定・修正された。
- 収束: プロセスは、2回連続の検証サイクルで検出事項がゼロとなった時点で、経験的に収束した。
- 機能的成果: 初回の手動実行時、システムは指定通りに動作した。パネルはストリーミング中に閉じたり再開したりすることができ、表示が復元され、損失や重複なくストリームが再開された。既存のユニットテスト・スイートにおける退行（リグレッション）は観察されず、ソフトウェアは約30回にわたるその後のセッションにおいてバグなしで動作している。
- 効率性: 仕様の精緻化、実装、および検証を含む全工程は、3日間で完了し、モデルの推論コストは2,430米ドルであった。
意義と主張
本論文は、AI支援エンジニアリングにおける制御が、事後的なコードレビューから、生成前（pre-generation）の仕様監査へと移行できることを示していると主張している。仕様を凍結された監査済みアーティファクトとして扱い、仕様をソースに、コードを仕様に適合させるための反復ループを用いることで、この手法は人間によるコードレビューなしに複雑なアーキテクチャ変更を達成した。
著者は、本手法を既存のパラダイムとは異なる特定の構成として位置づけている：
- SWE-bench とは異なり、本タスクは既存のテストオラクルに依存せず、振る舞いが存在しなかったために参照体（仕様）を構築する必要があった。
- Loop Engineering パターンとは異なり、本手法はユニットを分離できず、テストによって正誤を判別できない状況でも機能する。
- Bunの書き換え（Bun rewrite） とは異なり、本タスクには大規模な既存テストスイートが存在しなかった。
論文は、その限界についても明示している。これは、ツールの作成者による単一のコードベースを用いた単一のケーススタディであり、対照条件や独立した再現実験は行われていない。また、一般的な成功率や他のシステムへの再現性を確立すると主張するものではない。しかし、1,500ページを超えるセッションログと凍結された仕様を検証用に提供しており、仕様のソースに対する収束、およびコードの仕様に対する収束が、この種の「実行不可能」なリファクタリング・タスクに対する本手法の妥当性を証明していると主張している。