10のエージェントは不要。2つのトラックで十分
著者は、2つのエージェント(仕様策定用と実装用)のみを使用する効率的なAIコーディングワークフローを提案。注意集中が必要な仕様策定と比較的自律的なコード実装を分離することで、1人で並行作業が可能になり、複数エージェントによるボトルネックを回避できる。
近年、AIコーディングエージェントの普及に伴い、多くの開発者が複数のエージェントを同時に実行して生産性を向上させようとしています。しかし、Hugo Baraúna氏は本記事で、10のエージェントは不要であり、2つのトラックがあれば十分だと主張しています。
同氏は、Elixir Radarニュースレターのバックオフィスシステムを構築した実際のワークフローを紹介しています。このシステムは、各号のキュレーションとアセンブル、メールプラットフォーム経由の送信、顧客によるスポンサーシップ管理を担当します。このワークフローでは、わずか2つのエージェントのみを使用し、それぞれ仕様定義とコード実装を担当します。
最初のトラックは仕様トラックです。曖昧な機能アイデアから始め、エージェントとのブレインストーミングを通じて、機能要件ドキュメント(PRD)と技術設計書を作成します。このプロセスではエージェントがコードベースを読み取り、開発者に質問を投げかけながら段階的に進めます。開発者の継続的な参加が必要ですが、出力されたドキュメントが次のトラックへの明確な指針となります。
2番目のトラックは実装トラックです。エージェントは仕様書と実装計画に基づいて自律的にコードを記述します。開発者はその間、次の機能の仕様策定を開始できます。実装中にエージェントがフィードバックを必要とする場合、開発者が介入し調整した後、再び仕様作業に戻ります。このサイクルにより、複数エージェントの並行処理に伴う管理の複雑さを回避します。
Baraúna氏は、なぜ2つのエージェントだけを使用するのかを説明しています。複数エージェント並行処理の核心的なボトルネックは人間の注意力であると指摘します。仕様トラックは継続的な注意を必要としますが、実装トラックは比較的自律的です。たとえ10の実装エージェントがあっても、仕様は1つずつしか提供できません。また、コード生成後もコードレビュー、機能テスト、UI改善といった人間の介入が必要なフェーズが存在します。これらのボトルネックではないフェーズを並行化しても、全体の速度は向上しません。
同氏は、ユーザーエクスペリエンス(UX)をエージェントに委任できないことも強調しています。エージェントはフロントエンドコードを実装しフルスタックに接続できますが、優れた製品を構築するための主観的な判断やセンスは開発者自身から生まれるものです。
このワークフローは、製品決定とコーディングの両方を担う「ビルダー型」開発者、例えば個人開発者、インディーハッカー、技術系創業者に最も適しています。開発チームのメンバーであっても、プロダクトマネージャーから完全に決まった仕様が渡されれば、それをエージェント向けの技術設計と実装計画に変換する必要があり、おそらく2トラック以上は扱えますが、10トラックには及びません。
Baraúna氏はまた、この厳格なワークフローは長期的に維持されるコードにのみ有効であり、使い捨ての実験的なプロジェクトでは、雰囲気コーディング(vibe coding)で十分だと述べています。この方法の実用性を示すため、彼は実際のプロダクションアプリに二重トラックワークフローを適用した未編集のエンドツーエンドビデオを録画し、使用ツール(Tidewave: PhoenixおよびRails向けのエージェント開発環境、Superpowers: 仕様策定と実装計画のためのエージェントスキル)も紹介しています。
最後に、同氏はこのワークフローが機能する理由を振り返り、それが偶然ではないと述べています。制約理論と待ち行列理論に基づくボトルネックの概念、かんばん方式の「開始をやめ、完了を始めよ」という原則、そしてプロダクトマネジメントコミュニティでMarty Cagan氏が広めた「デュアルトラック開発」の考え方が背景にあります。新しいツールは注目に値しますが、既存のエンジニアリング原理は依然として適用可能であり、エージェント駆動開発の世界に適応させることが重要だと結論づけています。