The Verification Tax Nobody Budgets For
96% of developers do not fully trust AI-generated code to be functionally correct. Somebody has to check, that checking is work, and it appears on no invoice.
There is a number in DORA's research that should be discussed far more than it is.
96% of developers do not fully trust that AI-generated code is functionally correct.
Not 96% dislike it. Not 96% think it needs review. Ninety-six percent do not fully trust that it works. And in the same body of research, 90% of technology professionals use AI at work and more than 80% believe it has made them more productive.
An industry has standardised on a tool almost nobody fully trusts. That is not hypocrisy — it is a rational response to a tool that is genuinely useful and genuinely unreliable. But it has a consequence, and the consequence has a cost that appears on no invoice.
Somebody has to check
If you do not trust the output, you verify it. Verification is work. That work has to happen somewhere, and DORA gives it a name: the verification tax — time saved during creation, re-spent on auditing.
Here is why it is invisible. A developer reading AI output looks precisely like a developer thinking. Same posture, same screen, same silence. No velocity metric distinguishes them. No standup report says "I spent forty minutes establishing that yesterday's suggestion was wrong." Story points do not have a field for it.
So the saving is legible — the code appeared instantly, everyone saw it — and the cost is not. That asymmetry is the entire mechanism by which teams conclude AI is working while their delivery rate stays flat.
Two kinds of review, and only one of them is new
Review has always existed, so it is tempting to conclude nothing has changed. Something has.
Judgement review is what code review was for. Is this the right approach? Does it fit our patterns? Will we regret this in a year? It requires a senior person and it produces value.
Correctness verification is the new job. Does this function exist? Does this API take these parameters? Does this actually do what it says? Historically, a human author had already established most of this — they wrote it, so they knew whether the method existed. AI output arrives with none of that assurance and considerable fluency, which is the worst combination for a reviewer, because fluency suppresses suspicion.
Teams that feel review has become exhausting are usually not doing more judgement review. They are doing correctness verification and calling it review, and it is a genuinely worse job.
What it costs, concretely
You can estimate your own in an afternoon.
For two weeks, ask reviewers to record two numbers per pull request: minutes spent establishing that the change is correct, and minutes spent judging whether it is good. Nothing else — no tooling, no process change.
Most teams that run this are surprised twice. First by the ratio, which usually runs heavily toward correctness. Second by the total, which is typically larger than any time saving they attributed to AI in the same period.
Then multiply. If verification runs to an hour per non-trivial change and your team merges forty a week, that is a full-time engineer's week spent establishing that generated code does what it claims. At a loaded cost of, say, $150,000 a year, one FTE of verification is a six-figure line item that exists in no budget.
The evidence it is not just perception
If verification were merely a feeling, code-level signals would look normal. They do not.
DORA's data shows copy-paste rates climbing from 8.3% in 2021 to 12.3% in 2024, refactoring rates collapsing from roughly 24% to under 10%, and duplicate code blocks rising about eightfold year over year in 2024.
Read those together. More code is being copied rather than adapted. Less of it is being consolidated. Duplication is compounding. That is not what a codebase looks like when a team has spare capacity — it is what one looks like when everybody is at capacity and consolidation is the first thing to be dropped.
And METR's randomised controlled trial provides the outcome measure: sixteen experienced developers, 246 real tasks, 19% slower with AI — while believing they were 20% faster. The verification tax is a plausible mechanism for exactly that result.
Why the obvious fixes disappoint
"Better prompts." Improves the first draft. Does not tell the reviewer whether this particular output is correct, which is the expensive part.
"A stronger model." Raises the average, and may make things worse for verification: a model that is right 95% of the time trains reviewers to skim, so the 5% ships. Reliability that is high but not total is the hardest regime to review in.
"More tests." Genuinely helps for behaviour you anticipated. Verification is largely about behaviour you did not anticipate — the interaction two modules away that nobody wrote a test for because nobody knew it existed.
The reason these disappoint is that they all address generation. Verification is a comprehension problem: the reviewer must understand the system well enough to know whether this change is right within it. Nothing that improves output quality touches that.
What actually reduces it
Two things move the number.
Evidence attached to claims. If a suggestion arrives with a traceable basis — this is the function, here is where it is defined, here is what already depends on it — verification becomes a two-minute audit instead of a re-derivation. The reviewer checks the citation rather than reconstructing the reasoning. Most of the tax is re-derivation, and citations remove it.
Shared understanding rather than per-person reconstruction. When every reviewer independently works out how the system behaves, the organisation pays for that reconstruction once per reviewer per change, forever. When it is established once and reusable, verification becomes checking a claim against a shared reference — which is a smaller job than forming a private mental model from scratch.
Neither of these is about generating better code. Both are about the reviewer's cost of knowing whether the code is right, which is the actual bottleneck and the actual line item.
The question for your next planning cycle
You have almost certainly budgeted for AI tooling. Have you budgeted for the checking?
If not, the money is being spent anyway — out of your senior engineers' weeks, invisibly, in an activity nobody logs and no dashboard shows. Making it visible is free and takes two weeks. Deciding what to do about it is the actual strategic question, and you cannot answer it while the number is unknown.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
What is the verification tax in AI-assisted development?
DORA's term for time saved during code creation being re-spent on auditing the result. It is structurally invisible: a developer reading AI output looks the same as a developer thinking, and no velocity metric separates them — so the saving is legible while the cost is not.
How do I measure the verification tax on my team?
For two weeks, have reviewers record two numbers per pull request: minutes spent establishing the change is correct, and minutes spent judging whether it is good. The ratio and the total both tend to surprise teams, and the total is often larger than the time saving attributed to AI in the same period.
Why doesn't a better model reduce verification work?
It can make it worse. A model that is right 95% of the time trains reviewers to skim, so the remaining 5% ships. Reliability that is high but not total is the hardest regime to review in, because fluency suppresses suspicion exactly when suspicion is warranted.
What actually reduces the cost of checking AI output?
Evidence and shared understanding. When a suggestion arrives with traceable sources, verification becomes a two-minute audit rather than re-deriving the reasoning. And when how the system behaves is established once rather than reconstructed privately by every reviewer, checking a claim replaces building a mental model from scratch.
Is 96% distrust of AI code a sign teams should stop using it?
No — it is a sign the checking work is real and should be budgeted. Teams use these tools because they are genuinely useful. The mistake is booking the productivity gain while leaving the verification cost unmeasured, which is how delivery rates stay flat while everyone reports being faster.
Related articles
The 19% Problem: What a Controlled Trial Revealed About AI and Developers
A randomised controlled trial found experienced developers were 19% slower with AI — while estimating they were 20% faster. The detail everyone skips explains why.
What to Measure When AI Writes the Code
Most engineering dashboards were designed for a world where producing code was expensive. Six numbers that still mean something, and three things to stop reporting.
Knowing What Breaks Before You Write the Code
Impact analysis fails because reference lists answer at the wrong altitude. What a useful answer contains, why it must run in both directions, and how to improve this without new tooling.