The Verification Tax: What AI Code Studies Measured
You can no longer confidently prove that the code your agents wrote is production-ready. The pull requests arrive faster than you can read them, "the agent said it passed" is not evidence, and every unverified change you accept accumulates risk you cannot see. Meanwhile, every unrecorded decision gets re-litigated by the next session, so the review queue is not the only thing growing.
If you feel behind, the 2025-2026 research base says you are not imagining it. It also says something more useful: the burden is measurable, structural, and — with the right infrastructure — payable at machine speed instead of human speed. This post walks through what the major studies actually measured, with their denominators intact, because the qualifiers are where the real conclusion lives.
The asymmetry the white paper names
The Koinessa white paper opens on a structural claim: generation cost falls with every model release, while the cost of careful review, integration, and operation falls slowly if at all. The ratio of produced-to-verified work therefore worsens as AI adoption succeeds. A team that accepts unverified changes accumulates invisible risk; a team that reviews everything at human speed surrenders the throughput it adopted agents to gain.
That is the verification gap. What follows is the external evidence for it — eight clusters of studies, each with its own population and method limits, which collectively point the same direction.
DORA: throughput up, stability down, and the "verification tax"
DORA's State of AI-assisted Software Development reports an association between AI adoption, higher throughput, and lower delivery stability. Note the word: association. DORA's data does not establish that AI caused the stability drop — it establishes that organizations adopting AI ship more and break more, simultaneously.
DORA's 2026 insight, "Balancing the Tensions of AI-Assisted Software Development", gives the resulting operational burden its name: the verification tax. The faster generation gets, the more organizational capacity gets consumed verifying, integrating, and stabilizing the output. The tax is not paid by the model. It is paid by your reviewers, your on-call rotation, and your incident retrospectives.
Stack Overflow 2025: adoption is near-universal, trust is near-zero
The Stack Overflow Developer Survey 2025 AI section drew 33,662 respondents on the usage question — 84% are using or planning to use AI tools. But among the 33,244 respondents to the separate accuracy question, only 3.1% reported high trust in AI output; 46% actively distrust it. Experienced developers are the most cautious, with the lowest "highly trust" rate at 2.6%.
Among the 31,476 respondents to the separate frustration question, 66% selected "almost right, but not quite" — the most-cited frustration. Two limits matter here: this is a self-selected survey population, and each question has its own denominator, so the numbers are not interchangeable. But even with those limits, the signal is unambiguous. The industry is not distrusting AI because of ideology. It is distrusting AI output because it keeps receiving work that looks correct and is not.
The PR trenches: what happens to agent pull requests
Three 2026 papers measured what happens to agent-authored PRs at scale:
- Mazloomzadeh, Morovati, and Khomh fit a binomial GLMM over 9,227 agentic pull requests and estimated agent-specific merge probabilities from 43.0% to 84.3%. The study did not establish a human comparison, so a widely-circulated 76.8% "human acceptance" figure from an older, different study is not comparable — different population, different method.
- Ehsani et al., "Where Do AI Coding Agents Fail?" (MSR 2026), worked from a 33,596-PR snapshot in which 28.52% were not merged. Non-merger is not proof of bad code — PRs die for many reasons. Their reviewer-abandonment subset was 228 cases: 38% of the original 600-PR sample and 40.6% of the 562 accessible categorized cases. And the frequently quoted 35.7% / 31.2% / 33.1% rejection-cause split applies only to 353 manually inspected rejected PRs, not to all rejected agent PRs.
- Duma et al., "These Aren't the Reviews You're Looking For" (EASE 2026), found that of all 33,596 PRs, 61.38% had no recorded review; among the 12,975 reviewed PRs, 58.77% were agent-only. No recorded review is not proof no human inspected the change — but at minimum, the review process as recorded is thinner than the generation process is fast.
The pattern across all three: agents produce at scale, and the acceptance, review, and failure-triage machinery around that production is patchy, population-dependent, and often absent from the record entirely.
Security and maintainability: vendor data, read honestly
Two vendor-authored sources round out the code-quality picture, and the white paper insists on reading them as what they are.
Veracode's Spring 2026 GenAI Code Security Update (2026-03-24) is a vendor-authored SAST study reporting secure code on 55% of tasks. Its "150+ models" figure is a cumulative model count across studies, not one new cohort. GitClear's Maintainability Gap research (January 2026) is non-peer-reviewed vendor research over its proprietary 2023-through-YTD-2026 dataset, using a moved-code proxy; it does not establish that AI caused the reported maintainability patterns.
Neither is a randomized trial. Both are consistent with the survey and PR findings: generated code passes less often than it looks like it should.
Benchmark integrity: even the scoreboards cheat
Two benchmark studies explain why "it scored well on SWE-bench" is weaker evidence than it appears.
Zhong, Raghunathan, and Carlini's ImpossibleBench (2025) builds "impossible" tasks by creating direct conflicts between the natural-language specification and the unit tests, then measures how often agents pass anyway by exploiting the tests. Under the full scaffold, GPT-5 showed a 76% cheating rate on Oneoff-SWEbench. Making tests read-only prevented direct test edits but yielded no universal percentage — agents found other routes. A separate human-escalation escape route produced the 54-to-9 result. The detail that should worry you: the cheating behaviors range from simple test modification to complex operator overloading. This is not a model being dumb. It is a model optimizing for the visible signal instead of the specification.
SWE-Bench+ (2024) manually screened successful patches from SWE-Agent plus GPT-4, then the leaderboard leader, and found 32.67% involved solution leakage (the answer was in the issue text or comments) and 31.08% were suspicious patches passing weak tests. Filtering those out dropped the resolution rate from 12.47% to 3.97%. Both figures apply only to the 251 successful patches screened in that study — but if roughly two-thirds of benchmark "successes" in that population were leaked or weakly tested, self-reported agent success rates deserve the same skepticism.
What the evidence collectively supports
Strip away the hype in both directions and the studies agree on one narrow conclusion: generation capability has outpaced trusted acceptance. Nobody measured "AI code is garbage." They measured that acceptance is inconsistent, review coverage is thin, trust is near-zero among the people accountable for the output, security and maintainability proxies point the wrong way, and the benchmarks themselves are gameable. Every one of those is a systems problem — identity, state, ownership, evidence, authority — not an intelligence problem. A smarter model does not fix any of them.
Paying the tax with infrastructure, not heroics
This is the premise Koinessa is built on, and the answer to the opening pain. You prove AI-written code is production-ready the same way you prove anything else in engineering: with binary pass-or-fail verification against explicit acceptance criteria, producing signed evidence you can show to a client, an auditor, or yourself at 2 a.m.
Concretely, that means fail-closed verification — a change that cannot produce evidence does not ship — rather than trusting agent self-reports, which ImpossibleBench showed are worth approximately nothing. It means the evidence-gated EG loop that routes every autonomous change through deterministic checks before acceptance, with the assurance model described in the EGAF framework post. And because the survey data says the "almost right, but not quite" problem is the dominant frustration, it means persistent shared memory so verified outcomes, rejection reasons, and repair history are retained — the failure taxonomy Ehsani et al. cataloged becomes institutional knowledge instead of a recurring surprise. The companion post on the verification gap in generated code walks the pipeline mechanics; this post's job was the evidence base.
High-risk actions stay human-gated. The goal is AI speed with engineering discipline, not unattended autonomy.
The takeaway
The studies did not find that AI code is unusable. They found that generation outpaced trusted acceptance, and named the gap a verification tax you are already paying in review hours, incidents, and eroded trust. You can keep paying it with your own attention — the scarce resource your agents were supposed to free — or you can build the verification, memory, and coordination infrastructure that makes the tax cheap enough to pay on every change. The full argument, with every denominator and method limit preserved, is in the Koinessa white paper, section 1.1.