TL;DR: Google Cloud's DORA team just published The ROI of AI-assisted Software Development. I found it because two people I follow were debating it on LinkedIn — and reading it gave me an odd feeling: the report describes, in research vocabulary, the year my team just lived through. The J-Curve, the verification tax, AI as an amplifier rather than a miracle. The diagnosis is right. The numbers are vendor numbers — and the report admits it itself. Read it for the framework, not for the "39% ROI".

In March I wrote that the SDLC is dead, then that coding was never the job. In May I described how AI became a team reflex — a field report, not a manifesto. Three articles written from inside a team, with no external data to back them. Just what I was seeing.

Then, this week, the DORA report started circulating on LinkedIn. Robert Schrader, Head of Software Engineering, posted a measured analysis of it. Jean-Rémy Revy, Head of Architecture at Ippon Technologies, relayed it, saying it went "exactly in the direction" of what he had been arguing for months. Two practitioners, two different companies, the same conclusion. I clicked. I read all 60 pages. And I found, set down in black and white by a research team, almost everything I had described by feel.

One honest disclaimer first: this report is published by Google Cloud. The "delta" team that co-signs it is their consulting practice, and every chapter ends with a "contact us". It is, at the same time, genuine research synthesis — DORA is the lineage of Accelerate and the four key metrics, a brand that earned its credibility — and sales collateral. You can hold both ideas at once. You have to, in fact, to read this document correctly.

"AI is an amplifier" — the line I'd already written

The report's central thesis fits in one sentence: AI is an amplifier. It magnifies the strengths of organizations that work well and the dysfunctions of those that struggle. The return on investment doesn't come from the tool — it comes from the system around it: the quality of the internal platform, the clarity of workflows, the alignment of teams.

"AI will not fix a broken engineering system."

I wrote almost the exact same thing in the previous article: "garbage context in, garbage debate out". An agent that generates code three times faster inside a team with no solid pipeline does not produce three times the value. It produces three times the code, queued in front of an already-clogged manual review. The report says it bluntly: code is a liability, not an asset. Generating more code without guardrails isn't creating value — it's accelerating the accumulation of technical debt.

This point looks obvious once written. It is not obvious in the mind of a committee that just bought a thousand licenses expecting a miracle. The report's answer to them: the miracle is not in the license.

The J-Curve finally has a name

In the previous article, I described a dip: the first weeks my team adopted agents, we got less productive before getting more productive. I had no word for it. The report has one: the J-Curve.

The idea: when a team adopts a major technology, its performance temporarily drops before climbing back — and then past the starting point. The curve draws a J. DORA calls that dip "the tuition cost of transformation". Three things deepen it:

  • The learning curve — the time spent learning the tools, readapting workflows, moving from a hacked-together prompt to real work on context and specification.
  • The verification tax — the time spent reviewing generated code you're not sure about. The more code the AI produces, the bigger the review burden.
  • Pipeline adaptation — tests, approvals, the whole downstream that has to absorb a suddenly higher volume.
Value realized Time Time zero Baseline The learning curve The verification tax Pipeline adaptation Exponential growth where is your team? A dip to fund, not a failure to stop.

The trap is the dip. The report is very clear on this: most AI initiatives fail not because the technology is bad, but because leadership mistakes the dip for failure and cuts funding at the worst possible moment. Jean-Rémy Revy summed it up exactly on LinkedIn: the J-Curve "materializes the fact that the initial investment often costs you a bit of performance, before it eventually catches up". If you launch AI in your organization, you're signing up for that dip. Better to know it, and to budget for it.

"The dip is not a failure signal. It's the price of the ticket."

One aside: the "verification tax" is exactly what my panel of persona sub-agents pays on purpose. Rather than letting the review burden dilute into Friday afternoons, we concentrate it into an explicit mechanism. The tax exists — DORA is right — the question is whether you pay it consciously or let it bleed you in silence.

The ROI math, and the number I don't trust

The core of the report is an ROI calculation model, with a worked example. A 500-person organization, $100M of product revenue. First-year investment: $8.4M. Value generated: $11.6M. First-year ROI: 39%. Payback in eight months. And, as the cherry on top, "Google Cloud customers see an average of 727% ROI over three years".

There. Now, why I don't trust that number.

Of the $11.6M of value, $11M comes from a single lever: "headcount reinvestment capacity". In plain terms: it assumes every developer gains 12.5% of their time (about one hour a day) and values that hour at the fully-loaded salary cost. The entire ROI rests on two stacked assumptions: (a) that 12.5% time gain is real, and (b) that hour is actually reconverted into value. At 100%. But a "saved" hour has an annoying habit of being swallowed by meetings, context-switching… or by the verification tax itself. If real conversion is 50%, the ROI is halved.

As for the 727% over three years: those are Google Cloud customers, who stayed three years with Google Cloud, and who agreed to be measured. Total survivorship bias. The "78% of executives who report a return", the "88% of agentic adopters seeing positive returns": executive self-reporting, not delivery metrics.

The most honest part of all this is that the report says so itself. It calls its own numbers a "high-uncertainty estimate" meant "to spark a conversation", and quotes the classic line: "all models are wrong". So I take it at its word. What's useful in this chapter isn't the 39%. It's the structure: the formula, the value levers, the list of costs everyone always forgets — including a "J-Curve cost" line that nobody ever puts in the budget. The deliverable is the method. The percentage is decoration.

"Endorse the reasoning framework. Refuse the precise number."

The real problem is measurement

This is the point Robert Schrader raised on LinkedIn, and he's right to push it forward. The report gives you formulas — but an ROI formula needs two things: a baseline (the "before") and a target (the "after"), both grounded in real delivery metrics.

And that's where it gets hard. Getting reliable numbers is "especially hard in heterogeneous organizations", with fragmented system landscapes, disparate tool chains, and revenue drivers other than a software product or e-commerce. DORA itself warns that these metrics must be applied in context, at the application or service level — comparing two very different systems means nothing.

Translation: half the companies that will want to compute their AI ROI have no baseline. They never measured their lead time, their deployment frequency, their change failure rate before. Without that "before", the J-Curve is invisible: you cannot prove a climb you never measured descending.

Jean-Rémy Revy put it in a sentence I'm keeping: "No ROI without adopting an adequate methodological framework and aligned control tooling." That's the whole point. The report sells a calculation; the calculation assumes a measurement discipline most organizations don't have. The ROI of AI is, first, an instrumentation problem.

The findings that flatter no one

Two of the report's findings flatter no one — and that's exactly why they're the most credible.

First: AI helps far less on the code you actually maintain. The cited research (Stanford) gives 35 to 40% productivity gains on simple, greenfield tasks. On legacy, complex, brownfield code? 10% or less. For someone like me, working on regulated healthcare software several years old, that's the only number that matters. The "40%" that makes the headlines describes a blank slate. The real job happens in the code that already exists — and there, the gain is honest but modest.

Second, and even more uncomfortable: AI adoption is associated with a rise in delivery instability. In the 2025 DORA research, more AI goes hand in hand with a rising change failure rate. The report's worked example bakes it in: the rate goes from 5% to 6%, costing $344,000 of "instability tax". The delta looks small. The fact is not: a vendor selling AI tooling admits, in black and white, that its technology, poorly governed, degrades stability. It's probably the most credible sentence in the document — because it survives the commercial-interest filter. When a seller says something against their own interest, you listen.

Don't lay people off

The report is firm on one point, and I want to underline it because it's the most important: do not reduce headcount. The productivity gained must not be used to lay people off; it must free capacity for innovation.

For once, the argument isn't moral, it's financial — and airtight. The report's ROI model rests almost entirely on "headcount reinvestment capacity". If you lay the people off, you delete the biggest line of your own ROI case. You destroy the value you claimed to create. And you destroy it precisely at the bottom of the J-Curve — meaning you fire the people paying the verification tax and absorbing the learning curve, right before the climb.

The report reframes ROI in a way I find right: it is no longer "how many developers can I replace", but how much latent human creativity you can unlock by offloading systemic toil to the agents.

"We don't measure AI by the code it writes, but by the bottlenecks it clears."

On my team, over six months, headcount didn't drop. It grew — interns and apprentices included. We ship more, we sleep better, and nobody was replaced by a machine. The report describes, in consulting-firm language, exactly what I watched happen.

What still belongs to humans

As in every article of this series, the honest part. Many things are not in this report — or are, but stay in our hands.

Reading the report as a skeptic. Nobody will do it for you. A document published by a vendor, with a calculator provided by the same vendor, is read with one hand on your wallet. Not with contempt — DORA deserves a serious read — but with judgment.

Building and holding the baseline. The measurement tooling, the methodological framework Revy talks about: it isn't bought, it's built. It's slow, unglamorous engineering work, and it's the prerequisite to any serious ROI calculation.

Reconverting the gained time. The freed hour does not turn itself into value. Someone has to decide, deliberately, that it goes into tests, into the domain, into innovation — and not into one more meeting. The model's $11M only exists if that decision is made, and held.

Holding the architecture and deciding what to build. No agent has the strategic read of a product. The framework that AI amplifies — we are the ones who write it.

What to do Monday morning

If you lead a team and you want to take something concrete out of this report, here's the order I'd suggest:

  1. Measure your DORA baseline now. Lead time, deployment frequency, change failure rate, recovery time. Before adding any AI. Without the "before", you'll never prove the "after".
  2. Put the J-Curve in the budget. An explicit "transformation cost" line, with an announced duration. And get leadership to pre-commit to not cutting funding during the dip.
  3. Track leading indicators, not ROI. Experiment frequency and delivery metrics will tell you in week 3 whether you're on the curve. ROI is an eight-month story — too late to correct course.
  4. Audit your context layer. Is your internal platform a real product? Is your data AI-accessible? If the answer is no, that's where the spend goes — not into more licenses.
  5. Run the calculator with YOUR numbers. In three scenarios: conservative, realistic, optimistic. The deliverable is the range and the discipline of the exercise. Not the percentage you'll show in the steering committee.

Conclusion

Six months ago, I wrote a field report and ended it with: "if you thought I was being theoretical — I wasn't." Today, an external research team, with no interest whatsoever in flattering me and which obviously never read my blog, publishes the same diagnosis. This is not vindication. It's a convergence — and a convergence is worth more than vindication, because it comes from elsewhere.

The report's diagnosis is solid: AI is an amplifier, the J-Curve is real, foundations come before the tool, and code stays a liability. The arithmetic, on the other hand, is a conversation starter — not a promise. Read the report for the framework. Run the calculator for the discipline of putting your own numbers in. And forget the 39%.

One last question, the only one that really matters: which part of the curve is your team on, right now? If you can't answer, that's fine — it just means you have no baseline. Start there. The rest will follow.

Read the rest of the series: The SDLC Is Dead — why the process was always waste. Coding Was Never the Job — what the engineer becomes when the syntax disappears. AI Became a Team Reflex — what an AI-native team looks like on a Tuesday. Six Months of Agents — the checkpoint where I grade this J-curve against the data, and correct one call. The Backlog Was Never the Job — what the amplifier does to the product role. Doctrine Compounds. Models Don't. — where the foundations this report demands actually live. The Tests Passed. Nothing Happened. — the defect that has no symptom, and what catches it instead of reading.

Sources