The Verification Gap: Why Distrust of AI Code Doesn't Turn Into Checking It

Two 2026 surveys, published in January and September, measured the same discomfort in different ways. Sonar’s State of Code Developer Survey found that 96% of developers don’t fully trust AI-generated code. Qodo’s State of AI Code Quality Report found that 89% of organisations have already had an AI-related production incident, and only 3.7% of engineering leaders think their current review process is sufficient. Distrust is close to universal.

What should worry leaders more is a second number in the same Sonar survey: only 48% of developers say they always verify AI-generated code before committing it. That 48-point gap between what people believe and what they do is the subject of this piece.

It is a different problem from the review-bottleneck story told about PR size and wait times. A bottleneck is a capacity problem: not enough reviewer-hours for the volume of code arriving. This is a behaviour problem. The reviewer-hours exist, the stated will to use them exists, and the checking still doesn’t happen at the rate the distrust would predict.

The self-report data is not an outlier. Three independent kinds of measurement show the same gap.

Start with the surveys, which agree on the shape of the problem even when the numbers move around. Sonar frames the cost as cognitive rather than temporal: 61% of developers agree that AI “often produces code that looks correct but isn’t reliable,” 38% say reviewing AI code takes more effort than reviewing a colleague’s, and teams report spending close to a quarter of the working week checking, fixing and validating AI output.

GitLab’s AI Accountability Survey, fielded the same year, finds what it calls the AI paradox: 79% report individual productivity has improved and 73% say quality has improved, yet 85% agree that review and validation, not code generation, is now the constraint on delivery. And 43% of developers say they can’t reliably tell AI-generated code from human-written code in their own codebase. That is a confidence problem hiding inside a trust problem: you can’t selectively distrust what you can’t identify.

Telemetry doesn’t ask anyone what they believe. It measures what happened. Faros AI’s Acceleration Whiplash report, drawn from two years of engineering-lifecycle data across roughly 22,000 developers, found that as AI adoption rose, PR size grew 51%, bugs per developer rose 54%, median PR review time rose 441%, and the share of pull requests merged with zero human review rose 31%.

Its explanation for the review-time blowout matters more than the number. AI-generated code is idiomatic, well-named and stylistically consistent, so the old habit of pattern-matching for obviously wrong-looking code stops working. Reviewers now have to reconstruct intent to catch an error, which is slower work. Commentary on the report has taken to calling this “the senior engineer tax,” because reconstructing intent is the skill juniors haven’t built yet.

GitClear’s five-year analysis of 211 million changed lines tells the same story from the codebase side. Team review participation fell by roughly 30% over the period even as AI-generated volume rose, refactored code fell from about a quarter of changes to under a tenth, and copy-pasted code overtook moved code for the first time in the dataset’s history.

Both of these are software-specific, so it would be easy to assume the mechanism is something about code review culture in particular. Radiology says otherwise. It has run something close to a controlled version of the same experiment for years, because AI-assisted diagnosis has been in clinical use long enough to study properly.

Dratsch et al.‘s mammography study found that when an AI suggestion was wrong, inexperienced radiologists’ accuracy on those cases collapsed from around 80% to under 20%, and even the most experienced readers, averaging over fifteen years’ practice, saw their accuracy roughly halve. Kim et al.’s study on cerebral aneurysm detection found that reading time dropped once AI assistance was present, across every experience band, regardless of whether the AI’s suggestion was correct. Readers weren’t asked whether they trusted the tool. Their scrutiny was measured, and it fell anyway.

Researchers call the mechanism automation bias: a plausible-looking suggestion gets treated as evidence by default, which both anchors judgement toward the tool’s answer and shortens the time spent checking it independently. Expressed caution and reduced scrutiny coexist comfortably, in radiology and in code review, because they are not in tension with each other. One is what a person believes about the tool. The other is what the tool does to their attention once it’s in the workflow.

Even the study built to correct this pattern got caught in it.

METR’s 2025 randomised trial is the field’s clearest evidence that self-reported productivity and measured productivity can point in opposite directions: 16 experienced developers took 19% longer on real tasks with AI tools, having predicted beforehand they’d be roughly 24% faster, and still believed afterwards they had been.

In February 2026, METR disclosed a problem with a follow-up experiment meant to check whether that gap had narrowed. Developers who felt AI benefited them most were disproportionately the ones who refused to be assigned to the no-AI condition, and 30 to 50% of participants withheld the tasks they thought would most favour AI rather than risk losing that comparison. METR now calls its original finding “historical” rather than standing behind it as current.

None of this discredits the original RCT, which remains a randomised design. It does show, inside the research itself, that people who believe a tool is helping them will route around having that belief tested. That is the dynamic this piece is about.

Why the gap persists is a Goodhart’s-law problem, and it’s a choice leaders are already making.

None of the surveys or telemetry reports name career risk or blame allocation directly as the reason checking lags behind stated distrust. But look at what gets measured and celebrated instead. GitHub’s Octoverse 2025 leads with adoption speed and volume: nearly 80% of new developers use Copilot in their first week, pull requests merged per month are up 23% and commits up 25%, none of it paired with a defect rate or a revert rate.

Faros’ own report warns explicitly against reading its throughput numbers (epics per developer up 66%, task throughput up 34%) as clean wins. “Every organisation cutting engineering headcount on the basis of AI output gains should read this report,” it says, in the same document that shows incidents per PR up 243% over the identical period.

When the visible, rewarded number is volume and the invisible, unrewarded cost is verification time, the gap between what people say they distrust and what they check is no mystery. It is what you get from measuring one thing and hoping for the other.

Seniority sharpens the incentive problem. Stack Overflow’s 2025 survey found that developers with ten or more years of experience report the highest distrust of any group, yet Faros’ telemetry shows senior engineers absorbing the heaviest new review burden, because reconstructing an AI agent’s intent takes real expertise. The people most convinced the output needs checking are also the people least able to check all of it: each of them is one person facing an accelerating volume of code.

JetBrains’ 2025 ecosystem survey adds a smaller but telling wrinkle. Less experienced developers report that reviewing AI code takes more effort than their senior peers report, while also estimating that a higher share of their own committed code is AI-assisted in the first place. Distrust, review burden and review capacity are distributed across a team in three different, uncorrelated ways. No single policy fixes all three at once.

One thing this piece won’t do is dress up “check your AI output” in inherited authority it doesn’t have. “Trust, but verify” gets reached for constantly in this conversation because it sounds tested by history. In this context it isn’t. The phrase’s real lineage is a Russian proverb popularised in English by Reagan during nuclear arms-control negotiations, a domain where the party being verified had its own incentive to cheat on a treaty. There’s no comparable engineering tradition behind it. The one documented technical use of the phrase, a 2015 paper on type-checking in dynamic languages, is about compiler theory, not code review.

Borrowing the idiom lends the problem a rhetorical weight it hasn’t earned in software. That is worth naming because this piece argues against the same kind of substitution: a phrase that sounds like a solution standing in for the unglamorous work of building verification into how the organisation measures itself.

What leadership can change is structural, and none of it is “ask developers to care more.” Qodo’s report puts the fix cleanly: “generation scaled across the entire lifecycle, and verification never scaled with it.” Its recommendation is to move quality checks upstream to the point of authorship rather than adding more human review capacity downstream of an ever-growing queue. GitLab’s is about infrastructure, not vigilance: organisations that ship trusted software faster are the ones building traceability and governance into the platform now, not the ones planning to review harder later.

DORA’s framing is the sharpest one for a leader deciding where to start. AI doesn’t fix a team, it amplifies what’s already there, so a team with weak testing and version-control discipline will find AI making its existing problems worse, faster, while a team with strong safety nets converts the same tool into a real gain.

The gap between distrust and verification isn’t going to close because developers decide to trust less carefully. It closes when what gets measured, rewarded and built into the pipeline is verification itself, not the volume it’s supposed to be checking.