2026 年 4 月 23 日に公開されたこの記事で、Tim Deschryver は、1 か月にわたってエージェント型 AI を使い、あるプロジェクトを完全に一から書き直した経験を述べている。対象は Aspire でオーケストレーションされた、ASP.NET の API バックエンドと Angular のフロントエンドから成るもので、AI に何ができて何ができないかを学ぶためのサンドボックスとして作られた。彼の主張は、複雑なセットアップも終わりのないプロンプトの小技も必要ないというものである。彼の経験では、AGENTS.md ファイル、Agent Skills、仕様といったいくつかのプラクティスによって、エージェントの速度、品質、一貫性を劇的に向上させられるという。
彼は、このプロジェクトをバイブコーディングで作ったわけではないと明言している（バイブコーディング を参照）。そのやり方は長期的に問題を引き起こすと考えているからである。代わりに彼はロードサイクリングの比喩を用いる。AI はチームのために働く（スーパー）ドメスティークであり、開発者は依然としてチームリーダーとして戦略を定め、プロジェクトの方向性と品質に責任を持ち、自らゴールラインを越えなければならない。
要点
- 彼はエージェントを自由に動かす前に、プロジェクトの構造を自分で組み立てた。採用したのはバーティカルスライスアーキテクチャで、彼の見方では、ユースケースを分離することでエージェントの助けにもなる。
AGENTS.mdファイルは常にエージェントのコンテキストに含まれるため、一般的なガイドライン、プロジェクト構造、エージェントが使えるコマンドを記載すべきだとする。彼は、このファイルはエージェントに生成させることができ、定期的に見直すべきであり、新しい概念を導入した後にエージェントに更新を頼めば最新の状態に保てると述べている。また、繰り返し起きるミスや、データモデルの理解を助けるための Mermaid のデータベース図もこのファイルに追加した。- 彼はツールを問わず標準の
AGENTS.mdという名前を好み、彼の説明では Claude Code はこのファイルを読まないため、ツールごとに別々のコピーを持つのではなく、シンボリックリンクか@AGENTS.mdによる参照で結び付けている。 - スキルが
AGENTS.mdと異なるのは、関連があるときにだけ読み込まれる点であり、これによってコンテキストウィンドウを扱いやすい大きさに保てる。スキルはスラッシュコマンドとして必要に応じて呼び出すこともできる。彼は Angular と .NET の公式スキルに加え、生成される UI の一貫性を保つために必要だと感じた独自のデザインシステム用スキルを使った。その必要性は Claude よりも Codex のモデルで強かったという。 - 彼はほとんどの MCP サーバーを避けている。彼の経験では、MCP サーバーはエージェントのコンテキストウィンドウを肥大化させ、出力の品質を下げるからであり、同じタスクにはスキルや CLI ツールを好んで使う。
- 大きめの機能には OpenSpec を用いた仕様駆動開発を使った。OpenSpec は数文のプロンプトから提案、設計、タスクリストを生成した。小さな変更やバグ修正では、エージェントに直接プロンプトを与えた。大きめの機能で仕様がないと、エージェントは微妙な詳細を見落とすことが多く、余分な反復が必要になったという。代替として GitHub Spec Kit の名前を挙げている。
- Claude のモデルと Codex のモデルは、Claude のほうがデザインのタスクに優れている点を除けば同程度に有用だったとし、モデルを取り巻くツールをハーネスと呼んで、それは薄くなりつつあると考えている。彼が OpenCode を好むのは、モデルやプロバイダーを切り替えられ、ベンダーロックインを避けられるからである。
- 彼のワークフローは次のとおりである。OpenSpec で計画を生成し、エージェントに実装させ、機能テストを行い、重要なコードパスを入念にレビューする。その際、独自の UI コンポーネントなど一部の生成コードは、公開 API だけを確認するサードパーティの依存関係のように扱う。その後、git と GitHub のスキルを通じてコミットし、プルリクエストを作成する。
- 彼は、デリバリーサイクルが短くなるにつれて、より頻繁なチェックインとレビューが求められ、プロダクトオーナーやプロジェクトマネージャーの役割がより重要になると予想している。リスクが時間の不足ではなく、価値の低い機能の氾濫になるからである。
背景
著者は、自分は AI の専門家ではなく、これはプロジェクトの唯一の開発者としての自身の経験だと述べている。したがって、その推奨事項は比較に基づくものではなく、一人の人物による書き直しに基づいている。締めくくりの助言は、まずデフォルトのエージェントから始め、エージェントが同じミスを繰り返すようになったときに初めてこれらのファイルを追加すること、指示ファイルは特定のツールに依存しないように保ち、ツール間の違いはシンボリックリンクで橋渡しすること、そしてセットアップを継続的に見直すことである。彼は、エンジニアの役割が、プロダクトの責任を持ち続けながら、エージェントにガードレールを提供する方向へ移りつつあると見ている。