Checking Isn't Catching

The verification gap essay asked whether developers check AI code before committing it. A newer, sharper question is what happens when they do: more than one in five of the problems AI introduces were still unfixed when researchers looked, and some of the checking that does happen is delegated back to the thing that wrote the code.

TL;DR

Distrust of AI-generated code and the act of checking it are two different things, and both are different again from whether checking actually catches anything. Telemetry studies that track what happens to AI code after it ships find a large share of problems that were still uncorrected when the researchers looked, work that looks like review but is quietly delegated to the AI itself, and a confidence-versus-capability gap at the organisational level that mirrors the one already documented at the individual level.

A large-scale study of AI-authored GitHub commits found that more than one in five of the issues AI introduces are still present in the codebase's latest revision, meaning nobody had fixed them by the time of the study, and that AI assistants introduce security vulnerabilities at about 1.5 times the rate they fix them.
A six-month tracking study of AI-generated files found that when correction does happen, it shows up less often as an explicit bug fix and more often as ordinary feature or refactor work, which suggests problems are getting smoothed over rather than caught and named.
A behavioural study of 75,000 real AI chat messages found developers explicitly correcting misaligned AI output in 7.21% of messages, a larger share than the 3.99% of messages where validation work like code review or runtime checking was handed straight back to the AI that wrote the code, though that smaller figure is the more unsettling one.
GitLab's 2026 survey found 87% of organisations confident they could trace AI code's role in a production incident within 24 hours, but only 34% of organisations that actually had an incident could do it, the same confidence-outruns-capability pattern the original verification gap essay found in individuals, now showing up at the level of the organisation.

The verification gap essay asked a simple question: do developers check AI-generated code before they commit it? The answer was a 48-point gap between stated distrust and stated checking, and it held up across surveys, telemetry and non-software research alike. That’s still true. But the question was about an action, and it leaves a harder one about the outcome sitting underneath: when checking happens, does it catch anything?

A 2026 study of AI-authored commits across more than 6,000 GitHub repositories gives the first clean answer, and it isn’t reassuring. Researchers ran static analysis before and after every commit from five major coding assistants (Copilot, Claude, Cursor, Gemini and Devin) to see what each one introduced. More than 15% of commits from every single assistant introduced at least one new issue. Worse, more than one in five of those issues were still sitting in the codebase’s latest revision at the time of the study, meaning nobody had fixed them since. Security issues were worse than the average, with assistants introducing new vulnerabilities at about one and a half times the rate they fixed existing ones.

When correction happens, it often doesn’t look like correction.

A separate six-month study tracked 508 AI-generated files against an equal number of human-written ones, logging every follow-up commit for half a year after creation. The headline finding sounds comforting: 83% of the maintenance work on AI-generated files was done by humans, not by another AI pass. The detail underneath is more interesting. AI-generated files received noticeably fewer commits explicitly labelled as bug fixes than human-written files did, and correspondingly more labelled as feature work or refactoring. The researchers’ own reading is that problems in AI-generated code are absorbed into later feature and refactor work more often than they are caught and logged as bugs. Fixed, perhaps, but never named as a fix. A defect folded into the next feature commit doesn’t show up in any bug count, incident report or retrospective about AI code quality. It disappears into the normal churn of the codebase: correction without an audit trail.

Some of the checking is delegated to the thing being checked.

A behavioural study published this year coded 75,000 real developer messages across more than 11,000 AI chat sessions in Cursor and Copilot. These were the actual conversations developers have with AI tools while coding, not a survey about them. Developers explicitly corrected AI output that had drifted from what they wanted in 7.21% of messages. That’s the bigger number. The smaller one is more unsettling: in 3.99% of messages, validation work like code review or runtime checking was handed straight to the AI itself rather than performed independently by the developer. It’s a minority of messages, but it describes something the correction rate doesn’t: work that looks like checking but only checks the model against itself.

The paper’s own warning is blunt. When diagnosis, comprehension and validation are all delegated to the same tool that wrote the code, “the assistant may become the only judge of both what the code does and whether it is correct, with no independent check on its own errors.” That is a structural problem, separate from how much developers trust the tool or how often they check. The verification gap essay assumed a human was on the other end of the check. Sometimes the other end is the same model.

Organisations confuse confidence with capability too.

GitLab’s 2026 accountability survey found 87% of organisations confident they could trace AI-generated code’s role in a production incident within 24 hours. Among organisations that had actually had such an incident, only 34% could do it. That 53-point gap between stated confidence and demonstrated capability echoes the original verification gap’s split between belief and action, one level up. What’s being overestimated here is the organisation’s tooling and audit trail, not any individual’s diligence, and that confidence only gets tested when an incident happens.

Self-assessment runs ahead of reality again in a disagreement between two of the field’s most-cited 2026 reports. DORA’s research argues that organisations with strong engineering foundations are protected from AI’s downsides, that good platforms and good practices act as a buffer. Faros AI’s telemetry, pulled from 22,000 developers’ actual commit, review and incident history, finds no such protection: high-performing teams show the same downstream quality deterioration as everyone else once AI adoption rises. DORA’s finding is built from what organisations say about themselves. Faros’ is built from what their systems recorded. When self-report and telemetry disagree this directly, the disagreement is itself evidence for the thesis: the people closest to a system are consistently the worst placed to judge it dispassionately, and that includes people judging their own employer’s resilience, not just their own code.

Even research designed to correct this kind of bias isn’t immune to it. METR’s widely cited 2025 trial found developers were measurably 19% slower with AI assistance while believing, before and after the study, that they’d been faster. Its 2026 follow-up, intended to see whether that gap had narrowed, hit a problem baked into its own design: the developers most convinced AI was helping them increasingly declined to take part, or withheld the specific tasks most likely to show AI’s benefit, rather than risk having that belief tested against a no-AI condition. Between 30% and 50% of surveyed developers admitted doing exactly this. METR now describes its own newer data as “only very weak evidence.” Any study of this kind would run into the same thing. Try to measure how well people check their own work, and the people most confident in the answer turn out to be the ones most likely to route around the question.

Checking more won’t close the second gap.

None of this says checking is pointless, or that the original verification gap doesn’t matter. It says the gap has a second layer that surveys of stated distrust and stated checking can’t see. A developer who dutifully reviews every pull request still works inside a system where more than one in five of the problems that get through were still unfixed when researchers looked, where correction often gets logged as something else, and where validation is sometimes quietly handed to the tool that needs validating.

Getting people to check more closes the first gap. It doesn’t automatically close the second. What would: tracking whether review finds anything as well as whether it happens, treating a bug smoothed into a refactor commit as a near-miss worth logging, and building the kind of traceability that a real incident tests rather than the kind an org chart assumes exists. The verification gap was about whether anyone looks. This one is about whether looking, as currently practised, actually works.