AI Code Works. It's Rarely Secure.

Two curves moved in opposite directions over the last two years, and most teams are only tracking one of them.

The first curve is syntax correctness: whether AI-generated code compiles, passes its tests, and does what the prompt asked. That curve has climbed from roughly 50% in 2023 to over 95% today across frontier models. The second curve is the security pass rate: whether that same code is free of a known vulnerability class when no security instruction is given. That curve has been flat at approximately 55% for two years, across model generations, across parameter counts, across every headline release from every major vendor.

Read that again. Nearly half of AI-generated code carries a known security flaw, and the newest, most capable models are no better at avoiding it than the ones from two years ago. The industry got dramatically better at writing code that works and made essentially no progress on writing code that's safe.

Working and secure were never the same target

Veracode's Spring 2026 testing, run across the newest flagship releases (GPT-5.1 and 5.2, Gemini 3, Claude 4.5 and 4.6) against a fixed set of 80 coding tasks spanning four languages and four vulnerability classes, found the security ceiling holding at roughly 55% regardless of which model wrote the code. Model size barely moved the number. Reasoning-focused variants did better, landing at 70 to 72%, which is the single largest jump the research has documented, and is still a coin flip's distance from acceptable.

The breakdown by vulnerability type is the more interesting finding. Models do well on SQL injection (82% pass) and weak cryptography (86% pass), the pattern-matchable failures that appear constantly in security training material and public code review. They do badly on cross-site scripting (15% pass) and log injection (13% pass), the failures that require tracking how a piece of user input moves across multiple functions and files before it lands somewhere dangerous. That is not a training data gap that scales away with a bigger model. It is a structural mismatch: these models are excellent local pattern matchers and poor global dataflow reasoners, and the vulnerabilities that survive are exactly the ones that require the reasoning they don't have.

Java is the sharpest version of this problem: a 29% security pass rate, the worst of any language tested, plausibly because the public training corpus is dominated by a decade of enterprise Java written before current secure-by-default patterns existed. A model trained on that corpus reproduces what it saw most, not what's safest.

The gap is not going to close by watching harder at write time

The obvious response is to catch this earlier: govern the agent, review its output before merge, add a linter pass tuned for AI-generated patterns. Every major vendor has moved there. Endor Labs shipped AURI to catch vulnerable code inside the coding assistant itself, before a commit happens. Checkmarx's newest Assist agents run a continuous find-fix-verify loop directly inside the developer's AI coding tool.

These are real improvements and worth having. They are also, structurally, opinions formed at write time: judgments about what a piece of generated code is likely to do, made before it has done anything. Write-time review answers "does this look dangerous." It cannot answer "did this specific deployment, with this configuration, actually expose the flaw," because that fact does not exist yet at the moment the review runs.

The volume problem makes this worse, not better. As AI-assisted development scales from early adopters to the median engineering team, more code gets generated per day than any write-time review process, human or automated, can examine at the depth the data says is required for the failures that matter (cross-site scripting, log injection, anything requiring cross-function reasoning). Catching a percentage of it earlier does not solve for the code that gets through, and the data says a lot gets through.

Runtime narrows an unreviewable volume to a checkable one

This is the same argument that applies to any code, human-written or AI-generated, and it applies harder here because the volume is higher and the review capacity is fixed. A vulnerability that never executes, regardless of who or what wrote it, is not the operational problem. The operational problem is the vulnerability sitting in code that is actually loaded, actually reachable from a real ingress point, and actually invoked in production.

Kodem's Kai reviews AI-generated code contributions before merge, but the claim that matters is downstream: runtime intelligence confirms which AI-generated code paths are actually loaded and executed after deployment, turning an unreviewable volume of generated code into a much smaller, execution-confirmed set that a security team can actually act on. This does not require AI-generated code to be treated as magically more dangerous than human code. It requires treating it as an elevated-scrutiny class, because the Veracode numbers show its failure modes cluster in exactly the vulnerability types (dataflow-dependent, cross-function) that both static tools and the models themselves handle worst.

What actually reduces the risk today

Three things, in order of leverage. First, keep security-focused prompting and static analysis at commit time. It is not sufficient on its own, but the 55% number is the baseline with no security guidance at all; explicit guidance measurably helps. Second, treat AI-generated code as a class that gets runtime-validated after deployment, not just reviewed before it. Third, weight review effort toward the vulnerability classes the data says are hardest: anything requiring tracking user input across functions, not the pattern-matchable ones models already handle well.

The gap is the story, not the models

The productivity gains from AI-assisted coding are real, and so is the growing distance between code that works and code that's safe. That gap will not close by prompting harder or shipping the next flagship model. It closes by pairing generation with execution evidence, which is the only signal in this whole chain that does not depend on how carefully anyone reasoned about the code before it ran.

Frequently asked questions

Do newer, more capable AI models write more secure code?

Not meaningfully. Security pass rates have held near 55% across two years of model releases, including the most recent flagship models from every major vendor. Reasoning-focused models reach 70 to 72%, the best result documented so far, still short of what production security requires.

Which vulnerability types does AI-generated code get wrong most often?

Cross-site scripting and log injection, both requiring multi-step dataflow reasoning, sit at 13 to 15% security pass rates. SQL injection and weak cryptography, both more pattern-matchable, sit at 82 to 86%.

Does write-time agent governance solve this?

It helps, but it is a judgment made before the code has executed. It cannot confirm whether a specific deployment actually exposes a flaw, only whether the generated code looks risky in isolation.

References

• Brombacher, F. (2026, March 24). Spring 2026 GenAI code security update: Despite claims, AI models are still failing security. Veracode Blog. veracode.com
• PR Newswire. (2026). Endor Labs introduces AURI, security intelligence for agentic software development. Cision PR Newswire. prnewswire.com
• SD Times. (2026, July 17). Checkmarx unveils self-healing application security in Assist Agent family. SD Times. sdtimes.com