Mitate、余暇6週間で2990コミット

この開発記録は、プロダクトを単一のコードベースではなく物理的に分離した4つのリポジトリに分割するという意図的な判断から始まる。Mitateがアーキテクチャ方針、API契約、適合フィクスチャを保持し、mitate-agentが設計層、mitate-applicationが安全な実行、data-service-apiが共通のData Service API仕様と2つのデータベース実装を担う。AIが隣接層の内部に立ち入らないようにしたことが、各層を同時に作業できた理由のようだ。

契約優先の流れは、その分離を具体的な作業指示に変えた。9月28日のケイパビリティDM-0065では、契約改訂で36件のフィクスチャを追加し、次にApplicationが41ファイルを変更、続いてAgentが26ファイルを変更、その後71件のミューテーションテストと証拠監査が行われた。監査はきれいに通ったわけではない。62件が履行済み、5件が未履行、4件が証拠不足と記録され、監督AIは未検証項目を記録に残したまま条件付きで作業を受け入れた。確認しなかったことを書き残す習慣が、作業を終えたふりをせずにプロジェクトを進められるようにしている。

第二のパターンは並列セッションの活用だ。9月8日の契約v0.24.0の記録では、4つのOpusインスタンスが並列で起草し、続いて3つのSonnetインスタンスが並列で実装し、別のセッションがmitate-applicationでヘルスチェックCLIを先に着地させた。ここでの並列性はスケジューリングの工夫ではなく分離の副産物だ。著者はまた、最も厳しい制約はAIリソースの枯渇だったと述べている。週次クォータが1週間持たず、だからこそ役割別のモデル割り当てが重要だった。