Two things are true at once in 2026, and most arguments about AI in software pick one and ignore the other.
The adoption number is real
As of mid-2026, around 90 percent of professional developers use AI coding agents at work at least weekly and 68 percent use them daily. Gartner puts the net average productivity gain at 19.3 percent, with developers saving roughly 3.6 hours a week. Daily users merge about 60 percent more pull requests than non-users.
Nineteen percent is a genuine gain. It is also a long way from the replacement narrative, and the gap between those two numbers is where most of the confusion lives.
The saved hours are concentrated in a specific kind of work: boilerplate, test scaffolding, unfamiliar syntax, the first draft of something well-trodden. That work was never the expensive part.
The quality number is also real
Research tracking more than 300,000 AI-authored commits found 22.7 percent of the quality issues introduced by AI tooling persist into production. Repositories that adopted one popular agent showed a 41 percent rise in complexity and a 30 percent rise in static analysis warnings.
Complexity is the number to watch, because it is the one that compounds. A system that gets 41 percent more complex is a system where the next change costs more, the next engineer takes longer to onboard, and the next incident takes longer to diagnose. None of that shows up in a velocity chart.
This is not an argument against the tools. We use them daily. It is an argument that generated volume and delivered value stopped being the same measurement, and that if you only track the first one your estimates will quietly stop matching reality.
The number nobody puts in the pitch deck
88 percent of agent pilots never reach production. The blockers reported are infrastructure and governance rather than model quality: deployment, access control, data boundaries, monitoring and the question of who is accountable when the agent is wrong.
It is the most useful figure of the three. The hard part of an AI feature has almost never been the model. It is everything around the model, which is ordinary engineering, and ordinary engineering is exactly what a demo skips.
| Stage | What it needs | Where pilots die |
|---|---|---|
| Demo | A model and a prompt | Rarely |
| Pilot | Real data, a real workflow | Sometimes |
| Production | Access control, monitoring, fallback, accountability | Usually here |
What this changes about hiring a team
If output volume is cheap and correctness is not, the value of a team moves to the parts that were always scarce: deciding what to build, designing a system that stays workable, and being accountable for what happens after launch.
- Ask how a team reviews generated work, not whether they use the tools. Everyone uses the tools.
- Ask what they measure besides shipping speed. If nothing, complexity is accumulating unmeasured.
- Ask what their last AI feature does when the model is unavailable, slow or wrong. The answer describes their engineering, not their prompting.
- Ask who is accountable for a wrong output reaching a user. If that is unowned, it is unbuilt.
The cost of producing software fell. The cost of being responsible for it did not move.