なぜ今のチーム構造はもう機能しないのか

従来のソフトウェアチームの典型的な構造は、テックリードが5～8人のエンジニアを管理するものだ。テックリードはタスクを割り当て、技術的な意思決定を行い、コードをレビューする。エンジニアは技術スタックで分けられる：フロントエンド、バックエンド、テスト、運用。各人のコアの仕事はコードを書くことだ。この構造は何十年もうまく機能してきたが、暗黙の設計前提のセットに支えられている。

第1の前提：人を増やせば出力が増える。もっと機能が必要か？エンジニアを追加する。出力は人数にほぼ線形にスケールする。第2の前提：テックリードのレビュー帯域幅がチームの出力をカバーできる。エンジニアは1日に数百行のコードを書く。テックリードは5～8人の出力をレビューし、ペースはおおよそ一致する。第3の前提：技術スタックによる分業は効率的だ。フロントエンドエンジニアはReactに集中し、バックエンドエンジニアはGoに集中し、テストエンジニアはテスト自動化に集中する。専門化が効率を生む。

エンジニアの仕事が「自分でコードを書く」から「Agentにコードを書かせる」に移行すると、3つの前提がすべて同時に崩壊する。

テックリードがボトルネックになる。各エンジニアが自分のAgent部隊を持ち、1日の出力が過去1週間分に相当するかもしれない。テックリードのレビュー帯域幅はそれに合わせてスケールしていない。5人のエンジニアがそれぞれのAgentを指揮して生産するコード量は、1人のレビュー能力をはるかに超える。結果として、レビューの品質が低下するか（形式的なスタンプ押し）、レビューがワークフロー全体のチョークポイントになるか（コードは書かれたがレビュー待ちの行列ができる）のどちらかだ。

技術スタックによる分業が意味を失う。エンジニアとAgentの組み合わせはスタックを横断して作業できる：午前中にバックエンドAPIを書き、午後にフロントエンドページを書き、夕方に統合テストを書く。Agentは技術スタックに制約されない。どの言語やフレームワークでも出力速度は同じだ。技術スタックで引かれた専門化の境界はAgent時代に溶解する。

従来のプロセスが足かせになる。Four-eyesコードレビューはすべてのコードに2人のレビュアーを要求する。Agentが1日で機能を完成させても、2人のレビュアーの調整に3日かかる。変更承認委員会は週1回しか開かれない。Agentは1日に10回デプロイできる。手動デプロイと手動テストという、人間の実行速度に合わせて設計されたプロセスが、Agent速度では積極的な障害となる。

品質の説明責任に空白が生まれる。従来のチームでは、コードを書いた人がそのコードに責任を持つ。Agent時代では、エンジニアは「Agentが書いた」と言い、テックリードは「レビューが追いつかない」と言う。Agent自体には説明責任の能力がない。コードの品質責任の帰属が組織内で明確なオーナーを持たなくなる。