AI-generated code and the verification gap: what the data says

Six sources, side by side

These are the six most-cited measurements of AI-written code published between July 2025 and early 2026. Two are 2026 publications; four are from 2025 and remain the latest of their kind we could verify. Each figure below was checked against the publisher's own page or announcement.

What the sources agree on

Almost everyone uses it

Stack Overflow puts use or planned use at 84 percent of developers; DORA puts use at work at 90 percent of technology professionals. Whether to use AI for code is no longer the question most teams are deciding.

Few fully trust it, and checking is partial

Three independent surveys land in the same place. Stack Overflow found 46 percent do not trust the accuracy of AI output. DORA found 30 percent report little or no trust in AI-generated code. Sonar found 96 percent do not fully trust it to be functionally correct, and that fewer than half always check it before committing.

That last pair of numbers is the gap: nearly everyone doubts the code, and fewer than half always check it.

The cost shows up after the code is written

Faros measured it in delivery data: more pull requests merged with no review, and more incidents per pull request, as AI adoption rose inside the same organizations. Veracode measured it in security: vulnerabilities in 45 percent of test cases. Stack Overflow's respondents described it in their own words, as answers that are almost right and take longer to debug. METR measured it in time, and found the developers themselves could not see it.

How to read them

These figures deserve the same scrutiny as any others.

• Three of the six come from vendors that sell a remedy. Sonar sells code quality tools, Faros sells engineering analytics, and Veracode sells security testing. Their findings point toward problems their products address. That does not make the data wrong, and the other three sources point the same way.
• The Faros figures are changes, not rates. They compare periods of low and high AI adoption inside each organization. The incident figure is a ratio, and Faros notes it is not a probability, since one pull request can be linked to several incidents.
• METR's study is small and specific. Sixteen experienced developers, working on large repositories they knew well, with early-2025 tools. The authors describe it as a snapshot of that setting and caution against reading it as a verdict on AI tools generally.
• Veracode tested models, not teams. Its tasks were chosen because they have a known potential for security weaknesses.

What none of them measures

Every one of these studies looks at the code: whether it is trusted, whether it is reviewed, whether it is secure, how long it took. None of them, as published, separates defects that were introduced while writing the code from defects that were already in the requirement the code was written from.

That distinction matters, because the checks are different. A code review can catch a fault in the code. It cannot catch a requirement that was wrong, because the code matches it. A security scan can find an injection flaw. It cannot find a business rule that was never written down.

The older research is specific on this. Boehm and Basili found that 40 to 50 percent of project effort goes to avoidable rework, and named hastily specified requirements as a major source. An AI agent given such a requirement produces working code for the case it was given. The output looks correct to every measurement in the table above.

Three places to verify

The data supports checking at three points, and most teams have invested in only the second.

1. The requirement, before anything is built. Is it measurable, complete, and consistent with what was already decided? This is where a wrong assumption is cheapest to remove.
2. The code, when it is written. Review, static analysis and security scanning. This is the check the six studies show slipping.
3. The running software, against the requirement. Tests that trace to the requirement, with a record of which steps actually verified something.

Where Spec2TestAI acts

Spec2TestAI works on the first and third. Requirements Intelligence scores each story on 32 quality measures before code is written, and what it leaves open goes to a person who can decide. Tests are then generated from the requirement, and Spec2RunAI runs them against the live application and reports which steps were verified.

Security scanning and code review are their own category of tool, and the second check still needs them.

What this does not solve

Better requirements do not make AI-written code secure, and they do not replace code review. The 45 percent security figure and the unreviewed pull requests are problems in their own right.

We also cannot tell you what share of the incidents Faros counted began in a requirement. Nobody has published that number for AI-assisted teams. The 2001 research says the share was large when people wrote the code; whether it is larger or smaller now is an open question, and we would rather say so than guess.

Sources

• Sonar, State of Code Developer Survey, press release, 8 January 2026. More than 1,100 developers.
• Faros, The AI Engineering Report 2026: The Acceleration Whiplash, summary published 12 April 2026. 22,000 developers, more than 4,000 teams.
• Stack Overflow, 2025 Developer Survey, AI section, and press release, 29 July 2025.
• DORA, State of AI-assisted Software Development 2025, announcement, Google Cloud, 23 September 2025. Nearly 5,000 respondents.
• Becker, J., Rush, N., Barnes, E. & Rein, D., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR, 10 July 2025.
• Veracode, 2025 GenAI Code Security Report, press release, 30 July 2025.
• Boehm, B. & Basili, V., “Software Defect Reduction Top 10 List”, IEEE Computer 34(1), January 2001.