AI-Generated Code Security Has Been Flat for Two Years

This week the headlines are about AI agents going rogue and breaking into labs at machine speed. Underneath the drama sits a quieter fact almost nobody in the panic is citing, and it matters more to anyone actually shipping software: the ordinary code these models write is insecure about 45% of the time, no rogue agent required.

That number comes from Veracode's Spring 2026 GenAI Code Security Update, which tested more than 150 large language models on 80 security-sensitive coding tasks.^[1] With no security-specific prompting, the model introduced a known vulnerability in roughly 45% of cases. Not exotic bugs, either: OWASP Top 10 and CWE staples.

The coverage wave that resurfaced this data landed alongside this week's rogue-agent story,^[2] but the finding predates the panic and outlasts it.

The 45% is not even the striking part. The striking part is that it has not moved.

Has AI-generated code security improved as the models got better?

No, and that is the finding. Veracode's own summary is blunt: "Two years of 'revolutionary' model releases have moved the security needle from approximately 55% to… approximately 55%."^[1] Two years of leaps in capability, and the share of AI-written code that is actually safe sat still.

Set that flat line next to the other curve. Over the same two years, these models became near-flawless at writing code that runs. Syntax correctness now clears 95%. So one measure of "good code" went vertical while the measure that decides whether you get breached stayed pinned to the floor.

The company put the gap in one sentence, and it is the whole post:

This is the "looks done versus actually done" gap, finally measured. Compiles-and-runs is looks-done. Safe-under-attack is actually-done. We have written before about how generating code is the easy part and dependable software is the hard part.

Here is that argument with a number on it: the easy curve is at 95%, the hard curve is at 55%, and the two have pulled apart for two years.

Why does insecure AI code slip through review?

Because the failure is invisible and uneven. You cannot look at a working function and see which 45% carries a flaw, and the model is not uniformly bad in a way you could learn to distrust. It handles some vulnerability classes well and falls off a cliff on others.

Veracode broke it down by weakness type. On SQL injection the code passed about 82% of the time, and on weak cryptography about 86%. Then the floor drops out: cross-site scripting passed only about 15% of the time, and log injection about 13%.

That unevenness is what makes it dangerous. A developer who watches the AI nail SQL injection twice learns to trust it, then accepts a cross-site-scripting hole that reads exactly as clean. The code that runs and the code that is safe are indistinguishable on the screen, which is precisely why a person has to look.

Does a bigger or newer model fix it?

Largely no, and that is the part that should change how teams plan. Veracode found model size had only a very small effect on security, and even that had mostly vanished. Coding-specialized models were no safer than general ones. Newer releases did not reliably beat older ones.

One thing did help: deliberate reasoning. The extended-reasoning models (the GPT-5 reasoning series) reached roughly 70-72%, the best in the study. That fits a pattern we keep seeing, where capability climbs fast while real output barely moves unless something forces the model to slow down and think.

Reasoning helped more than raw scale. But 70% still means three in ten ship a flaw, and it took a deliberate process to get there, not a bigger download.

The upgrade path is a dead end here. You cannot buy your way out of this gap with next quarter's model. Two years of next-quarter's-model is exactly the evidence that it does not close.

What happens after the developer accepts the code?

The generation number is only half the story.

Watch how the code gets used, and a second signal points the same way. DECODE, a Carnegie Mellon study of 53,600 real in-editor edits from 1,000-plus developers, found people delete the AI's completion outright in 31% of edit trajectories, most within 15 minutes of accepting it.^[3] Acceptance is not delivery. It is the start of the rework.

And the consequences are no longer hypothetical. The Cloud Security Alliance tracked AI-generated code linked to about 35 new CVEs in March 2026, up from 6 in January and 15 in February.^[4]

A flat failure rate multiplied by exploding volume is a rising count of real vulnerabilities in shipped software. The rate holds steady; the absolute damage grows because AI writes more of the code every month.

Three independent measurements now point the same way. A third of AI code gets edited away, nearly half ships a known weakness, and the CVEs are stacking up. This is not a new crisis a patch will fix. It is a stable, measured property of generation without governance.

The same pattern shows up in agent security, where the danger is a matter of aim, not raw capability: a model pointed at a task with no security intent produces insecure output, reliably, because nothing in the request asked otherwise.

How do you ship AI-generated code safely?

Treat generation as a first draft, never a deliverable. That is not a knock on the tools. We build with them every day, and the speed is real.

It is a statement about where the work moved. The model closed the gap on writing code that runs, so the human work now concentrates on the gap it did not close: the code that is safe.

Concretely, that means a few things become non-negotiable:

• Ask for security in the prompt. The 45% failure rate is the no-guidance number. Explicit security intent measurably improves it, because the model amplifies the aim you give it.
• Scan in the pipeline. Static analysis in CI catches the uneven failures (the cross-site scripting and log injection holes) that no one can eyeball.
• Keep a person accountable for the merge. Someone who understands the domain owns what ships, because the tool cannot tell you which working function is the unsafe one.

Veracode's own conclusion, from a company that sells scanners and still said the quiet part, is that "the human security review remains irreplaceable."^[1] That is the collaboration we keep describing, stated by the measurement itself.

AI writing half your code is only good news if someone is accountable for the unsafe half. The teams that win this era are not the ones with the best model. They are the ones with a way of working that turns fast generation into safe, shipped software.