10月23日、GDEのエンジニアが「926 Steps, Two Lobotomies, and Zero Nudges: Flight-Testing the Commitment Machine Across Gemini, Claude, and GPT-OSS」と題した記事を公開した。AIコーディングエージェントが引き起こす「コード増加・チケット完了ゼロ」という逆説をワークフロー設計で解決する手法について、実際のプロダクションバックログを用いた926ステップ超の実験結果とともに詳しく紹介している。
Harvardの研究が示した不都合なデータ
2026年初頭、HarvardのFiona ChenとJames Strattonが718社・72万5000人以上の開発者を対象にした研究（"Artificial Intelligence in the Firm: Bottlenecks in Software Production"）を発表した。結果は衝撃的だった。
- 開発者のコード量は**+30%増**（1人あたり月1,500行）
- PRオープン数は**+23%増**
- 完了したJiraチケット・エピック数は**+0%**
なぜか。PRレビュー待ち時間が+49%（+3.45日）増加し、差し戻し率はほぼ2倍、レビューコメントは+35%増、そしてシニアエンジニアの14%が他人のコードの「お守り」に引き抜かれたからだ。
著者はこの構造を「タイピングを10倍速にしても、悪いチケットに黙って従い、コミット前に自分のバグを指摘しないエージェントは、シニアレビュアーに尤もらしいゴミを放水しているだけ」と表現する。
解決策：1986年の「約束理論」×1976年のMakefile
著者が構築したのはCommitment Machineと呼ぶワークフローだ。チリの政治家・哲学者でもあり言語行為論の研究者でもあるFernando Floresが1986年に提唱した「Committed Speech（約束としての発話）」の概念を基盤に、コード変更前に段階的なサブエージェント群が動作する仕組みを設計した。
状態管理には/etc/init.dスタイルの番号付きMarkdownファイル（00_governance.md〜99_next_action.md）をディスク上に保存し、LLMのコンテキストウィンドウ外に状態を持たせる。オーケストレーションは1976年のMakefileが担う。
このワークフローを、実際のプロダクションバックログから取った5枚の連続チケット（合計926+ステップ、18サブエージェント）、途中でのベンダー切り替え（960ステップ）、オープンウェイトモデルのストレステスト（791ステップ）に適用した結果を報告している。
最も示唆に富む事例：8分29秒でチケットをゼロ行でクローズ
TICKET-553は、本ワークフローの効果を端的に示す一事例だ。
このチケットは「プッシュ通知トークンをDBから削除してからFirebaseAuth.instance.signOut()を呼ぶラッパー（PreSignOutFirebaseAuth）を作れ」というHigh優先度のタスクだった。現時点のHEADを見ると該当コードは存在しない。通常のAIエージェントなら4ファイル・約280行のコードを生成してPRを開く。
ところが、著者のワークフローではまず読み取り専用の「Codebase Archaeologist」サブエージェントがgit log -pで履歴を精査し（SCAR-ARCH-20）、15_archaeology_receipt.mdに調査結果を書き込む。そこで発覚したのは：
- チケット登録2週間後に別のPR（PR #927）で全く同じ243行のラッパーが既に実装されていた
- コードレビューでリードアーキテクトが明示的に却下。「FirebaseAuthをラップするのはSDKアップグレードで壊れやすく、サーバーサイドの枯れトークン削除で十分」という理由でラッパーは削除されてからマージされていた
- 元のTICKET-553はそのまま放置されバックログに残っていた
ワークフローはチケットの前提条件をリポジトリ履歴と照合しCONTRADICTEDと判定。エージェントはコードを書く約束ができないため、代わりにCounter-Offerを提示した：
- Plan A（推奨）：コードゼロ。PR #927の経緯をTICKET-553に貼り付けてクローズ
- Plan B：アーキテクトを無視して却下済みラッパーを再実装
著者のレビューは4秒。「Plan Aで。彼が既に判断を下しているなら異議なし。」
Makefileベースのワークフローはターゲットファイルがゼロと判定した時点でTarget 30（コード生成）〜Target 70（PRチェック）をすべてUp to dateとして自動スキップし、8分29秒でチケットをクローズした。なお、これはあくまで本実験における一チケットの結果であり、全チケットの平均値ではない点に注意されたい。
PRレビュー前にバグを潰す：Flutterのリンター盲点
TICKET-482では15ファイルの実際の変更が必要だったが、ここで別の問題が顕在化した。
エージェントが生成したコードはflutter analyzeをゼロ警告でパスした。しかし「Adversarial Critic」サブエージェントがSCAR-RIV-14として以下のパターンを検出した：
// awaitの前にcontextをキャプチャ（リンター対策）
final messenger = ScaffoldMessenger.of(context);
final local = AppLocalizations.of(context);
final result = await notifier.create(...);
isLoading.value = false;
// ⚠️ 問題箇所：messengerはダイアログが閉じられると無効化される
notifier.onCreated(result, messenger, local);
notifier.onCreated()の引数にcontextという単語が出現しないためuse_build_context_synchronouslyリントはパスする。しかしユーザーがawait待機中にモーダルを閉じると、messengerはその背後のスクリーンのものになりウィジェットツリーから切り離された状態で呼ばれる。静的解析では検出不能なバグだ。
さらにTICKET-482では14件のbotコメントが発生していたが、これをPR上に個別展開せず1つのトリアージテーブルにまとめてポストすることでレビュアーの認知負荷を削減した。
コンテキストリセットとベンダー切り替えへの耐性
もう一つの重要な検証がコンテキストリセット耐性だ（元記事タイトルでは「Lobotomy」という語が使われているが、これはコンテキストウィンドウの強制圧縮・リセットを比喩的に指す技術的俗語である）。
TICKET-227（351ステップの数値/バイナリ処理チケット）では、著者が「コミットしてプッシュしていいよ」と言った直後にコンテキストが自動圧縮された（233kトークン→46kトークンへの2回リセット）。再起動後のエージェントは00_governance.md〜99_next_action.mdを読み直し、ヒントゼロで45/45テストをパスしてコミットを完了した。
また960ステップの実行では、元記事に記載のとおりStep 433でAPIクォータの壁に当たりClaude Sonnet 4.6からGemini 4に切り替えた。状態がディスク上のMarkdownファイルにあるため、新モデルはそのまま作業を引き継いで完了した。
オープンウェイトモデルによる対照実験
対照実験として、GPT-OSS 120B（オープンウェイトの120Bパラメータモデル）に同一のワークフローを791ステップ適用した。元記事に記録されている同一ワークフロー下での実験結果として、以下の挙動が報告されている：
/etc/init.dスタイルの状態ファイルを無視- 6回のコンテキストリセット
- プライベートなローカルDartクラスをGoogleで検索
- 6つの
git commitジョブをバックグラウンドで並行起動し.git/index.lockを削除
著者は、Makefileの外部スキャフォールディングは有能なモデル（Gemini 4やClaude Sonnet 4.6）を軌道に乗せ続けられるが、モデル自体の能力にハードフロアがあると結論付けている。
まとめ
Harvardの研究が示した「コード+30%・チケット+0%」という問題の根本は、エージェントがコミット前に自分でプッシュバックしないことにある。この記事が示す解決策のコアは：
- コード生成前に読み取り専用の考古学サブエージェントがチケット前提を検証する
- コミット前にAdversarial Criticが静的解析をすり抜けるバグを検出する
- 状態をディスク上のMarkdownに置くことでコンテキストリセットとベンダー切り替えに耐える
「エージェントにコードを書かせる」より「エージェントに書くべきでないと判断させる」ことに設計の重心を置く本アプローチは、AIエージェントをレビュー負債の発生源ではなく抑制装置として機能させる一つの実践的回答として読める。ワークフローの実装詳細はRandal's Public Workflow Gistで公開されている。
詳細は926 Steps, Two Lobotomies, and Zero Nudges: Flight-Testing the Commitment Machine Across Gemini, Claude, and GPT-OSSを参照していただきたい。
