この記事は、ソフトウェアエンジニアの役割が実装者から管理者へと移りつつあると論じ、その道筋上の 2 つの地点を名指しする。1 つは**指揮者（conductor）であり、特定のタスクについて単一の AI エージェントと密に作業し、リアルタイムでそれを操る。もう 1 つはオーケストレーター（orchestrator）**であり、複数の自律型エージェントに高レベルの目標を設定し、実装を独立して進めさせ、生み出されたものをレビューして統合する。この変化は、エンジニアが発する問いの変化として捉えられている。「これをどうコーディングするか？」から「正しいコードをどうやって作らせるか？」へ、である。
記事の大部分は、現在のツールを 2 つのモードに当てはめることに費やされている。CLI やエディタ内のアシスタントは指揮者のツールとして示され、そこでは開発者が各アクションを起動して出力をすぐにレビューし、やり取りはおおむね一過性のものである。リポジトリをクローンし、ブランチを切り、編集し、テストを実行し、プルリクエストを開くクラウドエージェントやバックグラウンドエージェントはオーケストレーターのツールとして示され、そこでは作業はチャットウィンドウ内の提案としてではなく、バージョン管理上のレビュー可能な成果物として届く。記事はその後、制御の範囲、自律性の程度、同期性、それぞれが残す成果物、そして開発者の労力がタスク全体にどう配分されるかという観点で、2 つのモードを直接対比する。
締めくくりとして、記事はオーケストレーターの役割を実装の先へと広げ、計画、コーディング、テスト、レビュー、ドキュメント作成、デプロイを担う専門エージェントのパイプラインへと拡張し、その規模での委任に伴う未解決の問題を示す。著者は、これが現在の実践の記述ではなく、向かっている方向であると明言している。
要点
- エンジニアの役割は実装者から管理者へ、「コーダーから指揮者へ、そして最終的にはオーケストレーターへ」と移りつつあると記述され、開発者は自らコードを書くのではなく、正しいコードを作るようエージェントを導くことが増えている。
- 指揮者モードは、1 つのエージェントとの緊密なフィードバックループとして特徴づけられる。同期的かつ対話的で、通常は IDE や CLI で行われ、開発者は各提案を確認または修正し、ブランチの作成、テストの実行、コミットメッセージの記述といった手作業のステップも依然として自ら行う。
- 指揮者モードのやり取りの大半は一過性のものとして記述される。セッションが終わると、コードに記録されなかったコンテキストや判断は失われうる。
- オーケストレーターモードは、リポジトリをクローンし、ブランチを作成し、複数のファイルを編集し、コンパイルしてテストを実行し、解決策を反復的に改善してから、通常はプルリクエストとして提示するだけの主体性を持つエージェントによって特徴づけられる。
- 記事は、オーケストレーターのワークフローは永続的な痕跡、すなわちバージョン管理上のブランチ、コミット、プルリクエスト（多くの場合 issue にリンクされる）を残すのに対し、指揮者スタイルの作業は、開発者が途中の変更をコミットしない限り明示的な記録をほとんど残さないと論じる。
- 2 つのモードは 5 つの軸で対比される。制御の範囲、自律性の程度、同期型か非同期型かのやり取り、成果物とトレーサビリティ、そして人間の労力の特性である。
- 労力の軸について、記事の主張は、指揮者はエージェントが作業している間ほぼずっと能動的に関与するのに対し、オーケストレーターの労力は前半（タスクの説明を書きコンテキストを整える）と後半（レビューとテスト）に集中し、その間はほとんど必要ないというものである。これこそが、1 人でより多くの作業を並列に管理できる理由だという。
- 自律型コーディングエージェントは、アセンブリから高水準言語へ、フレームワークやライブラリへ、AI による補完へと続く系譜における次の抽象化レイヤーとして位置づけられている。
- 記事は、これらの役割は固定的な区分ではなく流動的なものだと論じる。開発者は場面によって指揮者にもオーケストレーターにもなり、同時に両方として振る舞うこともあり、ツールもリアルタイムの協働と非同期の委任の両方をサポートすることでその境界を曖昧にしつつある。
- 計画、コーディング、テスト、コードレビュー、ドキュメント作成、デプロイまたは監視を担う専門エージェントからなる将来の「AI チーム」を描き、それを計画を承認し、衝突を解決し、デプロイの最終承認を与える人間が調整するものとしている。記事はこれを、すでに実現したものではなく、目前に迫っているものとして示している。
- オーケストレーターモデルの課題として挙げられるのは、品質管理と信頼、共有コードベース上でのエージェント間の調整と衝突、エージェント間で受け渡されないコンテキストと状態、仕様の質への依存、道を外れたエージェントのデバッグ、そして AI が書いたコードにおけるライセンス遵守とセキュリティの説明責任である。
- 記事は、出荷されるものに最終的な責任を負うのは人間のオーケストレーターまたはその組織であると述べ、AI が生成したコードのセキュリティスキャンや依存関係の検証といった実践を推奨している。
- 記事は、ソフトウェアエンジニアの最大 90% が何らかの AI をコーディングに使っているという主張から始まるが、その数値の出典は示していない。
- 一部の開発者は 1 日に 10 件以上のプルリクエストを AI に委任し、エージェントを賢いオートコンプリートではなく独立したチームメイトとして扱っていると報告している。これは測定データとしてではなく、早期採用者についての報告として示されている。
- 著者は、1〜2 年のうちにすべての、あるいは大半のコードがエージェント主導になるわけではないという明示的な留保を述べつつ、これが進んでいる方向であることは堅持している。
背景
この記事は、同じ変化についての著者の他の文章と並ぶものであり、大部分は総合である。新たな測定値を報告するのではなく、仕事の姿勢の変化を記述し、それに照らして現在のツールを読み解いている。個々のツールを特徴づける箇所では、引用された製品説明を含め、各ベンダー自身の位置づけに依拠しているため、どのツールが何をするかについての記事の説明は、独立した評価ではなく、そのベンダーの主張の言い換えである。
著者の 2 つの利害関係は、議論の読み方に関わる。記事の著者紹介では、Addy Osmani は Google で 14 年以上にわたり Chrome、そして後に AI の開発者体験を率いた後、Anthropic で Claude Code に取り組む Member of Technical Staff であると記されており、記事が取り上げるツールのいくつかはこの 2 社が作ったものである。また記事は、AI 支援エンジニアリングに関する著者自身の O’Reilly の書籍を宣伝している。
著者は生産性の議論と並べて、自らの注意も付け加えている。コードレビューのループこそが人間のスキルが引き続き発揮される場所であり、生成されるコードの量が粗悪なもの（slop）にならないようにするには、そこに手を入れる必要があるというのである。