That gap — between code that runs and software that can be trusted — is where this story actually lives.
An afternoon miracle, and what it doesn’t show
Software engineering has never been mainly about typing syntax, even though syntax is the only part outsiders usually see. In any mature team, writing the first version of a function is often the cheapest step in a much longer chain that also includes deciding what the system should actually do, choosing an architecture that won’t collapse under future requirements, testing conditions nobody has thought of yet, integrating with older systems built by people who’ve since left the company, monitoring how the thing behaves once real users touch it, and maintaining it for years after the initial excitement fades. Writing code is one output of that process — frequently not the most expensive one.
A concrete example from the central report makes this vivid. Ask an AI model to implement something as ordinary as "let a user transfer money between two accounts," and it will produce a short, plausible-looking function in seconds. It will compile. It will pass the obvious test. It will also contain at least half a dozen defects that only show up in production: two simultaneous transfers from the same account can both succeed and overdraw it; a retried request after a timeout can double-charge someone; a negative amount can quietly reverse the direction of the transfer; moving money between different currencies can go through without conversion; and there’s no record of what happened, so when something does go wrong, nobody can reconstruct it.
Fixing all of that doesn’t require more coding skill than writing the original version — a competent model can generate the safer version too, if asked correctly. It needs something called an idempotency key, essentially a unique tag attached to a request so the system recognizes "I already did this one" and doesn’t repeat it, plus a fixed order for locking accounts, currency checks, and an audit trail. None of that is conceptually hard to generate. What’s scarce is knowing that each of those protections has to exist in the first place — knowledge usually acquired by having watched the unprotected version fail. The code became cheap. The list of things that must go on the list did not.
From commits to customers: a funnel that narrows
This pattern shows up at scale, not just in a single example. A 2026 study from the National Bureau of Economic Research tracked more than 100,000 developers across successive generations of AI tools — plain autocomplete, interactive coding assistants, and fully autonomous agents — and measured what happened to their output. Commit activity, a record of changes saved to a project’s version history rather than a direct measure of anything shipped or used, rose dramatically: roughly 40% with autocomplete, 140% with interactive agents, and about 180% with autonomous agents.
If more commits simply meant more delivered software, that would be one of the most important productivity jumps in the industry’s history. It isn’t that simple. The same study found that the 180% rise in commits produced only about 50% more completed projects and roughly 30% more actual releases — and across major app marketplaces, no measurable increase in overall usage. Generated code multiplied; the number of people actually using the resulting software did not move.
flowchart TD A[Prompts and AI-generated code] --> B[Completed projects] B --> C[Shipped releases] C --> D[Customer adoption and usage]
Each arrow in that chain passes through a different bottleneck. Turning code into a finished project requires someone to review it, decide if it’s correct, and integrate it with everything else the system depends on — and review capacity didn’t grow by 180% just because generation did. Turning a project into a release requires testing against conditions nobody specified in the prompt, and clearing whatever process a company uses to decide something is ready. And turning a release into actual usage runs into a constraint AI can’t touch at all: how many customers exist, how much attention and budget they have, and how willing they are to switch from whatever they’re already using. The NBER researchers also estimated how interchangeable AI and human effort are at a technical level — the figure came out low enough to indicate the two remain strongly complementary rather than substitutes, meaning a company can’t simply swap one for the other and expect output to hold steady.
It’s worth being careful here: part of that 180% rise may simply reflect agents producing a commit per small step rather than one commit per finished task, which would inflate the count without changing what was actually built. The direction of the finding — far more generated code chasing far fewer releases — is well supported; the exact size of the gap is less certain than the headline number suggests.
The same code, two very different outcomes
Not everyone gets the same value out of these tools, and that unevenness is itself informative. Anthropic analyzed close to 400,000 sessions with its Claude Code agent and compared how novices and experienced users worked with the same technology. The differences were large: experts triggered more than double the number of agent actions per prompt and produced roughly five times as much output text, because they broke problems down more precisely and pushed the agent further. The payoff showed up directly in results — fully verified successful outcomes were recorded in about 15% of novice sessions versus 28–33% of expert sessions, and novices abandoned tasks without any usable result nearly four times as often.
What made someone an "expert" in this data wasn’t primarily programming background. Software engineers succeeded at around 30%, but professionals from ten other fields — including management, sales, and law — landed within a few percentage points of that figure. The decisive skill was the ability to specify a problem clearly and judge whether the output actually solved it: users made roughly 70% of the planning decisions about what needed doing, while the agent handled about 80% of the execution decisions about how to do it. Domain knowledge, not coding fluency, increasingly determines who gets useful work out of these systems.
Where the speedup actually lands
Putting the generation, review, and adoption stages side by side makes clear why treating "AI writes code fast" as the whole story is misleading.
| Stage | What AI changes | What still depends on people | Typical timescale |
|---|---|---|---|
| Generation | Produces working drafts, tests, scripts, schemas almost instantly | Deciding which requirement actually matters | Minutes |
| Review & correctness | Can catch some obvious errors, suggest fixes | Judging edge cases, security, business rules | Hours to days |
| Integration & architecture | Can draft connectors and migrations | Choosing designs that survive future change, avoiding fragile dependencies | Weeks |
| Reliability & accountability | Can flag some issues, monitor logs | Owning outcomes, signing off in regulated contexts, coordinating teams | Ongoing |
| Market adoption | No direct effect | Customer demand, trust, switching costs | Months to years |
Reliability, in particular, is as much a matter of process and coordination as of code quality — a well-written function still fails if nobody owns the decision to test it against real-world failure modes, or if two teams assume different things about who handles an edge case.
Why scarcity moves instead of disappearing
None of this means software engineering as a profession is shrinking. Labor projections cited in the central report show the narrower job title "computer programmer" declining over the coming decade while the broader category "software developer" keeps growing — a sign that the work is changing shape rather than vanishing. What’s getting cheaper is the bounded, well-specified part of coding: translating clear instructions into working syntax, assembling standard components, producing conventional interfaces. What’s staying scarce — and by some measures becoming more valuable — is the capacity to define the right problem, catch what a generated solution misses, fit it into a larger system without breaking something else, and take responsibility when it doesn’t work.
That’s the shift worth understanding, and it cuts against two tempting stories at once: that AI has made software engineering effortless, and that it offers nothing real. It has made one input — generated code — abundant. It has left the other input — the judgment to turn that code into something dependable — exactly as scarce as it always was, and arguably more exposed, since there’s now far more generated material that someone has to check.
The part that doesn’t get automated
If AI coding tools have a single lesson for managers, product people, and anyone starting out in the field, it’s this: the bottleneck didn’t disappear, it moved. It moved away from "can someone produce this code" and toward "can someone decide what should be built, tell whether the output is right, and stand behind it when something breaks." That’s a different, older kind of expertise — one built through experience with failure, not through typing speed — and for now, nothing in the evidence suggests it’s becoming any less necessary.
