AI speeds up what you write, not what you can deploy

Of the two things the DORA report said about AI in 2024, in 2025 it observed the opposite for one and exactly the same for the other. The one that did not move is the one that costs money: "AI adoption does continue to have a negative relationship with software delivery stability." More AI still comes with less delivery stability. Two consecutive reports, same sign.

It is worth saying up front what this is and is not about. It is not about whether AI works: we use it daily and we are not going to pretend otherwise here. It is about where the hours it promises end up. And the answer the available data gives is not "nowhere", which would be the sceptic's comfortable headline. It is rather more awkward: they end up downstream, in the part of the process almost nobody budgets for because it has no logo and no monthly subscription.

Two consecutive reports, one sign that does not change

The 2024 edition, with around 3,000 respondents and 75.9% of them already relying on AI for part of their job, estimated that a 25% increase in AI adoption came with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Those two figures were published in the same year in which nearly the whole industry was saying the opposite.

A year later, with nearly 5,000 professionals surveyed and over a hundred hours of qualitative data, the first number turned around: "Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance." Teams ship more. 90% of respondents use AI at work and over 80% say it has raised their productivity. 30% report little or no trust in the code it generates — "a slightly lower percentage than last year", the report notes — and stability stayed where it was: negative.

Before building anything on top of it, the honest caveat: this is a survey, not an experiment. These are correlations over answers from people rating themselves, with everything that drags along. That 80% perceived productivity is exactly the kind of figure to distrust, which is why it is worth looking at the recent work that, instead of asking, put a clock on it.

The experiment that did put a clock on it

In July 2025, METR published a randomised trial with 16 experienced developers and 246 real tasks on large open-source repositories — averaging over 22,000 stars and more than a million lines — that those people had been contributing to for years. Not beginners on a new project: people on home ground. With AI allowed, they took 19% longer.

What makes that study memorable is not the 19%. It is the rest: before starting, participants forecast that AI would cut their time by 24%; after doing the tasks and having been slower, they still estimated a 20% improvement. They had lived through the whole experiment and did not notice. Between what the clock said and what they remembered there is not a difference of degree: there is a change of sign. And decisions to buy tools, headcount and licences are always made with the second one.

And now the part almost nobody quotes when they use this study as a weapon, starting with those who use it against AI. The authors themselves say they do not claim the result applies to most developers or to other domains, and describe their work as "a snapshot of early-2025 AI capabilities in one relevant setting". And in February 2026 they went considerably further: they distanced themselves from their own number.

What they published on 24 February 2026 is this: between 30% and 50% of participants told them they were not submitting some tasks because they did not want to do them without AI, which biases the tasks that did enter the experiment against the tool; and of their second trial's estimates they write that "our estimate reported above is a lower-bound on the true productivity effects of AI on these developers". That second trial, started in August 2025 with 57 developers, 143 repositories and over 800 tasks, gives −18% for the original participants (confidence interval −38% to +9%) and −4% for the new ones (−15% to +9%): two intervals that cross zero. METR calls its own data "an unreliable signal" and adds that, from what participants tell them, developers in early 2026 are likely getting more of a speed-up from AI than their 2025 estimate showed.

So no: the 19% does not prove AI slows you down, and anyone using it this year as evidence of that is quoting a number its own authors have stepped back from. What is left standing is duller and more useful: you do not know whether it slows you down or speeds you up until you measure it, your impression is not a measurement, and not even a team whose job is measuring this gets an interval that does not cross zero. If they cannot assert it with 800 timed tasks, your team's feeling in Monday's meeting cannot either.

Where the time went: into review

DORA sums it up in a sentence that explains both results at once: "time saved in creation is frequently re-allocated to auditing and verification." Time saved writing gets reassigned to checking. And the qualitative interviews contain the lines you hear in any team on a Tuesday afternoon: "I spend more time babysitting the AI and reviewing what it is trying to do," and this one, which is what really matters for what comes next: "Reviewing [another's] code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed."

That last point is our opinion and we flag it as such: reviewing a colleague's code is expensive, but reviewing a model's is worse, because you can ask the colleague why they did it that way and the answer changes what you look for. Ask the model and you get an equally fluent explanation whether it got it right or not. You review without the clue that saves the most time.

The sentence in the report that explains the bill

Plainly: AI accelerates, and that acceleration exposes the weaknesses you already had further down. Without robust control systems — serious automated testing, mature version control practices, fast feedback loops — more change volume turns into instability. Look at the verb: expose. It does not say AI creates the crack. It says it raises the flow until the crack shows.

It is exactly the idea we have been using for years to explain infrastructure resilience, which is why this report sounds so familiar to us: failure is inevitable, an outage is a design decision. A change that breaks something is going to happen, whoever writes it. Whether that change takes the service down, or stops dead in a test environment at eleven on a Wednesday, is not decided by the tool it was written with. It is decided by what you have underneath. The report's own summary puts it without anaesthetic: "AI doesn't fix a team; it amplifies what's already there."

What the 2026 report puts in money

On 11 May 2026 the same team published a return-on-investment report. Precision matters here, because it is a model, not a measurement: for a 500-person engineering organisation it models around $11.6m of first-year return against $8.4m of investment — a 39% return and roughly an eight-month payback. We have not audited that model and we do not present it as fact: we quote it for what is inside it.

Inside it there are two things more interesting than the total. The first is a negative line item, and it needs reading carefully because it is an assumption of the model rather than a finding: in the calculator's example the change failure rate is assumed to go from 5% to 6% after adopting AI, and that single percentage point is booked as $344,000 of cost, on the reasoning that more code moving faster "can overwhelm existing deployment pipelines and manual review gates". One point. The second is the conclusion, which reads like a warning: "The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams."

If your company has twelve people in development, those millions tell you nothing: you do not divide them by forty and get your numbers. What does carry over is the order of the causes. That the greatest return sits not in the tool but in the platform underneath is an uncomfortable claim for anyone who has just signed licences for the whole team and has not touched their deployment process in three years. It is the same conclusion we reached in July by a different route, when Gartner worked out how many agent projects would be cancelled before the end of 2027 — there the cause was cost and the lack of a baseline; here the data and the sources are different and the result points the same way.

The four things that have to take more flow

This is not a list of good intentions: each point carries its own measurement, because without one you are back to the original problem — believing you are faster without being faster.

None of the four is new and none has AI in it. They are the same ones we asked for before the problem existed, and that is precisely the point: what has changed is not the list, it is the hurry. The same goes for the platform's own calendar — anyone running Kubernetes knows the version expires on its own, whether you look or not — and change volume will not wait for you to finish building what is missing underneath.

When none of this applies to you

Time to declare the conflict of interest: we sell platform, CI/CD and on-call. When somebody like us tells you "you need more platform", look at who is billing. So here is the honest part: if your team is three people, you deploy once a month and the last backup restore you tested worked, do not touch anything. Building pipelines for a flow you do not have is another way of spending badly, and one you pay for in complexity every single month. You size the platform by the real change flow, not by the one you would like to have next year.

What is worth examining closely is whatever came in through the side door. The AI pilots somebody set up "just to try" and which ended up carrying real work have a bill of their own, and we have already written about what happens when nobody switches them off: a pilot in production with no owner, no update window and no inventory is not an experiment, it is a service nobody has agreed to maintain.

The question that works in a steering meeting

The usual question is "how much does AI save us?", and we have seen that it gets answered with a perception which, in the first clocked experiment, got the sign wrong. The useful one is different: how many more changes per month can what we have absorb without the failure rate going up? It has the advantage that it can only be answered with numbers that either exist or do not. And if the answer is "we do not know, because we do not measure the failure rate", there is your first job of the quarter. It has no AI in it, it will not make a press release, and it decides whether the rest is worth anything.

Sources (verified on 2026-09-27): the quotes "Unlike last year, we observe a positive relationship…", "AI adoption does continue to have a negative relationship with software delivery stability", "AI accelerates software development, but that acceleration can expose weaknesses downstream…" and "AI doesn't fix a team; it amplifies what's already there", together with the figures of nearly 5,000 respondents, 90% usage, 80% perceived productivity and 30% with little or no trust — the 2025 DORA report announcement on the Google Cloud blog. The lines on time being reallocated to verification, the two engineer quotes and "Working in small batches is a critical countermeasure…" — DORA, "Balancing AI tensions". The 2024 estimates (−1.5% throughput and −7.2% stability per 25% increase in adoption, with 75.9% usage among around 3,000 respondents) are taken from RedMonk's analysis of the 2024 report, not from the original PDF. The randomised trial, the 19%, the 16 people, the 246 tasks, the 24% forecast, the 20% estimated afterwards and the authors' caveat ("a snapshot of early-2025 AI capabilities in one relevant setting") — METR, 10 July 2025, with the paper at arXiv:2507.09089. The second trial (57 developers, 143 repositories and over 800 tasks, started in August 2025), the −18% and −4% with their confidence intervals, the declared bias of 30–50% of participants withholding tasks, "our estimate reported above is a lower-bound on the true productivity effects of AI on these developers", "an unreliable signal" and the expectation of a larger speed-up in 2026 — METR's note of 24 February 2026. The figures from the ROI report of 11 May 2026 ($11.6m, $8.4m, 39%, eight months, the 5%-to-6% step and the $344,000) and the quote "The greatest returns on AI investment…" are taken from InfoQ's write-up, which speaks of "the assumed change failure rate" — which is why it is presented here as an assumption of the calculator and not as a measurement; the report page is published, but we have not opened the PDF and we say so. What is ours and not the sources': the reading that the bottleneck moves to delivery, the comparison between reviewing a colleague's code and a model's, the four checks with their measurements, and the closing question. DORA's reports are self-assessed surveys, not controlled experiments, and we cite them as such. Cover photo: "LOOM office seating", Wikimedia Commons (CC0).