Recent advances — especially putting large models inside IDEs and deploying agentic workflows — have fundamentally changed engineering work. The bottleneck in software development is no longer typing or how fast code can be written: it is who decides, and how clearly they can specify, what should be built.
What happened (who, when, why it matters)
Anthropic provides a concrete example: internal reporting indicates Claude Code enabled some engineering teams to ship at roughly three times the rate implied by their headcount. As a result the constraint shifted from IDE throughput to the people who define what gets built — decision-making became the primary bottleneck.
A short history: how the engineer's day compressed
- The Stack Overflow era (2014–late 2022): engineering was a relatively linear craft — learn the tech, write the code, consult Stack Overflow when stuck, escalate to a senior engineer if needed. New monthly questions on Stack Overflow have dropped roughly 77% since November 2022, coinciding with ChatGPT's launch; this decline reflects a change in the workflow represented by the site.
- The browser-tab era (late 2022–2024): first-generation ChatGPT sat outside the IDE. Engineers used a faster oracle — write a prompt in a browser, paste the result into the editor, repeat. Work remained single-threaded and engineer-driven, with localized leverage.
- The IDE-native era (2024–2025): tools like Cursor and Claude Code moved models into the editor with repository access. The senior-engineer escalation path largely dissolved. Practices that once favored Bash as the most enduring tool shifted — by 2026, for many developers the first command in a fresh terminal is reportedly "claude."
- The spec-driven era (2025–2026): larger context windows let single sessions handle work 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. An AWS engineering team said an 18-month rearchitecture, originally scoped for 30 engineers, was completed by 6 people in 76 days. The bottleneck moved from writing the code to how clearly a 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, via webhooks, or overnight. Cron and hooks returned. Third-party wrappers like OpenClaw (briefly suspended by Anthropic in April before partial reinstatement) underscored the same point from the open-source side.
The bottleneck moved; most teams haven't
Where agentic workflows are deployed in production, engineering throughput has effectively tripled. Product management headcount has not scaled at the same pace. The traditional 1:8 PM-to-engineer ratio, already stretched, now plays out closer to an effective 1:20, because each engineer ships much more per day. LinkedIn, for example, replaced its associate product manager track with a "Product Builder" program training generalists across product, design, and engineering. Anthropic is hiring more PMs, not fewer.
Across companies using agentic workflows, the system produces built features faster than it produces the decisions about what to build.
Career implications for engineers
- First principles matter more, not less: operating systems, networks, concurrency, and query plans still determine who can resolve a true incident. An agent that wrote 70% of a modern repo cannot reliably say where its assumptions on thread safety, memory ownership, or transaction isolation diverged from runtime — a human with fundamentals can. That engineer prevents costly failures.
- Fundamentals are now a leverage skill, not merely hygiene. What used to speed a debug ticket closure in 2014 now prevents agent-driven release pipelines from shipping regressions at scale in 2026. The blast radius of an engineer who understands underlying systems has grown.
- Review is the new writing: in 2026 engineers generate code faster than any individual can read carefully. The teams that survive are those that review AI-generated code with as much rigor as they once applied to hand-written code.
Numbers on trust and use: the 2025 Stack Overflow developer survey found 84% of developers use AI tools, but 46% said they do not trust the output — up sharply from 31% the year before. Heavy use combined with low trust is exactly where review skills are now critical. Engineers who push a lot of code but review little are accruing debt that will surface in the first real incident; engineers who can pay it back pair volume with deep, first-principles knowledge.
The new differentiator: the product funnel
Both fundamentals and review skills are necessary but not sufficient. The engineer who matters in 2026 is the one who stopped waiting for a Jira ticket.
That requires doing things the role previously could skip:
- Talk to customers. Observe how they use the product. Read the support queue. Sit in on sales calls. An engineer can get the signal a product team receives through multiple summaries in an afternoon.
- Generate ideas, not just estimates. A PM who used to source ideas for 8 engineers cannot serve 20 with the same fidelity. An engineer who brings a validated, scoped opportunity is doing the work the new ratio requires.
- Work backwards from the customer. Amazon's press-release-first discipline scales down to individuals and agent swarms; without a clear statement of what a "customer win" looks like, teams will ship a lot of software in the wrong direction.
- Stop hiding behind bandwidth. The honest answer to "Do you have capacity for this idea?" used to be "No." With routines, hooks, and cooperative agent stacks, the honest answer is closer to "What is the idea worth?" — a harder conversation that needs a real point of view on the customer.
What the next decade will reward
The five-phase arc above is less about tools than about which part of the job required human attention. The human part has moved up the funnel: from typing to reviewing to deciding to choosing the customer and the problem to solve.
The 2026 great engineer is not the person who writes the most code. It is the person who knows what to build, can prove it is worth building, and has the agent fleet plus the review discipline to ship without the system collapsing under its own velocity.
Engineers who internalize this will spend the next decade doing some of the most interesting software work ever. Engineers who wait for a ticket will watch the agent next to them write that ticket.
Author
Ishan Gupta is a software engineer at Amazon.
