AI delivery stability is the number almost nobody is tracking, and it is the one moving in the wrong direction. The adoption argument, by contrast, is settled. DORA’s 2025 State of AI-assisted Software Development found that around 90% of technology professionals use AI at work, and more than 80% believe it has made them more productive. Whatever debate existed about whether engineers would take up these tools ended some time ago, mostly without anyone waiting to be asked.
The finding that matters sits underneath that one. The same research associates higher AI adoption with an increase in software delivery throughput and an increase in software delivery instability.
More gets shipped. More breaks.
The trust number nobody expected
Alongside near-universal use, roughly 30% of developers report little or no trust in AI-generated code.
That is a strange thing to say about a tool you reach for every day, and it is not irrational. It is a reasonable response to output that is confident, fluent and occasionally wrong in ways that are expensive to find later. The distrust is not a barrier to adoption — adoption already happened. It describes how the work now feels: faster to start, heavier to finish.
The verification tax
DORA describes the mechanism plainly. Time saved during generation is reallocated to verification. Engineers spend it auditing output and refining instructions. The report’s own term for this is the verification tax.
The work did not disappear. It moved — from writing to checking. And checking is the activity most organisations never resourced, never measured and never named, because historically it was the small part of the job. When writing was the bottleneck, review was a courtesy at the end. Now that writing is nearly free, review is the entire constraint, and it is staffed as though it were still the courtesy.
That is the actual shape of the problem. Generation became cheap. Verification did not, and the budget never followed the work.
Amplifier, not accelerator
The framing DORA published in March 2026 is the most useful sentence available on this subject, and it belongs in any board discussion about AI investment: AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.
Read as a warning about sequencing, this is unambiguous. If test coverage is thin, review practice informal and the release process a person rather than a pipeline, the assistant repairs none of it. It feeds it faster.
Organisations that already deliver well get more of what they already do. Organisations that do not get more of that too.
It is worth being precise about the status of that claim. The amplifier framing is the authors’ interpretation, not a measured result, and the published material gives no magnitude for the effect on either throughput or instability. It should be used as a lens, not quoted as a statistic.
Why this is a governance question before it is an engineering one
The instinct, on reading that stability is falling, is to reach for a technical fix: more tests, stricter linting, another gate in the pipeline. Those help. They are also not what distinguishes the organisations where this works.
What distinguishes them is that someone owns the answer to a question that sounds bureaucratic and turns out to be operational: when a change reaches production, who decided it was ready, and on what evidence? In a team where generation is human and slow, that question answers itself socially — everyone knows who wrote it. In a team where a substantial share of changes originate from an assistant, the social answer quietly stops being available, and nothing replaces it unless it is designed.
What separates the two groups
Nothing in this research points at the model as the differentiator. What distinguishes teams that gain from agentic coding is unglamorous and entirely within their control.
They have written rules specific enough to be enforceable: what the assistant may change, what it may never decide alone, and what has to exist before a change counts as finished. They have verification that actually runs rather than verification that is assumed, which means tests against a real environment and a release path that does not depend on who is in the office. And they measure delivered work — what passed review, reached production and stayed there — rather than what was generated or how fast the week felt.
Improving AI delivery stability turns out to be a matter of practice, not procurement. None of it arrives with a licence, and that is precisely why so few organisations have it.
Source: DORA, State of AI-assisted Software Development (2025) and DORA Insights, Balancing AI tensions, 10 March 2026.