この記事は、AI コーディングエージェントがバックグラウンドで意味のある作業を行うこと — 隔離された環境で実行され、レビュー可能な成果物、多くの場合プルリクエストを返すこと — が増えるにつれて、ボトルネックは「エージェントはコードを書けるか？」から、「これを作るべきか？」と「それを行う複数のエージェントを効果的に管理できるか？」へと移ると論じている。記事は、その結果として生まれる姿勢を、小規模な並列コーディングエージェント群を走らせる「非同期ファーストのマネージャー」として捉え、優れたテックリードやエンジニアリングマネージャーを形づくるスキルはこれをうまく行うことにそのまま転用できると主張する。大規模な AI コーディングは、プロンプトの問題ではなくマネジメントの問題になるからである。
記事は、2 つのモードを並行して走らせるというメンタルモデルを示す。1 つは、アーキテクチャ上の判断、厄介なリファクタリング、プロダクトの微妙なニュアンス、曖昧な要件について開発者がヒューマン・イン・ザ・ループにとどまる、ローカルで手をかけるセッションである。もう 1 つは、単純な機能、明確なパターンのある移行、テスト生成、ドキュメントの更新、依存関係のバージョンアップ、対象を絞ったリファクタリングといった範囲の限られたタスクに対して非同期に実行される、クラウドまたはバックグラウンドのセッションである。
要点
- この変化を具体的に感じさせたのは、Claude Code の生みの親である Boris Cherny の話題となったスレッドだとしている。彼はローカルのターミナルタブで 5 つの Claude Code セッションを、ブラウザでさらに 5〜10 のセッションを走らせ、スマートフォンからセッションを開始して後で確認していると伝えられている。
- 並列コーディングエージェントを走らせる際の本来のボトルネックは、出力の生成ではなくそのレビューであり、並列タスクを次々と投げることの価値は、開発者が自分の注意力の持続について正直であり、それを過負荷にしないタスクを選ぶ場合にのみ成り立つ、という Simon Willison の見解を引用している。
- コーディングエージェントを指揮することにそのまま転用できると記事が主張する、4 つのマネージャースキルを示している。明確なタスクのスコープ設定（成果、コンテキスト、制約、非目標、受け入れ基準、統合上の注意点、検証計画を含むブリーフ）、委任（何を完全に任せ、何をチェックポイント付きで委任し、システムアーキテクチャやセキュリティ上重要な設計判断など何を人間の判断のために残すかを決めること）、検証ループの運用（テストスイートの出力、lint と型チェックの通過、振る舞いの変更に対するテストの追加、構造化された「PR パケット」を求めること）、そして非同期のチェックイン（決まった形式のステータス報告とチェックインの頻度。タイムゾーンをまたぐ分散チームの管理になぞらえられている）である。
- GitHub の Copilot コーディングエージェントは、ドラフトのプルリクエストを作成し、バックグラウンドで作業し、その後レビューを依頼する非同期のバックグラウンドエージェントとして位置づけられており、人間がコメントするとそれを受けて反復すると説明している。また、GitHub が複数のサードパーティ製コーディングエージェントを 1 か所で調整するコントロールプレーンとして「Agent HQ」をプレビューしたと報告しており、これには同じタスクで複数のエージェントを並列に走らせて出力を比較することも含まれる。
- Anthropic 自身による Claude Code のベストプラクティスのガイダンスに、次の主張を帰している。最初に具体的に指示することでエージェントの成功率が実質的に高まり、軌道修正が減ること。エージェントに既存のファイルパターンを示すと実際の規約に足場を置きやすくなること。1 つのエージェントにコードを書かせ、2 つ目のエージェントにレビューとテストで検証させることが、推奨される 2 人体制風のワークフローであること。さらに、OpenAI の Codex ドキュメントが、テスト、lint ルール、依存関係のポリシー、ドキュメントの要件についてエージェントに一貫した期待を与えるために AGENTS.md ファイルを推奨していることを引いている。
- 隣接するコードに触れる並列エージェントから生じるマージコンフリクトは、ツールの失敗ではなく境界設定の失敗だと論じ、Git ワークツリーと明示的なルールを組み合わせることを推奨している。1 つのエージェントが 1 つのプルリクエストを受け持ち、複数のエージェントから組み立てた巨大な PR は作らないこと、2 つのエージェントが同じファイルに触れる可能性があるならタスクの分割を設計し直すこと、共有インターフェースは人間が主導する最初のプルリクエストで扱い、エージェントはその上に構築すること、である。
- 作ることが安くなるにつれて、「作れるか？」よりも「作るべきか？」のほうが重要になり始めると論じ、マネジメントの実践から WIP 制限（同時に稼働するエージェントのストリーム数に上限を設ける）とキル基準（機能を作り切る前に中止するための事前に定めた条件）を借りることを推奨している。
- 著者自身の現在のセットアップとして、低〜中程度の複雑さの作業に 4〜5 のバックグラウンドエージェントを走らせつつ、アーキテクチャとプロダクトのニュアンスのためにさらに 3〜5 のローカルセッションでヒューマン・イン・ザ・ループにとどまっていると述べ、オーケストレーションのための反復可能なループを提案している。マネージャーのように計画し、オーケストレーターのように起動し、非同期で監視し、積極的に検証し、慎重に統合し、AGENTS.md とチェックリストを更新することで振り返る、というものである。
背景
記事は、誰もが 10〜15 のエージェントを同時に走らせる必要があるわけではないと明示的に注意を促しており、Boris Cherny のワークフローを、必須要件ではなく何が可能かを示す極端な例として提示している。記事は、オーケストレーションが主流になりつつあることについての著者自身の別の文章にリンクし、関連する読み物として著者の後年の記事 3 本を挙げている。最後に、AI 支援型およびエージェント型エンジニアリングのより包括的な解説として、著者の O’Reilly の書籍 Beyond Vibe Coding を読者に案内して締めくくっている。