An autonomous AI agent was recently handed a real software project and told to build it. It did — the whole system, working, in a single week. It also racked up between €10 million and €15 million in token fees doing it, and produced code researchers later described as nearly unmaintainable. That case study, buried in a 2026 industry report most people never read, is the single best illustration of a problem quietly spreading across the entire software industry: the code is getting written faster than ever, and almost nobody is checking whether it’s actually safe.
The Headline Number That Should Worry Everyone
Veracode has spent two years running the most comprehensive longitudinal study of AI code security that exists — testing over 150 large language models across security-sensitive coding tasks. Their latest update, published in July 2026, delivers a genuinely uncomfortable finding: despite AI coding assistants now hitting syntax correctness rates above 95%, the security pass rate has stayed stuck at roughly 55% — virtually unchanged from where it stood two years earlier. Nearly half of all AI-generated code contains a known, detectable security vulnerability when no explicit security guidance is provided.
The breakdown by vulnerability type is where this stops being an abstract statistic. Across the models tested, 86% of generated samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection — not obscure edge cases, but staples of the OWASP Top 10, the industry’s own list of the most common and best-understood web application vulnerabilities. Java code fared worst of all, failing security tests at a 72% rate. These aren’t exotic attack vectors nobody anticipated. They’re mistakes the security community has been teaching developers to avoid for over a decade, and AI models are still making them at scale, without the improvement curve you’d expect as the underlying models get more capable at everything else.
This Isn’t Staying Theoretical — It’s Already in Production
If the Veracode numbers sound like a lab result, a separate study makes clear the problem has already left the lab. API security firm Escape.tech scanned more than 1,400 real, vibe-coded production applications — software actually running, actually serving users — and found that 65% had security issues, with 58% containing at least one critical vulnerability. Their scans turned up over 400 exposed secrets and 175 instances of exposed personally identifiable information, including bank account data, sitting in live applications.
Credential exposure specifically is accelerating in a way that’s easy to quantify and hard to dismiss. GitGuardian’s 2026 State of Secrets Sprawl report found that AI-assisted commits expose secrets at more than twice the rate of human-only commits — 3.2% versus 1.5% — while public GitHub saw a 34% year-over-year increase in hardcoded credentials overall. Separately, enterprise security data cited by SecurityWeek documented a roughly 10x increase in monthly security findings inside Fortune 50 companies between December 2024 and June 2025 — climbing from around 1,000 flagged vulnerabilities a month to over 10,000 in the space of six months.
Why This Is Genuinely Hard to Track — and Probably Undercounted
One of the more unsettling threads in this research isn’t the size of the problem, it’s how much of it is likely invisible. Georgia Tech’s Vibe Security Radar project set out to answer a specific question the security community had only been asking informally: how many publicly filed CVEs — the formal vulnerability identifiers used industry-wide — can actually be traced back to AI-generated code? In a single month, March 2026, researchers tracked 35 CVEs directly attributable to AI coding tools. But the researchers themselves believe that number represents only a fraction of the real total, estimating the true count at five to ten times higher across the broader open-source ecosystem, since most AI coding tools don’t leave identifiable metadata in their commits that would let anyone trace a vulnerability back to its AI origin after the fact.
That’s a genuinely strange problem for the security industry to be facing: not just “AI-generated code has more bugs,” but “we can’t even reliably measure how many of our bugs came from AI in the first place,” because the tooling to track provenance simply doesn’t exist yet at the scale this is happening.
The Productivity Paradox: Faster Code, Slower Teams
Perhaps the most counterintuitive finding across this research is that the speed AI coding tools are famous for delivering doesn’t actually show up in overall team velocity once you account for what happens after the code gets written. The Software Improvement Group’s State of Software 2026 study found that AI-generated code carries roughly twice as many security-risk violations as human-written code, and productivity gains from AI coding tools tend to disappear entirely once a codebase reaches a certain size and complexity — because developers end up spending the time they saved generating code on cleaning it back up instead.
A separate large-scale empirical study tracking AI-introduced technical debt across real repositories found the cumulative volume of unresolved, AI-introduced issues climbing from just a few hundred in early 2025 to over 100,000 by February 2026 — and still rising, not plateauing. The researchers behind that study made a point worth sitting with: this debt doesn’t have to be a temporary side effect that gets cleaned up later. Left unaddressed, it becomes a permanent, compounding maintenance burden baked into the software itself.
The Trust Gap Nobody’s Talking About Enough
Here’s a statistic that captures the whole situation in one line: 84% of developers have adopted vibe coding, but only 29% actually trust it. That’s not a minor gap between adoption and confidence — that’s a majority of the industry using tools it doesn’t believe in, presumably because the speed benefit still feels worth the risk, or because competitive pressure makes opting out feel like falling behind. Separately, 57% of developers report actively worrying that AI-generated code could expose sensitive company or customer data — a majority-held fear about the exact tools those same developers are shipping production code with every day.
There’s also a structural, slower-burning problem layered underneath all of this. A 2025 survey found 54% of engineering leaders plan to hire fewer junior developers specifically because AI tools now handle work that used to require them. The uncomfortable irony there is that fixing AI-generated technical debt requires exactly the kind of hands-on debugging judgment junior engineers traditionally build through years of making and fixing their own mistakes. If fewer juniors get hired now, the pipeline of engineers equipped to clean up this debt in 2027 and beyond may simply not exist at the scale the debt requires.
What Actually Seems to Help
It’s not all bleak, and the research does point to something that measurably works: developers using tools with systematic verification built in — automated security scanning integrated directly into the development workflow, rather than treating review as a separate, optional step — show meaningfully better outcomes on code quality, technical debt, and vulnerability rates than developers who don’t. That’s a fairly unglamorous fix compared to “better AI models,” but it’s the one piece of this research that shows a genuinely improvable path forward: the fix isn’t asking the model to write more securely on its own, it’s putting real verification machinery around the output before it ships, every time, by default rather than by discipline.
My Take
What strikes me most about this research isn’t any individual statistic — it’s the flatness of the trend line. Security pass rates haven’t meaningfully moved in two years, across multiple model generations that have gotten dramatically better at almost everything else measurable: reasoning, coding benchmarks, agentic task completion. That’s not a rounding error or a temporary growing pain. It suggests security simply isn’t the axis these models are being optimized against, and nobody should assume it’ll fix itself as a side effect of general capability gains, because the data says it hasn’t so far.
I think the more useful way to read this isn’t “AI coding tools are dangerous, don’t use them” — that ship has sailed, and the productivity case for these tools in the parts they’re actually good at is real. It’s that the industry has quietly outsourced a huge volume of security-critical decisions to systems that fail security tests roughly half the time, without building the verification infrastructure to catch that failure rate before it reaches production. The 1,400 vibe-coded apps Escape.tech scanned weren’t hobby projects — those are live systems, with exposed bank data sitting in them right now, that somebody is presumably still using.
If there’s one number from all of this worth remembering, it’s the 84% versus 29% gap — the industry adopting a tool it doesn’t trust, at scale, faster than it’s building the safeguards to make that trust reasonable. That gap doesn’t close itself. It closes when verification stops being optional tooling bolted on by security-conscious teams and becomes the default nobody has to remember to turn on — and right now, for most of the industry, it still isn’t.