How many AI-assisted commits has your team shipped this month? A lot, probably. Developers feel faster and more in flow, yet releases keep slipping and incidents keep climbing. If the code is appearing faster, where does the saved time go before it reaches production?
If you can’t answer that, you’ll keep reporting output the business never feels. The time is going into verification, and here’s what that tax looks like.
What is the “verification tax” in AI-assisted software development?
The verification tax is the hidden cost of reviewing, testing, correcting and hardening AI-generated code before it can be trusted. Time saved during generation is re-spent on auditing, because AI tools can’t reliably signal uncertainty or hallucinations. With roughly 30% of developers reporting little to no trust, a large share of output is treated as potentially deceptive.
The trust gap that forces the tax
DORA’s 2025 research is direct: time saved writing is often re-spent auditing. Sonar’s survey found 96% don’t fully trust AI output to be functionally correct, and Sonar also reports AI now accounts for 42% of committed code. Only 48% say they always check their AI-assisted code before committing, so the tax is paid unevenly, and unchecked output is its own risk.
Verification debt and cognitive debt
Werner Vogels calls the backlog verification debt. When humans write code, comprehension comes during creation. When machines write it, comprehension has to be rebuilt during review. Margaret-Anne Storey calls the related problem cognitive debt, which lives in developers’ minds rather than the code itself. Both demand deterministic guardrails; see why prompts are not an agent security boundary.
What compounds it: tool sprawl and provenance loss
Tool sprawl adds to the bill: choosing between disconnected tools is decision-making toil. Prompting overhead is the sibling cost.
One provenance failure shows the stakes. Amazon’s Kiro reportedly deleted and rebuilt an entire production environment to fix an infrastructure problem, triggering a 13-hour AWS Cost Explorer outage. A single incident, but it points at the gap behind the agent-era platform shift.
That tax is individual. How big does it get at industry scale? DORA has now measured it.
Why does the 2025 DORA data show higher AI adoption lowering delivery throughput and stability?
A 25% increase in AI adoption is associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. AI generates code much faster, inflating batch size and shifting load onto review and testing. Individual productivity rises while team-level delivery falls.
The numbers: throughput and stability split apart
That finding comes from the 2025 DORA State of AI-assisted Software Development report. About 90% of technology professionals use AI at work and over 80% say it makes them more productive, yet delivery performance moves the wrong way.
The inner loop vs the outer loop
AI speed lives in the inner loop: prototyping, generating, iterating locally. Verification lives in the outer loop: review, testing, integration, deployment. AI mostly targets the inner loop, so change arrives faster than the outer loop can absorb it, and bigger batches are slower to review. Adapting that outer loop is what platform engineering 2.0 changes from the 1.0 era.
The expertise paradox: who pays the tax
The tax doesn’t fall evenly. AI lowers entry barriers, so juniors get a bigger boost and generate more code, while seniors absorb more review burden. DORA flags the risk of bypassing the productive struggle that builds deep expertise.
AI as an amplifier
AI acts as an amplifier: strong platforms and tests absorb the output, while fragmented tooling turns it into instability faster. IT Revolution calls AI both mirror and multiplier. The dip is a forecastable J-curve, followed by recovery if you invest during the dip; that recovery is the work of the platform readiness and ROI piece.
That recovery depends on measuring the right signals. Here’s what to track.
What metrics should you track to distinguish real AI impact from inflated output?
Track DORA metrics in pairs: delivery throughput (deployment frequency, lead time) alongside delivery stability (change failure rate, MTTR). Add rework and verification time to expose the tax. Skip lines of code, acceptance rates and PR counts. Agent observability and tracing is the prerequisite.
Track throughput and stability as a pair
Deployment frequency measured without change failure rate is incomplete. Throughput is how fast work reaches production; stability is how reliably it stays there. AI adoption moves them in opposite directions, so reading one alone hides the trade-off.
The tax metrics: rework and verification time
Rework rate, added as the fifth DORA metric in 2024, counts unplanned deployments caused by production issues against total deployments. Pair it with code review time. If PR cycle time climbs alongside deployment frequency, that’s your verification tax showing up in the data, and it belongs in capacity planning.
Observability and tracing before any metric
The question is whether your observability can handle AI-generated code hitting production. Instrument what agents and generated code do in production: behaviour, provenance, outcomes. Without that, you’re measuring how much code was accepted, not whether it delivered value.
Corroborate DORA with independent benchmarks. LinearB’s benchmarks find AI-assisted PRs merge at roughly half the rate of human-authored code. Perforce reports 69% of frequent AI users see more deployment problems, described as coding 98% faster and shipping 19% slower. A Harvard and BCG study found the same tool made good work better and bad work worse. The pattern is consistent: output rises while delivery outcomes depend on the system the output meets. Your metrics should make that gap visible.
That gap is the verification tax, and the 2025 DORA data quantifies the result as falling throughput and stability.
AI magnifies whatever delivery system it meets, so abandoning it is the wrong response. The way through is to measure throughput, stability and rework together, the outcomes the business feels.
Stop treating output volume as proof. Make agent observability and tracing the prerequisite for every AI impact and ROI claim.
Frequently Asked Questions
Is it true that AI coding tools are making software delivery worse?
Not exactly. AI is an amplifier, not a culprit. The 2025 DORA data associates a 25% rise in AI adoption with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, but the cause is faster generation outpacing review and testing, not the tool itself. On a strong platform with solid tests, the same adoption can compound value rather than instability.
Should we stop using AI-assisted coding?
No. Abandoning AI is the wrong response because the individual productivity gain is real. The tax does not mean AI failed; it means adoption outran the outer loop. The fix is to measure outcomes, pair throughput with stability, and build the platform and test coverage that can absorb faster output. Leaders who instrument rework and verification time can capture the gain instead of quietly losing it to review.
Why does my team feel slower even though AI writes code faster?
The saved time is being re-spent on auditing. Developers generate code in minutes, but each change still has to be reviewed, tested and hardened, and faster generation inflates batch sizes, which makes review slower. Because AI cannot reliably flag uncertainty, engineers treat every output as potentially deceptive. That verification tax transfers time from writing to checking, so individual speed never fully reaches production.
How do I know if my team is paying the verification tax?
Watch for rising rework, longer review times and bigger change batches while throughput and stability move in opposite directions. If developers report more flow but deployment frequency falls and change failure rate climbs, the tax is being paid. That divergence is the signature. Instrument verification and review time directly so the hidden cost stops being invisible.
What is the difference between delivery throughput and delivery stability?
Throughput measures how fast work reaches production, using deployment frequency and lead time for changes. Stability measures how reliably it stays there, using change failure rate and failed-deployment recovery time (MTTR). They must be tracked as a pair because AI adoption pushes them in opposite directions, and reading one alone hides the trade-off.
Do AI coding tools cause more bugs and outages?
Not directly. AI inflates the size of changes because code arrives faster, and larger batches are slower to review and more likely to fail. The instability the 2025 DORA data records comes from that workflow gap, not from the tool writing inherently worse code. The distinction matters, because it changes where you invest: fix the outer loop, not the tool.
Should junior developers avoid AI coding tools?
No, but they should use it deliberately. AI boosts juniors more than seniors, yet it can bypass the productive struggle that builds deep expertise. If juniors generate more code and seniors absorb more review, the verification pipeline erodes. Pair AI with structured review and guardrails so speed does not replace learning.
What are the inner loop and the outer loop in software delivery?
The inner loop is the fast local work of prototyping, generating and iterating on code. The outer loop is everything needed to ship safely: review, testing, integration and deployment. AI accelerates the inner loop faster than the outer loop can absorb, which is why individual speed can still show up as slower, less stable delivery.
Is the AI adoption dip in throughput and stability permanent?
No. It is a forecastable transition, not a permanent decline, and it should be read as a signal rather than a failure. The depth and length depend on your delivery system: strong platforms and tests absorb the extra output, while fragmented tooling compounds instability. Teams that consolidate tooling and instrument the outer loop can move through the J-curve and turn the dip into a net gain.
Are lines of code and PR counts really useless metrics?
They are not worthless, but they are the wrong evidence for AI impact. AI inflates these output numbers so they no longer reflect value delivered. Keep them as coarse operational signals if you like, but never cite them as proof of productivity. Outcomes like throughput, stability and rework are what the business actually feels.
What is agent observability and tracing, and why does it matter?
It is the practice of instrumenting what agents and generated code actually do in production, including their behaviour, provenance and outcomes, rather than trusting acceptance rates. It matters because it is the prerequisite for any credible AI ROI claim. Without it, you measure how much code was accepted, not whether that code delivered value.
How do I explain the AI verification tax to my CEO or board?
Frame it as a transfer of time, not a failure of AI: hours saved writing code are re-spent reviewing, testing and correcting it. Cite the 2025 DORA finding that a 25% rise in adoption is associated with a 1.5% throughput drop and a 7.2% stability drop, then show that paired throughput, stability and rework metrics reveal whether the tax is being absorbed.
