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 grown his engineering organization into a team with about three times its actual headcount, and the bottleneck shifted from the integrated development environment (IDE) to the people who decide what to build.
That detail is easy to overlook in the noise of each AI Productivity Claim. It is also the structural change that the rest of the industry is experiencing. The software bottleneck is no longer writing. It’s deciding what to write. And engineers who treat this as someone else’s problem are about to stagnate.
For most of the last decade, that decision fell to someone else. Software engineering it was a craft that was absorbed slowly and then practiced in a long, predictable sequence: dig into the technology, write the code, ask Stack Overflow when stuck, escalate to a senior engineer when Stack Overflow crashed, submit the ticket. The product manager owned the funnel. The engineer owned the construction. Both sides treated this division as physical.
Then the funnel collapsed in five steps.
A brief history of how the day of the engineer was compressed
The Stack Overflow era (2014 until the end of 2022): The way engineers thought lived in one place. But new monthly questions on Stack Overflow are no longer available approximately 77% since November 2022, which was no coincidence when ChatGPT was launched. The fall is not a referendum on the site. It’s a referendum on the workflow it represented.
The era of browser tabs (late 2022 to 2024): The first generation of ChatGPT was outside the IDE. The engineers ran the same loop they’d always run, just with a faster oracle: type a message in a browser, paste the response back into VS Code, and repeat. Work was still single-threaded and engineer-driven. The influence was real but local.
The native IDE 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 climbing path was largely dissolved. For years, the prevailing opinion among veteran engineers was that Bash had the longest lifespan of any tool on the market. By 2026, for a significant portion of working developers, the first command typed in a new terminal is claude.
The spec-driven era (2025 to 2026): Larger context windows turned single-session work into something that previously required tickets, design documents, and sprints. Amazon’s Kiro IDE team reportedly compressed feature builds from two weeks to two days using the same spec-based workflow they were shipping. An AWS engineering team described an 18-month restructure, originally planned for 30 engineers, that was completed by 6 people in 76 days. The bottleneck is no longer the time it takes to write the code. It started out as the clarity with which the team can describe what the right thing looks like.
The era of routines (2026): In April, Anthropic launched Claude Code Routines: persistent, scheduled agents that run at cadence, on a webhook, or overnight while the laptop is closed. Cron returned. Hooks returned. The engineer’s job is now part of orchestration: creating a swarm before bed, reviewing a stack of pull requests in the morning. Third-party wrappers like OpenClaw, which Anthropic briefly suspended in April before its partial reinstatement, made the same point from an open source point of view.
The bottleneck moved; most teams haven’t
Engineering has approximately tripled. Product management hasn’t budged. The traditional 1:8 ratio between PMs and engineers, which was already strained, is now closer to an effective 1:20 because each engineer ships more per day. For example, LinkedIn replaced its associated product manager profile with a "Product creator" program that trains generalists in products, design and engineering. Anthropic is hiring more PMs, not fewer. The pattern is consistent across companies that have actually deployed agent workflows in production: the system produces built features faster than it produces decisions about what to build.
For engineers, this is the biggest career sign of the decade, and the easiest to miss as productivity stories dominate the news.
First Principles Matter More, Not Less
The instinct to declare fundamentals obsolete in the age of agents gets the trend exactly wrong.
When a memory leak disrupts production at 3 a.m. and the cause turns out to be a subtle proprietary error that started 4 years ago, no agent currently available closes that end-to-end loop. Operating systems, networks, concurrency, and query plans still decide who can resolve a real incident. They also decide who can detect moments when a agent exit It seems right on the surface and, quietly and expensively, wrong at heart. The agent who wrote 70% of the code in a modern repository cannot reliably tell anyone where its assumptions about thread safety, memory ownership, or runtime transaction isolation diverged. The engineer who can read the differences and grasp that is the engineer the rest of the team needs in the room, and that engineer is based on fundamentals, not cueing skills.
The corollary is that fundamentals are now a leverage skill, not a hygiene skill. In 2014, knowing how a TCP relay worked made a debug ticket close faster. In 2026, the same knowledge will prevent an entire agent-driven release process from regressing at scale. The blast radius of the engineer who knows what’s going on below has increased, not decreased.
The review is the new writing.
By 2026, engineers will generate code at a rate that exceeds what any of them can read carefully. The team that launches 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. 2025 Stack Overflow Developer Survey put 84% of developers on AI tools, and 46% said they don’t trust the result, a sharp increase from 31% a year earlier. That gap, heavy usage combined with low confidence, is exactly where review skills are now most important. Coders who push hard and check little are accumulating debt that will come due during the first real incident, and the engineer who can pay it off is the one who combined his volume with a deep understanding of the first principles of the systems involved.
The new differentiator is the product funnel.
Both are necessary. Neither of them is enough. 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 that the role was historically allowed to omit.
Talk to customers. Observe how they actually use the product. Read the support queue. Sit in on the sales call. The signal a product team receives 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 generate ideas for 8 engineers cannot generate ideas for 20 with 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 work that the new ratio requires.
Work backwards from the client. Amazon has been writing the press release first for two decades. Discipline transfers well to teams of one and swarms of agents. They both produce a lot of software that works in the wrong direction without a clear statement of what "the customer wins" means before writing any code.
Stop hiding behind bandwidth. The honest answer to "Do you have capacity for this idea?" It used to be ‘No’. With routines, hooks, and a stack of cooperative agents, the honest answer is closer to "How much is the idea worth?" That’s a different conversation and much harder to have without a real customer point of view.
What the next decade rewards
The five-phase story above is not really a tool story. It’s a story of how much of the work a human had to do. The part that is still human, and will remain human for the foreseeable future, has moved up the funnel: from writing to reviewing to deciding to choosing the client to serve and the problem to solve.
The 2026 version of a great engineer He is not the one who writes the most code. It’s the one who knows what to build, can demonstrate that it’s worth building, and has the fleet of agents plus the review discipline to ship it without the system collapsing under its own speed.
Engineers who internalize this will spend the next decade doing the most interesting work software has ever produced. Engineers waiting for a ticket will spend it watching the agent next to them write the ticket.
Ishan Gupta is a software engineer at Amazon.
