Numbers about AI-generated code travel fast and lose their context on the way. Our Evidence page lists every figure this site uses, with the primary source, the date we checked it and what it measured. This post explains how to read four of the most quoted studies, and why one figure you may have seen is missing.
Three things turn a statistic into information: the sample and who chose it, what exactly was counted and by whom, and the denominator behind any percentage. Vendor research also deserves one honest sentence: Veracode, CodeRabbit, Tenzai and Escape all sell products related to what they measured. That does not make the numbers wrong. It means you read the method before repeating the headline.
Veracode: code samples, not apps
Veracode tested code from more than 100 large language models across Java, Python, C# and JavaScript and found that 45% of code samples failed security tests (Veracode, 2025). The unit is a code sample: a model's answer to a coding task designed around a known security pitfall. So the study measures how models behave on tasks where a wrong turn is available, not how often deployed apps have flaws. The language split matters too; the Java failure rate was 72% in the same report (Veracode, 2025). If your stack is JavaScript, the headline number is not your number.
The check that follows from this study is simple. The categories of flaw it counts are the same ones our pattern catalogue tests for. They can be tested on your app rather than inferred from a model average.
CodeRabbit: pull requests, reviewed by the vendor's tool
This one is about pull requests. CodeRabbit reviewed 470 open-source GitHub pull requests, 320 co-authored with AI and 150 written by people alone (CodeRabbit, 2025). The AI co-authored ones contained about 1.7 times more issues overall and up to 2.74 times more security issues (CodeRabbit, 2025). Two things belong next to that. The issues were detected by CodeRabbit's own review tool, so "issue" means what that tool flags. And the primary source says "up to", so the security multiplier is a ceiling across categories, not an average. Repeating the multiplier as a flat rate drops the qualifier the authors kept.
The practical reading is that generated changes need review time, and that review needs a checklist rather than a skim. Our two-account method is a place to start.
Tenzai: five agents, identical prompts, one lab
This one is a controlled experiment. Tenzai had five coding agents build applications from identical prompts in December 2025 and found 69 vulnerabilities across 15 applications; none of the 15 had CSRF protection or security headers (Tenzai, 2026). The strength of this design is control: same prompts, same reviewer, different agents. The limit is size. Fifteen applications from one lab tell you which categories of flaw appear when nobody adds a testing step, not a rate you can apply to the world. Press coverage adds a count of critical findings that the primary does not state as a total, so we do not record it.
The two flaw categories every app shared are checkable in minutes on your own site. See Missing security headers.
Escape: a large scan with a gated report
This one is about deployed apps. Escape analysed more than 5,600 publicly deployed apps built with AI app builders and found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal data (Escape, 2025). The sample is large and the apps are real, which is why this is the most useful headline of the four. The limits: the full report is gated, the figures come from the public methodology post, and the apps were found by the vendor's own scanner, which decides what counts as a vulnerability. Percentages that circulate for this study are not in the public primary and are not on this site.
Exposed secrets are the finding you can check yourself today: Third-party API key in the JavaScript bundle.
The figure that is not here
One figure is missing on purpose. You may have seen a claim that a percentage of apps built with AI app builders, a figure in the low nineties, had a critical vulnerability. It is attributed to Escape and dated early 2026. We tried to source it. It appears in none of Escape's publications we fetched. Repostings attribute it variously to a small vendor's page that does not contain it, and to an unpublished internal audit that we could not find. It is a widely reposted percentage we could not trace to a primary source, so our evidence entry records it as dropped and the site does not render it. Our rule is that a statistic without a resolvable primary is removed, not softened.
How to read the next one
When a new number arrives, find the primary, read the method section, and write down the unit, the denominator, who counted, and the date. If any of those is missing, treat the number as a rumour until it is found. Then ask what the check for your own app would be. A statistic tells you a category of problem exists. A test on your app tells you whether you have it.
What to do this week
- Read the primary for any figure you plan to quote; each row on Evidence links to one.
- Check the two flaws the Tenzai apps all shared: Missing security headers.
- Run the self-check to turn categories into a list of things to test: Self-check.