Claude Code がエンジニアを 3 倍に増やした今、企業はより多くの製品思考者を必要としている（8 分読み）
Claude Code の登場によりエンジニアの生産性が飛躍的に向上した結果、開発ボトルネックがコーディングから「何を作るか」という意思決定へと移行し、企業はより多くの製品思考を持つ人材を必要としている。
キーポイント
ボトルネックのシフト
AI ツールの普及によりコード作成の負担が劇的に減ったことで、開発プロセスの最大の制約要因が「実装」から「機能定義や意思決定」へと移行した。
組織構造の変化
Anthropic はエンジニア組織が実際の人員数に対して約 3 倍の生産性を発揮していることを認識し、開発チームに製品マネージャーをさらに増員する方針を示した。
エンジニアリングワークフローの変容
Stack Overflow やブラウザベースのチャットから IDE ネイティブな AI へ、そして最終的には仕様（spec）駆動型へと開発プロセスが圧縮・進化している。
キャリアの分岐点
AI の生成能力を前提とした作業に留まるエンジニアは成長の限界を迎える一方、製品設計や意思決定に関与できる人材の価値が高まっている。
影響分析・編集コメントを表示
影響分析
この記事は、AI が単なる生産性向上ツールを超え、ソフトウェア開発の社会構造そのものを変容させていることを示唆しています。エンジニアリングの専門性が「コードを書くこと」から「問題を定義し解決策を設計すること」へと再定義される中、企業の採用戦略や組織編成が根本的に見直されざるを得ない局面に来ています。
編集コメント
AI ツールの進化がもたらすのは単なる効率化ではなく、開発プロセスにおける権限と責任の再分配です。エンジニアはコードを書く「職人」から、製品を導く「設計者」へと役割を変容させる必要があります。
Anthropic は最近、成長チームに対してエンジニアを減らすのではなく、より多くのプロダクトマネージャーを採用するよう指示しました。業界報道によるとその理由は、Claude Code が静かに同社のエンジニア組織を実際の人員数の約 3 倍のペースでリリースできるチームへと変貌させたこと、そしてボトルネックが統合開発環境（IDE）から「何を構築するかを決定する人々」へ移行したことにあります。
この詳細は、あらゆる AI の生産性に関する主張 の雑音の中で見過ごされやすいものです。しかし、これは業界全体が現在経験している構造的な転換点でもあります。ソフトウェア開発におけるボトルネックはもはやタイピングではありません。「何をタイプするか」を決定することです。そして、それを他人事として扱うエンジニアたちは、すぐに頭打ちを迎えることになります。
過去 10 年ほどの間、その決定権は他者にありました。ソフトウェアエンジニアリング は、ゆっくりと吸収し、長く予測可能な一連の工程で実践する職人技でした：技術に深く没入し、コードを書き、行き詰まったら Stack Overflow で質問し、Stack Overflow でも解決できなければシニアエンジニアにエスカレーションし、チケットを完了させる。プロダクトマネージャーが漏斗（フィルタリング機能）を管理し、エンジニアが構築を担当していました。双方はこの役割分担を物理法則のように捉えていました。
その後、漏斗は 5 つのステップで崩壊しました。
エンジニアの一日が圧縮されてきた短い歴史
Stack Overflow の時代（2014 年から 2022 年末）： エンジニアの思考様式は一つの場所に存在していました。しかし、Stack Overflow における新しい月間質問数は 2022 年 11 月以来、約 77% 減少しています。これは ChatGPT が登場した時期と偶然一致するものではありませんが、このサイトの評価を下すものではなく、それが象徴していたワークフローに対する投票結果です。
ブラウザタブの時代（2022 年末から 2024 年）： 最初の ChatGPT 世代は IDE の外側に位置していました。エンジニアたちはこれまで通り同じループを回しただけで、より高速なオラクル（予言者）を利用するだけでした：ブラウザでプロンプトを入力し、回答を VS Code に貼り付け、これを繰り返す。作業はまだシングルスレッドかつエンジニア主導であり、そのレバレッジは確かに存在しましたが局所的なものに留まりました。
IDE ネイティブの時代（2024 年から 2025 年）： Cursor や Claude Code はモデルをエディタ内部へ移動させ、フルリポジトリへのアクセス権を与えました。シニアエンジニアによるエスカレーションパスはほぼ解消されました。長年にわたり、ベテランエンジニアたちの共通認識として、「Bash」がスタック内のどのツールよりも最も長い寿命を持つとされてきました。しかし 2026 年には、実務開発者の有意な割合にとって、新しいターミナルで最初に入力されるコマンドは「claude」となるでしょう。
仕様駆動の時代（2025年から2026年）: 大規模なコンテキストウィンドウにより、単一セッションでの作業が、以前はチケット、設計ドキュメント、スプリントを必要としていたものへと変容しました。Amazon の Kiro IDE チームは、同様の仕様駆動型ワークフローを用いて機能構築を2週間から2日に圧縮したと報じられています。ある AWS のエンジニアリングチームでは、当初30名のエンジニアを対象に18ヶ月かけて行われる予定だった再アーキテクチャが、6名によって76日間で完了しました。ボトルネックはコードを書くのにどれくらい時間がかかるかではなく、チームが「正しい状態」をいかに明確に記述できるかに移り始めました。
ルーチンの時代（2026年）: 4月、Anthropic は Claude Code Routines をリリースしました。これはスケジュールに従って、Webhook をトリガーとして、あるいはラップトップが閉じられた夜間に実行される、持続的なエージェントです。Cron が復活し、Hooks も復活しました。エンジニアの役割は現在、オーケストレーションの一部となっています。就寝前に群れ（スワーム）を起動し、朝にはプルリクエストの山を検証するのです。OpenClaw などのサードパーティ製ラッパーも、Anthropic に4月に一時的に停止された後部分的に復権した経緯を持つものの、オープンソース側から同様の点を強調しました。
ボトルネックは移動したが、ほとんどのチームはまだ追いついていない
エンジニアリングの規模はおおよそ3倍に拡大した。一方、プロダクトマネジメントは微動だにしていない。すでに負担のかかっていた従来の PM（プロダクトマネージャー）対エンジニア 1:8 の比率は、各エンジニアが1日に出荷する機能が増えたため、実質的に 1:20 に近づいている。例えば、LinkedIn は准プロダクトマネージャーのキャリアパスを廃止し、「Product Builder」プログラムを導入して、プロダクト、デザイン、エンジニアリングにわたる一般職者を育成している。Anthropic も PM の数を減らすのではなく増やしている。実際に生産環境でエージェント型ワークフローを展開した企業に見られるパターンは共通しており、システムが構築された機能をより速く生み出している一方で、何を構築すべきかという意思決定を生み出す速度には追いついていない。
エンジニアにとって、これは今世紀最も重要なキャリアのシグナルであり、生産性向上に関する物語がフィードを支配する中で見落としやすいものでもある。
第一原理は、むしろ以前よりも重要である
エージェント時代において基礎的な要素が不要になると宣言する直感は、このトレンドを完全に誤解している。
午前3時にメモリリークが発生してプロダクションがダウンし、その原因が4年前にプッシュされた微妙な所有権のバグだった場合、現在野外で稼働しているどのエージェントも、このループをエンドツーエンドで完結させることはできません。オペレーティングシステム、ネットワーク、並行処理、クエリプランは依然として、実際のインシデントを解決できるのが誰かを決定します。また、表面では正しく見えるが、裏側では静かに、かつ高価に間違っている瞬間を特定できるのが誰かも決定します。現代のリポジトリのコードの70%を書いたエージェントは、スレッドセーフティ、メモリ所有権、トランザクション分離に関する自身の仮定が実行時とどこで乖離したかを、信頼性を持って誰かに伝えることはできません。その差分を読み込んでそれを捕捉できるエンジニアこそが、チームの他のメンバーが必要とする部屋にいるエンジニアであり、そのようなエンジニアはプロンプティングスキルではなく、基礎的な知識の上に築かれています。
この帰結として、基礎的な知識は今や衛生管理のためのスキルではなく、レバレッジ（効果増幅）のためのスキルとなっています。2014年には、TCP再送の仕組みを知っていることがデバッグチケットをより早くクローズさせる要因となりましたが、2026年には同じ知識が、エージェント駆動型のリリースパイプラインが大規模な回帰（regression）をリリースするのを防ぐ役割を果たします。裏側で何が起きているかを知るエンジニアの爆発半径（blast radius）は、低下したのではなくむしろ拡大しています。
Review is the new writing
2026 年のエンジニアは、自分たちが慎重に読み切ることを超える速度でコードを生成する。速くリリースし生き残るチームとは、AI が生成したコードのレビューを、かつてコードを書く際にだけ適用していたのと同じ厳格さで扱うエンジニアを持つチームである。2025 年の Stack Overflow 開発者調査 では、84% の開発者が AI ツールを利用していると回答し、そのうち 46% が出力を信頼していないと答えた。これは前年の 31% から急激に増加した数値である。この「大量利用と低信頼」というギャップこそが、今最もレビュースキルが重要となる領域だ。多くのコードを生成してレビューを怠るコーダーは、最初の実際のインシデント時に返済を迫られる負債を蓄積している。その負債を支払えるのは、そのボリュームに、関連するシステムに関する深い第一原理の知識（first-principles knowledge）を組み合わせたエンジニアだけである。
The new differentiator is the product funnel
両方とも必要だが、どちらか一方だけでは不十分だ。2026 年に価値あるエンジニアとは、Jira チケットという形で「フンネル」がやってくるのを待つのをやめた人である。
それは、歴史的にその役割で省略することが許されていたことを実行することを意味する。
顧客と話す。製品をどのように実際に使用しているかを観察する。サポートのキュー（queue）を読む。営業電話に同席する。プロダクトチームが3層の要約を通じて得るシグナルを、エンジニアは午後1時間で直接入手できるようになった。
アイデアを推定値だけでなく生成せよ。かつて 8 人のエンジニア向けにアイデアを調達していたプロダクトマネージャーが、同じ精度で 20 人分のアイデアを調達することはできない。検証済みで範囲が明確な機会を持って現れるエンジニアはもはや PM の仕事を代行しているわけではない。そのエンジニアは、新しい比率が必要とする役割を果たしているのである。
顧客から逆算せよ。Amazon は過去 20 年間、まずプレスリリースを作成する手法を採用してきた。この規律は、1 人のチームにもエージェントの群れにもよく適用できる。しかし、「コードを書く前に『顧客が勝つ』とは何を意味するのか」という明確な定義がないままでは、両者は間違った方向へ大量の動作可能なソフトウェアを生産してしまうだけだ。
帯域幅を隠れ蓑にするのをやめよ。「このアイデアに余力があるか？」という問いに対する正直な答えはかつて「いいえ」だった。ルーチン化された手順、フック、そして協力的なエージェントスタックがあれば、正直な答えは「そのアイデアの価値はいくらか？」へと近づく。これは全く異なる会話であり、顧客に対する真摯な見解を持たなければ、非常に難しい対話となる。
次なる 10 年が報いるもの
上記の 5 つのフェーズからなる歴史は、実のところツールの歴史ではない。それは人間が業務のどの部分を担う必要があったかという歴史である。今後長期間にわたり依然として人間の領域であり続ける部分は、ファネルの上流へと移動した：タイピングからレビューへ、意思決定へ、そして「誰を顧客とするか」「何を解決すべき問題とするか」を選択することへと。
⟦CODE_0⟧
⟦CODE_1⟧
2026 年版の「優れたエンジニア」とは、最も多くのコードを書く人ではありません。それは、何を構築すべきかを知り、それが価値あるものであることを証明でき、システムがその速度によって崩壊することなく出荷するために、エージェント群とレビューの規律を備えている人です。
この考え方を内面化したエンジニアたちは、今後 10 年間でソフトウェア史上かつてないほど興味深い仕事に携わることになります。一方、チケット（作業依頼）を待っているだけのエンジニアたちは、隣でエージェントがそのチケットを書き起こすのを眺めることになります。
*イシャーン・グプタはアマゾンのソフトウェアエンジニアです。*
VentureBeat コミュニティへようこそ！
当社のゲスト投稿プログラムでは、技術専門家が AI、データインフラストラクチャ、サイバーセキュリティ、および企業の未来を形作るその他の最先端技術について、中立的で利害関係のない深い洞察を提供しています。
当社のゲスト投稿プログラムについては こちら をお読みください。また、ご自身の記事を投稿したい場合は、ガイドライン もご確認ください！
原文を表示
Anthropic recently told its growth team to hire more product managers, not fewer. The reason, as reported in industry coverage, was that Claude Code had quietly turned its engineering org into a team that ships at roughly three times its actual headcount, and the bottleneck moved from the integrated development environment (IDE) to the people deciding what to build.
That detail is easy to miss in the noise of every AI productivity claim. It is also the structural shift the rest of the industry is now living through. The bottleneck in software is no longer typing. It is deciding what to type. And the engineers who treat that as someone else's problem are about to plateau.
For most of the last decade, that decision sat with someone else. Software engineering was a craft you absorbed slowly, then practiced in a long, predictable sequence: Dive deep on the technology, write the code, ask Stack Overflow when stuck, escalate to a senior engineer when Stack Overflow failed, ship the ticket. The product manager owned the funnel. The engineer owned the build. Both sides treated this division as physics.
Then the funnel collapsed in five steps.
A short history of how the engineer's day got compressed
The Stack Overflow era (2014 to late 2022): The way engineers thought lived in one place. But new monthly questions on Stack Overflow are now down roughly 77% since November 2022, which was not coincidentally when ChatGPT launched. The drop is not a referendum on the site. It is a referendum on the workflow it represented.
The browser-tab era (late 2022 to 2024): The first ChatGPT generation sat outside the IDE. Engineers ran the same loop they had always run, just with a faster oracle: Write a prompt in a browser, paste the answer back into VS Code, repeat. The work was still single-threaded and engineer-driven. The leverage was real but local.
The IDE-native era (2024 to 2025): Cursor and Claude Code moved the model inside the editor and gave it access to the full repository. The senior-engineer escalation path largely dissolved. For years, the prevailing wisdom among veteran engineers was that Bash had the longest shelf life of any tool in the stack. By 2026, for a meaningful share of working developers, the first command typed in a fresh terminal is claude.
The spec-driven era (2025 to 2026): Larger context windows turned single-session work into something that previously required tickets, design docs, and sprints. Amazon's Kiro IDE team reportedly compressed feature builds from two weeks to two days using the same spec-driven workflow they were shipping. An AWS engineering team described an 18-month rearchitecture, originally scoped for 30 engineers, was completed by 6 people in 76 days. The bottleneck stopped being how long it takes to write the code. It started being how clearly the team can describe what correct looks like.
The routines era (2026): In April, Anthropic shipped Claude Code Routines: Scheduled, persistent agents that run on a cadence, on a webhook, or overnight while the laptop is closed. Cron came back. Hooks came back. The engineer's job is now part orchestration: Spin up a swarm before bed, review a stack of pull requests in the morning. Third-party wrappers like OpenClaw, which was briefly suspended by Anthropic in April before partial reinstatement, made the same point from the open-source side.
The bottleneck moved; most teams have not
Engineering has roughly tripled. Product management has not budged. The traditional 1:8 ratio of PMs to engineers, already strained, now plays out closer to an effective 1:20 because each engineer ships more per day. For instance, LinkedIn replaced its associate product manager track with a "Product Builder" program that trains generalists across product, design, and engineering. Anthropic is hiring more PMs, not fewer. The pattern is consistent across companies that have actually deployed agentic workflows in production: The system is producing built features faster than it is producing decisions about what should be built.
For engineers, this is the most important career signal of the decade, and the easiest one to miss while the productivity stories dominate the feed.
First principles matter more, not less
The instinct to declare fundamentals obsolete in the agent era gets the trend exactly wrong.
When a memory leak takes down production at 3 a.m., and the cause turns out to be a subtle ownership bug pushed 4 years ago, no agent currently in the wild closes that loop end-to-end. Operating systems, networks, concurrency, and query plans still decide who can resolve a real incident. They also decide who can spot the moments when an agent's output looks correct on the surface and is quietly, expensively, wrong underneath. The agent that wrote 70% of the code in a modern repo cannot reliably tell anyone where its assumptions about thread safety, memory ownership, or transaction isolation diverged from the runtime. The engineer who can read the diff and catch that is the engineer the rest of the team needs in the room, and that engineer is built on fundamentals, not on prompting skill.
The corollary is that fundamentals are now a leverage skill, not a hygiene skill. In 2014, knowing how a TCP retransmit worked got a debug ticket closed faster. In 2026, the same knowledge keeps an entire agent-driven release pipeline from shipping a regression at scale. The blast radius of the engineer who knows what is happening underneath has gone up, not down.
Review is the new writing
Engineers in 2026 generate code at a rate that exceeds what any of them can read carefully. The team that ships fast and survives is the team whose engineers treat reviewing AI-generated code with at least the same rigor they once reserved for writing it. The 2025 Stack Overflow developer survey put 84% of developers on AI tools, with 46% saying they do not trust the output, up sharply from 31% the year before. That gap, heavy use paired with low trust, is exactly where review skills now matter most. Coders who push lots and review little are accumulating a debt that will come due during the first real incident, and the engineer who can pay it back is the one who paired their volume with deep first-principles knowledge of the systems involved.
The new differentiator is the product funnel
Both of those are necessary. Neither is sufficient. The engineer who matters in 2026 is the one who has stopped waiting for the funnel to arrive in the form of a Jira ticket.
That means doing things the role was historically allowed to skip.
Talk to customers. Watch how they actually use the product. Read the support queue. Sit in on the sales call. The signal a product team gets through three layers of summary, an engineer can now get firsthand in an afternoon.
Generate ideas, not just estimates. The product manager who used to source ideas for 8 engineers cannot source ideas for 20 at the same fidelity. The engineer who shows up with a validated, scoped opportunity is no longer doing the PM's job. The engineer is doing the job the new ratio requires.
Work backwards from the customer. Amazon has been writing the press release first for two decades. The discipline travels well to teams of one and to swarms of agents. Both produce a great deal of working software in the wrong direction without a clear statement of what "customer wins" means before any code is written.
Stop hiding behind bandwidth. The honest answer to "Do you have capacity for this idea?" used to be 'No.' With routines, hooks, and a cooperative agent stack, the honest answer is closer to "What is the idea worth?" That is a different conversation, and a much harder one to have without a real point of view on the customer.
What the next decade rewards
The five-phase history above is not really a history of tools. It is a history of which part of the job a human had to do. The part that is still human, and that will remain human for the foreseeable future, has moved up the funnel: From typing, to reviewing, to deciding, to choosing the customer to serve and the problem to solve.
The 2026 version of a great engineer is not the one who writes the most code. It is the one who knows what to build, can prove it is worth building, and has the agent fleet plus the review discipline to ship it without the system collapsing under its own velocity.
Engineers who internalize this will spend the next decade doing the most interesting work software has ever produced. Engineers who wait for a ticket will spend it watching the ticket get written by the agent next to them.
*Ishan Gupta is a software engineer at Amazon.*
Welcome to the VentureBeat community!
Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.
Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み