Every few years our industry gets very good at one step of a pipeline and then acts surprised when the next step falls over.
We did this with CI. We did it with containers. We are doing it right now with code generation, and the DORA team has put a name on the bill: the verification tax.
What the report actually says
Google Cloud’s DORA team, with delta innovation practice, published ROI of AI-Assisted Software Development (2026.01) on 11 May 2026. It models the economics of adoption for a hypothetical 500-person engineering organization.
The headline numbers are genuinely good. First-year ROI of 39%, on $11.6M of value against $8.4M of investment, with payback in roughly eight months and an average three-year ROI of 727%.
I want to be clear about that before the rest of this post, because the rest of this post is about the cost side and I do not want to be read as arguing against the thing. The return is real and it is large. What is also real is the shape of how you get there.
The report describes value realization as a J-curve — a temporary dip before the long-term gain — and calls that dip “the tuition cost of transformation.” It names three causes:
- The learning curve as teams adapt their workflows
- The verification tax — the effort of checking whether AI-generated code is reliable, secure, and architecturally sound
- Adjusting downstream processes for increased code volume
Number three is the one platform teams own. Number two is the one that lands in code review. And in the report’s illustrative model, the two combine into a line I have not seen quoted much:
a modeled downtime impact of $344,000, from change failure rate rising from 5% to 6% after AI adoption
That is a model, not a measurement of anyone’s production system. I want to be careful with it. But the mechanism it encodes is not speculative at all, and you can reason about it from first principles.
The mechanism, without the model
Think of your delivery system as a pipeline with a throughput ceiling at each stage:
- Generation — turning intent into a diff
- Review — a human deciding the diff is correct and appropriate
- Integration — CI, tests, merge queue
- Deployment — getting it to production safely
- Absorption — production tolerating it, and someone noticing if it does not
For twenty years, generation was the binding constraint. Everything downstream was sized for how fast humans could write code, and that sizing was mostly invisible because nothing pushed against it.
Codegen removed the ceiling on stage one. It did not touch stages two through five.
So the queue moves. And because the downstream stages are staffed and tuned for the old arrival rate, you get exactly what queuing theory says you get: longer waits, more work in progress, more context-switching, and more pressure on the humans doing the reviewing to go faster. Review under time pressure is worse review. Worse review means more defects reaching production. More defects reaching production is change failure rate.
Nothing about that requires AI-generated code to be worse than human code. It only requires it to arrive faster than the system can verify it. Even at equal quality, raising arrival rate through a fixed-capacity verification stage raises escaped-defect rate. The model can be excellent and the outcome can still be a worse CFR.
That is the part I think gets lost. This is not a “is AI code good enough” argument. It is a capacity argument.
The greenfield trap
There is a second number in the report worth planning around. Citing Stanford research, it puts productivity gains at:
| Work type | Gain |
|---|---|
| Simple greenfield tasks | ~35–40% |
| Complex legacy code | ≤10% |
Notice which of those describes your platform.
Nobody’s Kubernetes operator is greenfield. Nobody’s Terraform is simple. The Helm chart with fourteen conditionals that three people understand is the definition of complex legacy code, and it is precisely where a codegen assistant helps least — because the hard part was never typing, it was knowing what the fourteen conditionals were for.
This matters for rollout planning in a specific way: pilots are usually run on the easy stuff. Someone builds a new service, reports a 40% speedup, and that number becomes the business case. Then it lands on the platform team, whose work sits at the other end of the spread, and the projected gain does not appear — while the verification tax appears immediately and in full.
If you are sponsoring an adoption program, measure the pilot on representative work or expect the forecast to be wrong in a predictable direction.
Make verification cheaper, not review stricter
Here is where I part ways with the most common organizational response, which is to tighten review requirements: two approvers instead of one, longer checklists, more mandatory sign-offs.
That response makes the bottleneck narrower. You have identified the constrained stage and then reduced its throughput. It will feel responsible and it will make delivery worse.
The platform-side answer is to reduce the cost of verifying each change, and there are four levers.
1. Shrink batch size. This is the oldest answer in delivery engineering and it is still correct. A 40-line change can be reviewed properly in five minutes; an 800-line change gets an approving glance. If codegen has increased your average PR size, that alone will move your CFR — and PR size is something you can measure today and set a target on. Making small changes easy is platform work: fast branch environments, cheap deploys, trunk-based patterns.
2. Improve test signal, not test volume. AI is very good at generating tests, which is a trap, because it means you can now produce enormous quantities of tests that assert the implementation rather than the behavior. Those tests raise coverage, pass reliably, and catch nothing. The metric that matters is not coverage — it is whether a green build means the change is safe. Track escaped defects against build status and you will find out quickly.
3. Bound blast radius with progressive delivery. This is the highest-leverage item on the list, because it is the only one that works even when review fails. Feature flags, canaries, automated rollback on SLO burn. If a bad change reaches production and affects 1% of traffic for four minutes before automatic rollback, your change failure rate technically went up and your customers experienced nothing. That is the outcome you want, and it is bought with platform capability rather than human vigilance.
I made the adjacent argument about config changes still causing the biggest outages — the pattern is identical. You do not prevent bad changes by asking people to be more careful. You prevent bad outcomes by limiting what any single change can do.
4. Instrument the tax directly. You cannot manage what you have not measured, and “change failure rate” is too lagging to steer with. Add:
- Review latency — time from PR open to first substantive review
- Review depth — comments per hundred lines changed, trending over time
- PR size distribution — p50 and p95 lines changed
- Rework rate — how often a merged change is amended or reverted within 7 days
If review depth is falling while PR size is rising, you are accumulating verification debt and your CFR is going to move whether or not you are watching.
DORA metrics are necessary and no longer sufficient
One more thing worth saying plainly.
The four DORA metrics were designed for a world where code volume was roughly proportional to engineering effort. That assumption has quietly stopped holding. Deployment frequency going up used to be unambiguously good, because it implied smaller batches and better automation. It can now also mean “we are generating more change and pushing it through the same pipe.”
The four metrics still work — but you need to pair them with something that captures how much change is arriving and how well it is being verified. Otherwise a dashboard can show improving throughput and stable lead time while verification quality erodes underneath, and the first signal you get is an incident.
The same instinct applies here as with error budgets for autonomy: when a system starts producing change faster than humans review it, you need a budget-shaped control rather than a vigilance-shaped one. Vigilance does not scale. Budgets do.
What I would tell a platform lead
The generation step got 10x cheaper. Review, CI, deployment, and production absorption did not.
You are not being asked whether to adopt AI-assisted development — that decision is usually made above you and the ROI case supports it. You are being asked, implicitly, to absorb the consequences. So make it explicit:
- Say out loud that the constraint has moved to verification and deployment, and that capacity there is now the thing to fund
- Measure the tax with leading indicators, not just CFR
- Spend on blast-radius control before spending on review process
- Set the expectation that the J-curve dips first, so nobody panics at month three and nobody declares victory at month four
The teams that will do well here are the ones that treated delivery as a system before any of this started. If small changes were already easy, tests were already meaningful, and rollback was already automatic, the extra volume is a nice problem.
If they were not, codegen did not create that debt. It just started charging interest on it.
Related
- Config changes still cause the biggest outages — blast radius beats vigilance
- Error budgets for autonomy — budget-shaped controls for machine-speed change
- SLI, SLO, SLA, and error budgets — the measurement foundation
- Agent workflows belong in code, not just visual builders — the review-and-rollback argument for agent behavior itself
Source: DORA — ROI of AI-Assisted Software Development (2026.01), via InfoQ
Comments