ハーネスエンジニアリング: エージェント優先の世界でCodexを活用する
(openai.com)- 内部ベータのソフトウェア製品を、手書きコード0行を固定制約として、Codex がアプリケーションロジック、テスト、CI設定、ドキュメント、オブザーバビリティ、内部ツールに至るまで記述した実験事例
- 空のgitリポジトリから始まったコードベースは、約5か月後に約100万行規模となり、3人のエンジニアがCodexを動かして約1,500件のPRを作成・マージした PRスループット
- エンジニアの主な仕事はコードを書くことではなく、環境設計、意図の仕様化、エージェントが信頼できる形で動けるようにする フィードバックループ の構築へ移行
- リポジトリ知識 は短い
AGENTS.md、構造化されたdocs/、実行計画、リンターとCIで管理され、UI・ログ・メトリクス・トレースはCodexが直接読んで検証できる アプリケーション可読性 へと転換 - スループット増加により、マージゲート の最小化と後続実行ベースの修正が実用的な選択となった一方、長期的な アーキテクチャ一貫性 と人間の判断のエンコードは依然として学習課題
手書きコード0行で作った内部ベータ
- 過去5か月間、内部ベータのソフトウェア製品を 手書きコード0行 で構築・公開する実験を実施
- 製品には内部の日常的な利用者と外部のアルファテスターがおり、リリース・デプロイ・障害・修正の流れを実際に経験している状態
- アプリケーションロジック、テスト、CI設定、ドキュメント、オブザーバビリティ、内部ツールに至るまで、すべてのコード行をCodexが記述し、手でコードを書く場合の約1/10の時間で構築できたと推定
- 人間が操縦し、エージェントが実行する
- 数週間以内に最終的に100万行規模となった成果物を公開する必要があり、そのためエンジニアリングチームの主業務はコード記述から、環境設計、意図の仕様化、フィードバックループ構築へ移った
空のgitリポジトリから開始
- 空のリポジトリの最初のコミットは2025年8月末に発生
- 初期スキャフォールドであるリポジトリ構造、CI設定、フォーマット規則、パッケージマネージャ設定、アプリケーションフレームワークは、既存テンプレートの一部の案内を受けたGPT-5利用のCodex CLIが生成
- エージェントがリポジトリで働く方法を案内する初期
AGENTS.mdファイルもCodexが作成 - システムを支える既存の人間作成コードはなく、リポジトリは最初からエージェントによって形成された
- 5か月後、リポジトリはアプリケーションロジック、インフラ、ツール、ドキュメント、内部開発者ユーティリティ全体で約100万行規模
- 3人のエンジニアがCodexを動かして約1,500件のPRを作成・マージしており、これはエンジニア1人あたり1日平均3.5件のPRスループット
- チームが現在7人のエンジニアに増えた後も、スループットは増加
- 成果物は出力のための出力ではなく、製品は内部のパワーユーザーを含む数百人の社内ユーザーが利用
- 開発過程全体を通じて人間はコードを直接貢献しておらず、手書きコードなし がチームの中核哲学
エンジニアの役割の再定義
- 人間が直接コーディングしないという制約は、システム、スキャフォールディング、レバレッジに集中する別種のエンジニアリング作業を導入
- 初期の進捗は予想より遅かったが、それはCodexの能力不足ではなく、環境が十分に仕様化されていなかったため
- エージェントは、高水準の目標に向かって前進するために必要なツール、抽象化、内部構造が不足した状態だった
- エンジニアリングチームの主な仕事は、エージェントが有用な仕事をできるようにすること
- 実際の作業は、大きな目標を設計、コード、レビュー、テストのような小さなビルディングブロックに分解し、エージェントにそのブロックを作らせ、それをより複雑な作業の足場にする深さ優先の方式
- 失敗時の解決策は「もっと頑張る」ことではなく、Codexが仕事を進めるために欠けている能力は何かを見つけ、それをエージェントが読んで従える形にすること
- 人間は大半をプロンプトでシステムと対話し、エンジニアが作業を説明してエージェントを実行し、その後PRを開かせる流れ
- PR完了プロセスでは、Codexはローカルで自身の変更をレビューし、ローカルおよびクラウドで追加のエージェントレビューを依頼し、人間またはエージェントのフィードバックに応答し、すべてのエージェントレビュアーが満足するまで反復する、Ralph Wiggum Loop に近い方式
- Codexは
gh、ローカルスクリプト、リポジトリ組み込みスキルのような標準的な開発ツールを直接使い、人間のコピー&ペーストなしにコンテキストを収集 - 人間がPRをレビューすることはできるが必須ではなく、時間の経過とともにほぼすべてのレビュー作業はエージェント間処理へ移行
アプリケーション可読性を高める
- コードスループットが増えるにつれて、ボトルネックは人間のQA能力へ移動
- 固定制約が人間の時間と注意だったため、アプリケーションUI、ログ、アプリメトリクス自体をCodexが直接読めるようにして、エージェント能力を拡張
- アプリケーションはgit worktreeごとに起動可能に構成され、Codexが変更ごとにインスタンスを1つ起動して操作できる構造
- Chrome DevTools Protocolをエージェントランタイムに接続し、DOMスナップショット、スクリーンショット、ナビゲーション操作用のスキルを生成
- Codexはこれによりバグを再現し、修正を検証し、UIの挙動を直接推論可能
- ログ、メトリクス、トレースは、特定worktree向けに一時的に存在するローカルオブザーバビリティスタックを通じてCodexに公開
- Codexはログとメトリクスまで含む完全に隔離されたアプリ版で作業し、その作業が終わると関連ログとメトリクスも削除
- エージェントはLogQLでログをクエリし、PromQLでメトリクスをクエリ
- 「サービス開始が800ms未満で完了することを保証」や「4つの主要ユーザージャーニーのどのspanも2秒を超えないことを保証」のようなプロンプトが実行可能なタスクへ変換
- 単一のCodex実行が1つの作業を6時間以上続けることも珍しくなく、その時間はしばしば人間が眠っている間
リポジトリ知識をシステム記録にする
- 大規模かつ複雑な作業でエージェントを有効にするうえで、主要な難題の1つはコンテキスト管理
- Codexに必要なのは1,000ページの指示書ではなく地図
- コンテキストは希少資源 であり、巨大な指示ファイルは作業、コード、関連ドキュメントを押し出し、エージェントが重要な制約を見落としたり、誤った制約を最適化したりする構造
- 過剰な案内は案内ではなくなる ので、すべてが重要になると何も重要でなくなり、エージェントは意図的な探索ではなく局所的なパターンマッチングにとどまりやすい
- 単一の巨大マニュアルはすぐに古くなり、古いルールの墓場となり、人間が保守しない魅力的な妨害物に変わる危険
- 単一の塊ファイルは、カバレッジ、最新性、所有権、相互リンクのような機械的検証が難しく、ドリフトが避けられない構造
AGENTS.mdは百科事典ではなく 目次 として扱う- リポジトリ知識ベースは、システム記録として扱われる構造化
docs/ディレクトリに配置 - 約100行の短い
AGENTS.mdがコンテキストに注入され、より深い真実の情報源を指し示す地図の役割を果たす - 設計文書は、検証状態とエージェント優先の運用原則を定義する中核的信念セットとともにカタログ化・索引化
- アーキテクチャ文書 はドメインとパッケージ階層の最上位地図を提供
- 品質文書は各プロダクトドメインとアーキテクチャ階層を等級化し、時間とともにギャップを追跡
- 計画は第一級成果物として扱われ、小さな変更には一時的な軽量計画を使い、複雑な作業は進捗状況と意思決定ログを含む 実行計画 としてリポジトリにコミット
- アクティブな計画、完了した計画、既知の技術的負債はすべてバージョン管理されて併置され、エージェントは外部コンテキストに依存せずに作業可能
- この構造により段階的公開が可能になり、エージェントは最初から圧倒されるのではなく、小さく安定した入口から始めて次にどこを見るべきかを学ぶ
- 専用リンターとCIジョブが知識ベースの最新性、相互リンク、構造の正確性を検証
- 反復実行されるドキュメントガーデニング用エージェントは、実際のコード動作を反映しない古くなった、またはobsoleteな文書を見つけて修正PRを生成
エージェント可読性が目標
- コードベース全体がエージェント生成物であるため、最優先の最適化対象はCodexの可読性
- 新しいエンジニアがコードを探索しやすくするのと同様に、人間のエンジニアの目標は、エージェントがビジネスドメイン全体をリポジトリ自体から直接推論できるようにすること
- エージェントの観点では、実行時コンテキスト内でアクセスできないものは事実上存在しない
- Google Docs、チャットスレッド、人の頭の中にある知識はシステムのアクセス対象ではなく、リポジトリローカルのバージョン管理された成果物であるコード、Markdown、スキーマ、実行計画だけがエージェントに見える対象
- Slackでチームがアーキテクチャパターンに合意していても、エージェントがそれを発見できないなら、3か月後に参加した新人に知られていない知識と同じ状態
- Codexにより多くのコンテキストを与えるとは、任意の指示を流し込むことではなく、エージェントが推論できるように正しい情報を整理して露出すること
- 新しいチームメンバーにプロダクト原則、エンジニアリング規範、チーム文化、絵文字の好みまでオンボーディングするのと同じように、エージェントにもこの情報を提供すれば、より整合した出力につながる
- 依存関係と抽象化は、リポジトリ内で完全に内在化され、推論可能なものを優先
- いわゆる「退屈な」技術は、合成可能性、API安定性、学習データ内での表現のしやすさから、エージェントがモデリングしやすい傾向
- 場合によっては、公開ライブラリの不透明な高レベル動作を迂回するより、エージェントが機能の一部を再実装したほうが安い
- 汎用
p-limitスタイルのパッケージを持ち込む代わりに、独自の map-with-concurrency ヘルパーを実装しており、これはOpenTelemetry計測と密接に統合され、100%のテストカバレッジを持ち、ランタイム期待と正確に一致する挙動 - エージェントが直接検査、検証、修正できる形でシステムをより多く引き込むほど、Codexだけでなく、同じコードベースで作業する Aardvark のような他のエージェントのレバレッジも増す
アーキテクチャと好みの強制
- ドキュメントだけでは、完全なエージェント生成コードベースの一貫性を維持するには不十分
- 実装を細かく管理せず、不変条件を強制することで、エージェントが基盤を弱めずに高速に公開できる構造
- Codexには 境界でデータ形状をパースする ことを要求するが、その方法まで規定するわけではない
- エージェントは 厳格な境界と予測可能な構造 を持つ環境で最も効果的なため、アプリケーションは堅牢なアーキテクチャモデル中心に構成
- 各ビジネスドメインは固定された階層セットに分かれ、依存方向と許容される接続は厳格に検証
- この制約はCodexが生成したカスタムリンターと構造テストによって機械的に強制
- 各ビジネスドメインでは、コードは
Types → Config → Repo → Service → Runtime → UIの固定階層に従って前方向にのみ依存可能 - 認証、コネクタ、テレメトリ、機能フラグのような横断的関心事は、
Providersという単一の明示インターフェースを通してのみ導入可能 - それ以外の依存は許可されず、機械的に遮断
- こうしたアーキテクチャは通常、数百人規模のエンジニアになるまで後回しにされがちだが、コーディングエージェント環境では、速度を維持しつつ腐敗とアーキテクチャドリフトを防ぐための初期前提条件
- 実運用では、カスタムリンター、構造テスト、小さな「好みの不変条件」集合でルールを強制
- 構造化ログ、スキーマと型名の命名規則、ファイルサイズ制限、プラットフォーム別信頼性要件をカスタムlintで静的に強制
- カスタムlintのエラーメッセージは、エージェントのコンテキストに修正指針を注入するよう設計
- 人間中心のワークフローではこうした規則は細かすぎたり制約的に感じられるかもしれないが、エージェント環境では一度エンコードしたルールが全体に同時適用される乗数となる
- 中央では境界、正確性、再現性を強く管理し、その内側ではチームまたはエージェントが解法表現に大きな自由を持つ構造
- 結果コードが人間のスタイルの好みと常に一致するとは限らないが、正確で保守可能で、将来のエージェント実行が読めるなら基準を満たす
- 人間の好みはレビューコメント、リファクタリングPR、ユーザー向けバグを通じて、文書更新やツールへ継続的にフィードバックされる
- ドキュメントが足りなければ、規則はコードへ昇格する
スループットが変えたマージ哲学
- Codexのスループットが増加するにつれ、既存のエンジニアリング規範のかなりの部分が逆効果になった状態
- リポジトリは最小限のブロッキング・マージゲートで運用
- PRは短く保つ
- テストのflakeは進行を無期限に止めるより、後続実行で処理することが多い
- エージェントのスループットが人間の注意を大きく上回るシステムでは、修正コストが低く待機コストが高い構造
- 低スループット環境では無責任になり得る方式だが、この環境ではしばしば正しいトレードオフ
「エージェント生成」の実際の範囲
- コードベースがCodexエージェントによって生成されるというのは、コードベース内のあらゆるものを意味する
- エージェントが作る対象
- プロダクトコードとテスト
- CI設定とリリースツール
- 内部開発者ツール
- ドキュメントと設計履歴
- 評価ハーネス
- レビューコメントと応答
- リポジトリ自体を管理するスクリプト
- 本番ダッシュボード定義ファイル
- 人間は常にループの中にいるが、以前より高い抽象化層で作業
- 人間は作業の優先順位を決め、ユーザーフィードバックを受け入れ基準へ翻訳し、結果を検証
- エージェントが苦戦した場合は、ツール、ガードレール、ドキュメントのどれが欠けているかを見つけるシグナルとして扱い、その修正もCodexが書けるようリポジトリへフィードバック
- エージェントは標準的な開発ツールを直接使い、レビューのフィードバックを取得し、インラインで応答し、更新をpushし、自身のPRをsquashしてマージすることも多い
自律性レベルを高める
- テスト、検証、レビュー、フィードバック処理、復旧がシステム内にさらにエンコードされるにつれ、Codexが新機能を最初から最後まで推進できる閾値を最近超えた
- 単一のプロンプトだけでエージェントが実行できる作業
- 現在のコードベース状態の検証
- 報告されたバグの再現
- 失敗を示す動画記録
- 修正の実装
- アプリケーションを直接操作して修正を検証
- 解決を示す2本目の動画記録
- PRを開く
- エージェントおよび人間からのフィードバックに応答
- ビルド失敗を検出して修正
- 判断が必要なときだけ人間へエスカレーション
- 変更をマージ
- この挙動はそのリポジトリ固有の構造とツールに大きく依存しており、同様の投資なしに一般化できると想定すべきではない状態
エントロピーとガーベジコレクション
- 完全なエージェント自律性は新たな問題も導入
- Codexはリポジトリにすでに存在するパターンを複製し、そのパターンが不均一だったり最適でなかったりしても反復する
- 時間が経つと、こうした反復はドリフトにつながる
- 初期には人間がこれを手動で処理し、チームは毎週金曜日、つまり週の20%を「AI slop」の整理に使っていた
- この方式はスケールしなかったため、「ゴールデンルール」をリポジトリに直接エンコードし、反復的な整理プロセスを構築
- ゴールデンルールとは、将来のエージェント実行に向けてコードベースを読みやすく一貫したものに保つ、意見の強い機械的ルール
- 例として、不変条件を集中化するため、手作りヘルパーより共有ユーティリティパッケージを優先すること
- 別の例として、データを「YOLO式」に探索するのではなく、エージェントが推測した形の上に偶然構築してしまわないよう、境界を検証するか型付きSDKに依存すること
- 定期的にバックグラウンドのCodexジョブがばらつきをスキャンし、品質等級を更新し、対象を絞ったリファクタリングPRを生成
- 大半のリファクタリングPRは1分以内にレビュー可能で、自動マージ可能
- このプロセスはガーベジコレクションのように機能
- 技術的負債は高金利ローンのようなもので、積み上げて後で痛みを伴って一括処理するより、小さく継続的に返済するほうがほぼ常に良い
- 人間の好みは一度捉えられると、すべてのコード行に継続的に強制される
- 悪いパターンは、コードベース全体に数日または数週間広がる前に、毎日捕捉して解消できる
まだ学習中
- この戦略はこれまでOpenAI内部の公開と導入段階まではうまく機能
- 実際のユーザー向けに実際の製品を構築することは、投資を現実に結び付け、長期保守性へ向かわせる役割
- 完全なエージェント生成システムでアーキテクチャ一貫性が数年にわたりどう変化するかは、まだ未知
- 人間の判断がどこで最大のレバレッジを生むのか、その判断をどうエンコードして累積効果を作れるかについても学習継続中
- モデルが時間とともにさらに有能になったとき、このシステムがどう進化するかも未解明
- 明らかになったのは、ソフトウェア構築には依然として規律が必要だが、その規律はコードよりスキャフォールディングにより強く現れるということ
- コードベース一貫性を維持するツール、抽象化、フィードバックループの重要性は今後も増していく
- 現在もっとも難しい課題は、エージェントが複雑で信頼できるソフトウェアを大規模に作り、保守できるよう支援する環境、フィードバックループ、制御システムの設計
- Codexのようなエージェントがソフトウェアライフサイクルのより大きな部分を担うほど、こうした問いの重要性はさらに増していく流れ
- 初期の学びは、どこに労力を投資すれば 何かをただ作れるのか を判断する助けになる資料
1件のコメント
Hacker Newsの意見
スループットがとんでもない水準だ。ベースラインを何に置くべきなのか気になる。エージェントコーディング以前は、エンジニアは通常どれくらいのPRを上げると期待されていたのだろうか。1日に2〜10件くらいだったのだろうか。
この6か月でソフトウェアがより良くなったと感じているのかも気になる。エンジニア数が同程度なら、主要なソフトウェアアプリの反復サイクルは5倍くらい速くなっていないとおかしいはずだが、そうは見えない。AIアプリは非常に速く変化しているが、そもそも新しい分野なのでその程度は予想の範囲内で、それ以外ではあまり実感がない
ここでは1,500件のPRで100万行なので、PRあたりの純増は約650行だ。PR全体が650行という意味ではなく、追加分から削除分を引いた純増が+650行という意味だ。
注意深い読者向けの問いがある。1年にFirefoxのコードベース1つ分だけ行数が増えるプロジェクトは、10年後にどんな姿になっているだろうか。行数はツールの冗長さについて何を物語り、プロジェクトの目的が明確に公開されていないという点は結果について何を示しているのだろうか。人が直接コードを書かない世界で、行数を気にする理由はあるのだろうか。コードベースがはるかに大きくなったら、トークン使用量はどうなるのか。LLMの利用が行数を爆発的に増やすことが確認されたなら、数か月使った後でコストのために再び手動コーディングへ戻ろうとするコードベースにとって、それは何を意味するのだろうか。
奇妙なことに、「エージェント」の用途の大半は別のAI製品を作るために使われている。またしても無限に亀が支えているような構造だ。もしかするとこれは「エージェント」の力というより、ハーネスという分野について多くを語っているのかもしれない
MS Officeを見ると最近は小さな変更が多いが、その大半はいらだたしい。たとえばWordのコメントで同僚を@タグするとフォーカスが消えるとか、Outlookの検索欄に入力するのに2回クリックしなければならないとか、Outlookモバイルの日付ピッカーが自分の空き時間と参加者の空き時間を表示していた機能を失ってしまったようなことだ。
だからスループットは多く見えるが、残念ながらうまく動いていた機能を壊している。または、OneDriveの検索ステータスバーが入力欄の周りをぐるぐる回るような、重要でもない部分に時間を使っている
書かれるコードの大半は自分が運転席に座って統制しつつ、AIはフロー状態を強化し、詰まった部分を取り除くために使う形だ。ツールには実際のコード生成は最小限だけやらせたい
この5か月、tsz[1]で同じ実験をしてきて、非常によく似た結論に達した。優れたアーキテクチャの分離を強制するためのハーネスがたくさん必要で、テストとCIも大量に必要だ。
tszを作っている目的は、AIで非常に大きなプロジェクトをどう進めるかを学ぶことだ。結局のところ、同じワークフローと姿勢は、UIのある顧客向け製品アプリを作る際にも活用できる。OpenAIは自動化されたブラウザテストや動画までワークフローの一部として活用しているように見える。モデルが良くなるにつれて、こうしたソフトウェア制作の方向性はいずれ筋が通るように思えるが、まだそこまでは行っていない。それでもOpenAIの曖昧な主張とは違って、成果物を共有して直接見ることはできる。
Lovableのように非常に高水準の自動化を提供するソリューションは、やや楽観的すぎて、多くの自動化テストと緊密に結び付いていない。
[1] https://github.com/tsz-org/tsz
自分がやってきたやり方と完全に重なる。Claude/Codexに、自分の作業を検証するための手段を与えるのだ。ブラウザ、スモークテスト、エンドツーエンドテスト、高忠実度のローカル環境といったものだ。
あらゆるコンテキスト、つまり課題追跡、ドキュメント、アイデア、計画、作業ログをリポジトリ内に置いている（https://github.com/shepherdjerred/monorepo/tree/main/package...）。
Claude/CodexにGrafana、Prometheus、Tempo、PagerDutyのようなオブザーバビリティツールへのアクセス権を与え、早期失敗、型安全性、境界でのパースといった優れたエンジニアリング指針に従わせている。
ただし、ホームラボではコストとCI負荷のため、まだ完全な自律性までは達成できていない
少し前に電子タバコ工場の労働者の動画を見た。コンベヤーベルトから電子タバコの束を手に取り、口にくわえて5秒ほど強く吸い、それから次の束をテストする。AIが書いたPRで数百行の変更を人間がレビューするのも、大して変わらない。
PRはそうではない。悪いPRが1つあるだけで事業に致命的になりうるが、悪い電子タバコが1つあっても通常はそうならないからだ。
また、ソフトウェアエンジニアがAIの出力をサンプリングしてみると、現時点の品質は製品に求める基準を一貫して満たしていないと考える。だからすべてのPRをレビューし、そのかなりの部分を修正しなければならない。
変更の影響範囲を制限できて、出力物がおおむね監督なしでも受け入れ可能になり、工場で回帰がないかだけ二重確認すればよい水準になれば、サンプリング方式は機能するかもしれない
この記事を書いた3人のエンジニアのうちの1人です。質問があれば答えられます
AI懐疑派ではありませんが、この記事の意図は疑わしいです。実際の製品、実際のユーザー、成長中の実際のチームを根拠にエージェントファーストのエンジニアリングについて大きな主張をし、実例のように見せていますが、何を作ったのかは言いも見せもしません。ほかのすべてのAI誇張記事と同じです
これは無限の計算資源と無限のトークンがあるときにしか機能しないはずです
$20プランを使った立場からすると、こういう純粋なエージェント式アプローチは不可能です。すぐに上限に達するし、結果も少なくなります
とてもうまくいった方法は、人間が書いたコードを参照として与え、それを拡張するよう指示することでした。全体構造を決め、アーキテクチャを設計し、コントローラ、サービス、モデル、コンポーネント、データベーススキーマ、認証方式のようなサンプルコードをいくつか書いて、LLMが注意を向け始める足場を持てるようにします
たいていは実装方法を詳しく書いたスタブを作ります。より高い抽象化レベルの疑似コードのようなものです。そのうえでLLMに実装を依頼します
失敗したら変更全体を巻き戻し、前の失敗を検出できるようにスタブを調整してから再試行するほうがよいことが多いです
あるいは変更をコミットして、新しい文脈で間違っている部分だけを扱わせます
最初からエージェント式で進めようとすると、結果と上限の両方でいつも失望します。1時間も経たないうちに上限に達することさえあります
月額$200にアップグレードすればもっと使えますが、私のようにヘビーに使う人間にとっても使用量は常に足りません
OpenAIパーティーにRSVPしたという理由だけで200倍の使用量をもらった人たちが、いまだにうらやましいです
またしても息つく間もない営業記事です。鉱夫にツルハシを売るようなものですが、金はどこにあるのでしょう？ Gitの上で互いに会話するチャットボットがコードの山を生み出して、実際に創造した驚くべき製品はどこにあるのでしょうか？ まったく見当たりません
こういう浮ついたブログ記事は、もう少し教育的であってほしいです
たとえば、そんなに強力だと主張するワークフローを実際にどう設定するのか、段階を追って具体的に実演してほしい
AI懐疑派ではありません。むしろ、本当に超能力があるなら見逃したくありません
新機能にはGherkinの機能仕様を書き、改善ではそれを更新し、リファクタリングでは触りません。PRにはこれらの名詞でラベルを付けます
push前フックで型チェック、lint、単体テスト、そのほか高速でスクリプト化可能な検証を回します
リポジトリ内にVitePressのサブサイトを作り、エージェントに保守させます。重要な原則やアーキテクチャなどを文書化します
すべてのページとYAMLフロントマターの説明を列挙するCLIコマンドを作り、エージェントがコンテキストウィンドウをあふれさせずに読むものを選べるようにします
ドメイン駆動設計とモノレポを使っています。ロジックはヘッドレス層に書き、層をアプリとして組み合わせます。エージェントは層の探索が非常に得意です
zod、またはその言語で同等のツールと、契約先行のAPI開発を使っています。個人的にはこの部分がいちばん気に入っていて、orpcを使っています
「code」という単一のスキルだけを作り、ライフサイクルを説明します。ワークツリーを開き、ほかのエージェントと衝突しないように
.envを設定し、未使用のポートなどを選びます。ここではDockerが有効です。機能ファイルを書いたり更新したりし、ここで仕様をすり合わせてから実装し、playwright mcpのようなもので検証し、push前のチェックを実行し、push後はレビューを待ち、片付けてからmainをfast-forwardマージします複数のエージェントが衝突せずにテストを実行できることを保証するにはtestcontainersが役立ちます
本当にスキルは1つだけです。残りはすべて文書にあります。コード行数という意味ではなく、「良いソフトウェアを作る」という意味でとても生産的に感じます
そのため、エージェントが問題にぶつかるたびに、検証ツールやスクリプトを使ってどう解決するかを尋ねました。監査プロセスの中で、そのようなツールも自分でコーディングさせました。その結果、今ではコミット検証用のルールが30個以上になっていて[2]、かなりうまく機能しています
[1] https://github.com/gildas-lormeau/rebuild-and-ruin（「デモ」モードを見るには、タイマーが終わるまで待てば大丈夫です）
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
初期にこれを試してみた。コードを書く前に、ChatGPT を「プロジェクトマネージャー」として使い、ハーネス全体をセットアップさせた。1週間後、ルール、アーキテクチャ、フレームワークの文書が140件以上できあがり、コードは0行だった
その後、別のツールでレビューさせたところ、評価は「完璧に安全な空の金庫」だった。ハーネスは非の打ちどころがなかったが、中には何も入っていなかった
ハーネスは重要だが、コードのリリースと並行して進めなければ、ただの虚構を書いているにすぎない