Vibe Code Security: 45%, 62%, or 91.5%?

If you follow security research analysis on AI-generated software, you have seen three numbers quoted constantly: 45%, 62%, and 91.5%. They are all real, published figures, and they all get cited as "the" AI code vulnerability rate. They cannot all be right. In fact, each number measures a different layer of the same problem, and conflating them is the fastest way to make bad decisions about your own codebase. This post breaks down where these numbers come from, why they disagree, and how to turn vibe coding statistics into a practical vibe code risk assessment for your project.

Where the three numbers come from#

The 45% figure#

The 45% figure comes from a widely cited benchmark study that generated code from natural-language prompts across a set of common programming tasks, then ran a commercial static analysis suite over the results. The researchers reported that roughly 45% of the generated code units contained at least one finding flagged by the scanner. The key detail: this is a synthetic benchmark. The samples are short, self-contained functions written from prompts, not real feature work. A "finding" here includes everything from buffer overflows to missing null checks.

The 62% figure#

Later research took a different approach. Instead of generating code in a lab, the researchers analyzed pull requests in real repositories where developers had used AI assistance. They used a source code scanner at merge-time and found that about 62% of the AI-assisted code changes introduced at least one security-relevant defect. This is an observational study, so it captures code that passed code review, passed CI, and made it into production. That is a much more demanding bar, and yet the number went up.

The 91.5% figure#

The largest figure comes from a portfolio-level scan of production applications that contained at least one AI-generated module. When the researchers aggregated all security findings by project, 91.5% of those applications had at least one vulnerability somewhere in their AI-written code. That is not the same as saying 91.5% of AI code is vulnerable, yet that is often how it gets quoted. It is the prevalence of at least one issue per application over an extended scan window.

Source: secure.com

Why the numbers disagree#

None of these studies are wrong. They measure different things, and the gap between them is explained by four methodological variables that any security research analysis has to confront.

The scanner problem#

Static analysis tools disagree with each other dramatically. One scanner may flag an unchecked array index as a high-severity defect; another ignores it if it is provably in-bounds. The 45% study used one commercial tool, the 62% study used a different one, and the 91.5% study aggregated both plus additional checks. Application security metrics are only meaningful when you know exactly which scanner, which ruleset, and which Common Weakness Enumeration (CWE) classes contributed to the denominator.

The sample problem#

Synthetic benchmark code is clean, short, and prompt-derived. It has no legacy dependencies, no framework wiring, and no copy-pasted boilerplate. Real pull requests have all of those, plus the developer's own edits layered over the generated code. AI code vulnerability rate numbers derived from synthetic samples will always be lower-bound estimates, because they exclude the integration vulnerabilities that only appear when generated code talks to existing systems.

The baseline problem#

Vulnerability statistics are meaningless without a human baseline. The 45% study reported that human-written solutions to the same tasks had a lower finding rate, but the difference was smaller than the headlines suggested. Other research shows that experienced developers fix most severe AI-generated issues during review, which means the raw output rate and the merged output rate diverge substantially. If you quote the raw generation rate, you are measuring the model, not the software.

Source: softwareseni.com

What each number actually means#

45% is a code-unit result#

It answers the question: given a fresh prompt, what fraction of the model's first pass contains something a scanner dislikes? It is a useful upper bound for planning: assume roughly half of generated output is not clean on the first try. It is not a statement about what ships.

62% is a contribution-level result#

It answers the question: when AI-assisted code reaches your main branch, how often does it carry a security-relevant defect? This is the number that matters most for teams adopting vibe coding workflows, because those contributions already passed review and CI. A rate in the sixties tells you that manual review is not catching everything.

91.5% is a portfolio-level result#

It answers the question: if you ship enough AI-generated code, how likely is it that one of those components is vulnerable somewhere? The answer being near-certain is not surprising. Any sufficiently large body of code, human or machine-written, eventually accumulates findings. Treat this number as an argument for continuous scanning, not for abandoning AI assistance.

Running your own vibe code risk assessment#

External numbers are useful context, but they cannot tell you the risk in your specific codebase. Here is how to build your own application security metrics instead of importing someone else's.

Fix the denominator#

Track the vulnerability rate per lines of code, per merge, and per feature area. A single percentage without a denominator is noise. Prefer finding density: security findings per 1,000 lines of generated code, compared against the same density for human-authored code in the same repository.

Weight by severity and reachability#

A static analysis finding that is reachable from an unauthenticated HTTP endpoint is an emergency. The same finding behind an admin-only code path is a backlog item. When you report your own AI code vulnerability rate, filter by severity and reachability before you share it with stakeholders. You will almost always arrive at numbers well below the scary headlines, because the scary headlines do not do that filtering.

Scan at generation time, not just merge time#

On the FIM platform, FutureX makes this practical: as it writes code, it can run security checks against the generated diff and revise before the code ever enters review. That means the frest measurement point catches issues while the context is still in the agent's working memory. For teams that want provenance, FIM supports attribution so you can tag which files or functions were AI-generated and compare their findings against hand-written code over time.

Look at fix cost, not just count#

Vulnerability count says nothing about how expensive the fix is. Measure median time-to-remediation for AI-generated findings versus human findings. In most teams, AI-generated defects are cheaper to fix because the model can regenerate the surrounding component. That is a real advantage hidden by raw statistics.

Source: saassentinel.com

Conclusion#

So which number is real? All three, and none of them. 45% tells you about raw model output, 62% tells you about merged contributions, and 91.5% tells you about long-term portfolio exposure. None of them is a verdict on whether your project is secure. What matters is building your own vibe code risk assessment: fix the denominator, weight by reachability, scan as early as possible, and track how fast issues get fixed. If you do that, you will understand your actual risk better than anyone citing a single headline percentage. The real number behind vibe code security is the one you measure in your own pipeline, and tools like FutureX are designed to help you collect it continuously.