Google's DORA team surveyed close to 5,000 technology professionals in mid-2025 for the State of AI-assisted Software Development report. Ninety per cent of respondents now use AI in their daily work, up fourteen points on the previous year, at a median of about two hours a day. That is roughly a quarter of the working day spent with an assistant.

Two findings sit next to each other in that data, and the pairing is the whole story.

The first is good news, and it is a reversal. In the 2024 report, AI adoption correlated with lower delivery throughput. In 2025 that flipped. AI now correlates with improved throughput, better product performance, and more time spent on work people consider valuable.

The second finding did not flip. As RedMonk's analysis put it, AI adoption is not merely failing to improve delivery stability, it is currently associated with making it worse. IT Revolution's read of the report reaches the same place: teams have adapted for speed, and the systems underneath them have not evolved to handle what that speed produces.

I have written on this blog before about how the DORA metrics get misread, and I do not want to repeat that argument here. This is a different one. It is not about how we measure. It is about what the measurement is now telling us, and about a gap in where the industry has spent its money.

A control system has a speed requirement

There is a line in the DORA report that stopped me, and it is not from software at all. The report reaches for the Nyquist stability criterion from control theory, which holds that a control system has to operate at least twice as fast as the system it is controlling.

Sit with that for a moment against what has actually happened.

The system being controlled is your delivery pipeline: the rate at which change enters production. AI has made that faster, and the 2025 data now confirms it at organisational scale rather than just as a feeling. The control system is everything that tells you whether the change was any good: your tests, your review, your monitoring, your ability to notice a regression and trace it back to what caused it.

We accelerated the first one substantially. We have barely touched the second. When the thing being controlled speeds up and the controller does not, the control condition breaks, and the system oscillates. In our terms, it becomes unstable.

That is not a metaphor I have imposed on the data. It is the shape of the finding.

The bill for a lopsided investment

Look at where three years of tooling effort has gone. Autocomplete. Chat-based problem solving. Agents that write code. Agents that open pull requests. Nearly all of it aimed at the moment of creation.

Now look at what happens after the code exists. When something breaks at eleven at night, the assistant that wrote the function has no idea the function is now failing. It cannot see the error rate. It does not know what deployed forty minutes ago. It has no view of the memory limit, the connection pool, or which service calls the one that fell over. The AI that helped build the system is completely blind to the system running.

Telemetry from Faros across 22,000 developers puts a number on the downstream cost. Their 2026 data shows epics completed per developer up 66.2%, which is a real organisational gain rather than a self-reported one. In the same dataset, median time in pull request review rose 441%, against 91% in their previous year's numbers.

Work is not disappearing. It is relocating. We made writing cheap and left verification exactly as expensive as it was, and now the queue has moved to review, to QA, and eventually to production.

Amplification cuts both ways

The central message of the 2025 report is that AI does not fix an organisation, it magnifies whatever is already there. Strong teams get meaningfully stronger. Teams with weak feedback loops and brittle architecture get faster at producing the thing that was already hurting them.

I find this the most useful framing available, because it makes the instability finding predictable rather than mysterious. If your control system was marginal at ordinary speed, it fails at double speed. Nothing new broke. The margin simply ran out.

It also explains the finding that gets less attention: AI showed no measurable effect on friction or burnout. Those are properties of the organisation, not of the workstation. A faster editor does not touch them. That result should end the argument that individual tooling is a substitute for fixing how a team actually works.

The report's accompanying capabilities model points in a consistent direction. The things that determine whether AI helps you or hurts you are mostly not AI things: the quality of your internal platform, whether your data is accessible and trustworthy, how clear your organisation has been about where AI is and is not appropriate, and whether feedback reaches people fast enough to act on.

What the second half of the investment looks like

If the diagnosis is that creation outran verification, the fix is not a better coding assistant. It is closing the asymmetry.

Today your AI has deep access to one half of your world. It can read your repository, understand your architecture, and reason about your code in detail. It has essentially no access to the other half: what that code is doing right now, what changed recently, what is degraded, what the last deploy did to your error rate.

That asymmetry is not inevitable. It is a consequence of where the tooling arrived first. An assistant that can read your monitoring, your deploys and your infrastructure alongside your code is answering from the state of the system rather than from the shape of the source. I work at Frigga on Vörr, which exists specifically to close that gap, so treat that as an interested opinion. The argument stands regardless of whose product you use, and it is the argument the DORA data makes on its own: the returns come from the systems around the AI, not from the AI.

What I would take to a leadership conversation

Do not present the throughput improvement without the stability number. They came from the same dataset, in the same year, and separating them produces a business case that will be embarrassing within two quarters.

Ask what proportion of your AI budget went to producing change versus verifying it. If the honest answer is nearly all of it, you have found your instability.

Check whether your feedback loop got faster in the same period your delivery did. Not whether it is good. Whether it got faster. If it did not, the control condition is broken and the numbers are behaving exactly as they should.

The uncomfortable conclusion in this report is not that AI does not work. It plainly does, and the throughput reversal proves it. The conclusion is that we bought half a system and are surprised it wobbles.

Author note

I am Mohan Gopi, an Associate DevOps Engineer at Frigga Cloud Labs, where I work on Vörr, connecting code, cloud, and monitoring so that AI answers from the state of a system rather than from a guess. I wrote this because the industry keeps reporting the throughput win and quietly filing the stability finding somewhere it will not be read. The pattern I keep seeing is leadership treating AI adoption as the intervention, when the data says AI is only ever a multiplier applied to whatever discipline you already had. Read together, those two numbers will tell you precisely where your delivery system is thin, long before an incident does it for you. Read apart, they will let you build a very confident business case for going faster in the direction you were already struggling to control.

Let us connect on LinkedIn → Mohan Gopi

AI Made Us Ship Faster and Break More