コードを書く人より先にレビューする人を採用せよ:エージェントがコードを書く時代のスタートアップのエンジニアリングチームの作り方(2026)

エージェントによる大量のコード出力が、シニアだけがレビューできる狭い地点で絞られ、mainへの中央値のスループットが下がっていることを示す漏斗図

LinkedInでは決着のつかない議論が続いていて、Redditではもっと静かな議論がすでに決着しています。LinkedInの議論は、AIがエントリーレベルのエンジニアの仕事を奪ったかどうかです。一方にはジュニアをAIで置き換えるという考えを「これまで聞いた中で最も愚かなことの1つ」と呼んだAWSのCEOマット・ガーマン氏がいて、もう一方にはエントリーレベルの求人が急減していることを示す大量の採用データがあります。Redditの議論は、r/ExperiencedDevsのようなスレッドで、もっと現実的です。シニアたちは、1日がレビュー待ちのプルリクエストの途切れない列になったと語り、Indeedの社内メモには、シニアエンジニアはもはやシニア未満の誰かを指導することを期待されていないと書かれています。

最初の3人のエンジニアを採用しようとしている創業者にとって、どちらの議論も形がずれています。役に立つ問いは、AIが全体としてジュニアの仕事を壊しているかどうかではありません。エージェントがすでにコードの大部分を書いている今、プロダクトの出荷速度を実際に制限しているのは何か。そして、それを解消するには誰を採用する必要があるのか。これについてのデータは珍しいほど明確で、多くの創業者が予想しない場所を指しています。

すべてを捉え直させる数字

CircleCIの2026年のデータには、すべての創業者の机の上に貼っておくべき結果があります。機能ブランチのスループットは前年比59%増えた一方で、中央値のチームのmainブランチのスループットは低下したのです。かつてないほど多くのコードが書かれています。それでも比率で見ると、本番に届くコードは減っています。

開発者単位の数字が、その仕組みを説明します。AIを使うエンジニアは完了したタスクが21%増え、マージしたプルリクエストは98%増えました。アウトプットはおよそ2倍です。しかしPRのレビュー時間は91%増えました。AIが生成したPRは、レビュアーが手を付けるまでに4.6倍長く待たされます。いったんレビューが始まれば約2倍速く終わり、一見よい知らせに聞こえますが、それが意味することに気づくと話が変わります。遅いのはレビューそのものではありません。待ち行列 なのです。作業は、承認できるだけの文脈と権限を持つ人を待って止まっているので、サイクルタイムはほとんど改善しません。

ボトルネックが移ったと言われるのは、このことです。ソフトウェアの歴史全体を通じて、制約はコードを書くことでした。今はもう違います。制約は、コードをマージしても安全かを判断することであり、その判断はチームに均等に分配できるものではありません。ただし教えることはできます。AIの出力を評価し、どの失敗パターンを探すべきかを知ることは、私たちのエンジニアリングチーム向けトレーニングで扱う内容の大部分です。

スタートアップに最も強く響く理由

大企業はレビューの滞留を既存の階層の中で吸収できます。4人のスタートアップには、中核システムへの変更を意味のある形で承認できる人が1人か2人しかいません。その人たちにエージェントの能力を買い足しても、出荷速度は上がりません。待ち行列が長くなるだけです。

判断は並列化できない

このボトルネックがしつこい理由は、エージェントの出力をうまくレビューするには、エージェントが提供しないもの、つまり何を作るべきだったかの知識が必要だからです。もっともらしく見える400行のPRをレビューするシニアエンジニアは、構文を確認しているのではありません。これが正しい抽象化か、すでにあるものと重複していないか、負荷の下で動くか、エラーの経路は本物か、3つ先のサービスの前提を黙って壊していないか、を問うています。それは文脈であり、文脈は蓄積されるもので、すぐに採用できるものではありません。

だからこそ、Redditの不満のほうがLinkedInの議論より示唆に富んでいます。シニアたちは、今では設計よりレビューに多くの時間を使っていると報告しています。かつては組織のいくつもの階層を流れていた仕事が、それを判断する資格を持つ少数の人に集中しているのです。これは仕事量についての不満ではありません。スループットが最も希少な資源によって上限を決められ、上流での効率向上のたびにその上限がより強く効いてくるシステムを描写しているのです。

では、シニアだけを採用するか。それは2か所で破綻する

シニアだけでチームを固め、かつてジュニアがしていたことをエージェントに任せる、という当然の結論に、2025年には多くの創業者がたどり着きました。そしてそれは2つの具体的な点で破綻します。

1つ目は算数です。シニアエンジニアはレビューの能力そのものです。チーム全員がエージェントを使って2倍の量を生み出し、それを承認できるのが同じ人たちだけなら、新しい採用のたびに方程式の両辺が増えるシステムを作ったことになります。ある点を超えると、小さなチームに生み出す側のシニアをもう1人加えても、待ち行列は良くなるどころか悪化します。だからこそ、今エンジニアリングリーダーの間で出回っている最も役立つ指針は、拍子抜けするほど単純です。コードを書く人より先に、レビューする人を採用せよ。次の採用は、レビューの負荷を吸収できるかどうかで選ぶべきで、レビューが必要な仕事をさらに生み出せるかどうかで選ぶべきではありません。

2つ目の破綻は、ガーマン氏が本当に指摘していたもので、短い引用ではそれが失われるので、きちんと引用する価値があります。ジュニアは「おそらく最も人件費が安い社員で、AIツールを最も積極的に使っている」と彼は述べ、そのうえで本当の論点を示しました。「10年後に、何も学んだ人が誰もいなかったら、どうやって回るのか」。シニアは必要なときに買える再生可能な資源ではありません。難しい問題を任され、自分の仕事を確認してくれる人がいたジュニアなのです。エントリーレベルの採用を凍結する会社はコストを避けているのではなく先送りしているのであり、数年後に中堅人材を買おうとする市場は、他の誰もが同じように飢えさせた市場になります。

ジュニア崩壊のデータについての正直な注記

LinkedInの議論で最も強い証拠は、経済学者のセイエド・ホセイニ氏とガイ・リヒティンガー氏によるハーバードの研究で、2015年から2025年までの約28万5000社の米国企業と6000万人超の労働者を対象としています。企業が生成AIを導入すると、ジュニアの雇用は6四半期で約9〜10%減る一方、シニアの雇用はほぼ横ばいだという結果です。彼らはこれを 年功に偏った技術変化 と呼び、その仕組みは直感的です。生成AIは、エントリーレベルの職が成り立っていた定型的で明確に定義された仕事を得意としているのです。

しかし、採用計画を立てる創業者は原因をAIに帰しすぎるべきではないので、正直な反論にも耳を傾ける価値があります。エントリーレベルの崩壊が始まったのは2022年で、FRBが金利をほぼゼロから5.25%に引き上げた数か月後、ほとんどのワークフローにAIが意味のある形で入るはるか前のことでした。パンデミック後の採用過剰の修正や単純なコスト削減が、起きたことの大部分を説明しており、AIが本当の圧力を加えたのは2024年後半からにすぎません。多くの企業にとって、「AIで置き換えた」は「採用しすぎたうえに金利が上がった」よりも聞こえのいい話なのです。

どちらも正しく、あなたにとって重要なのはその組み合わせです。マクロの崩壊は主にAIのせいではなく、その上に重なる年功に偏った効果は本物で測定可能です。実際的には、2026年のジュニア人材は、この10年のどの時点よりも採用しやすく、同時に過小評価されているということです。一方で、あなたが最も必要としている特定のスキルは、より希少になっています。それは凍結する理由ではなく、採用の好機です。

出荷しているチームの実際の姿

2026年に速く出荷しているチームの実際の姿は、創業者が予想するより小さいものです。OpenAIのエンジニアリングのリーダーたちは、協力関係の強い3〜4人のグループが最も速く動く単位だと指摘しています。Soraは4人で28日のうちに出荷されました。小さなチームがここで勝つのは、レビューの制約 のおかげ でもあります。引き継ぎが少なく、共有する文脈が多く、レビュアーは変更を開く前からそれを理解しているからです。

そこから導かれる構成の指針は一貫しています。AIネイティブなチームはシニア中心ですが、エントリーレベルの採用は止めません。品質についての証拠も同じ方向を指しています。McKinseyは、成果の高い組織がAIを専門性の代わりに使うのではなく、シニアエンジニアと組み合わせることで、ソフトウェアの品質を31〜45%向上させたことを見出しました。てこの力は、判断を道具で置き換えることからではなく、道具と判断を組み合わせることから生まれたのです。

創業者の採用の順番

人数より先に待ち行列を測る。 PRが誰かに手を付けられるまでに待つ時間と、始まってからレビューにかかる時間を比べてください。待ち時間のほうが大きいなら、問題はレビューの能力であり、エージェントのスループットをいくら増やしても解決しません。
最初の採用はレビュアーにする。 アーキテクチャの判断に責任を持てるだけのシニアで、週の大半を他の人の仕事に使う意思のある人です。それを明示的に見極めてください。優れた作り手の多くはこの仕事を望んでおらず、望まない人を採用すると、ボトルネックは残り続けます。
次に、守りではなく意図してジュニアを採用する。 1人か2人、本物の問題と名前のあるレビュアーを付けて。人件費が安く、エージェントのツールを最も使いこなし、いずれ2人目のレビュアーを得る唯一の方法です。
努力ではなく、仕掛かり中の作業に上限を設ける。 エージェントが生成したPRを同時にいくつまで開いておけるかを制限してください。上限のない生成を、容量の限られたレビューの管に流し込んでも、生まれるのは滞留と古いブランチであって、スピードではありません。
自動化の予算は、生成ではなくレビューに使う。 生成はすでに吸収しきれないほどあります。テスト、静的解析、そして人が自分で確認しなければならない範囲を減らすレビュー前のエージェントによるチェックこそ、追加の1時間が報われる場所です。
指導を明示的に守る。 Indeedのメモは反面教師です。ジュニアのレビューが誰かの職務記述書と評価に含まれていなければ、レビューの待ち行列が真っ先にそれを飲み込んでしまいます。

一貫しているのは、AIが希少な資源を変え、多くの採用計画がまだそれに追いついていないということです。30年間、「もっと速く出荷しなければ」への答えは、コードを書く人を増やすことでした。その答えは今、具体的で測定可能な形で間違っています。コードを2倍にしても、本番に届く量が減るのを目にすることになるのです。

2026年後半にこれを正しく扱う創業者は、少し時代遅れに見えるでしょう。小さなチームで、シニア中心で、LinkedInで誰もがジュニアは要らないと説明している間もジュニアを採用し続けている。そして彼らこそ、mainブランチが動き続けている人たちです。2021年に抱えていた制約ではなく、今実際に抱えている制約に合わせて採用してください。