Better AI models haven't written safer code

Veracode has run the same GenAI code-security benchmark across generations of frontier models: GPT-5.1 and 5.2, Gemini 3, Claude 4.5 and 4.6, and more than 100 models before them. Over that period, syntax correctness climbed from roughly 50% to about 95%. The code learned to run. The security pass rate, the share of tasks where the model produced code without a known vulnerability, stayed near 55% throughout.

Veracode's own summary is drier than any warning we would write: "Two years of 'revolutionary' model releases have moved the security needle from approximately 55% to... approximately 55%" (Veracode, Spring 2026). Between those two numbers sit GPT-4 through GPT-5, a jump the industry treated as a generational leap. On this measure it landed inside the margin of error of where it started. One caveat on the number itself: 55% is an average across a wide field of models, from cheap and old to current frontier, so the best model available today sits above it and the weakest well below. The point is not that every model is stuck at 55%. It is that two years of raising the ceiling did not raise the average.

Veracode sells application-security tooling, and a finding that AI-generated code needs scanning helps Veracode. Weigh it accordingly, and weigh us the same way: Taiga sells a gate, and "AI code needs a gate" is our pitch as much as scanning is theirs. What makes the line hard to wave off despite both incentives is that it is longitudinal and self-consistent: one method, one test, applied release after release, showing the same result. The direction also holds outside Veracode. Pearce et al. measured roughly 40% of GitHub Copilot completions as vulnerable across security-relevant scenarios back in 2022 (IEEE Symposium on Security and Privacy, 2022). Tihanyi et al. generated 331,000 C programs across nine models and formally verified at least 62% as vulnerable (Empirical Software Engineering, 2024). Apiiro found privilege-escalation paths in AI-generated code rising 322% across Fortune 50 repositories while syntax errors fell 76% (Apiiro, 2025). Different labs, different methods, same shape: the code got cleaner on the surface and no safer underneath.

The line is not perfectly flat forever. OpenAI's reasoning models are the exception, reaching about 70 to 72% on the same benchmark, a step up Veracode already recorded in late 2025 rather than a fresh 2026 surprise (Veracode, Spring 2026). That is a genuine break in the trend, and it matters: it is direct evidence that model improvement can move the security curve. But the improvement is narrow. One model family, to roughly seven-in-ten. That leaves about 28% of tasks still flawed, against 45% flawed at the older 55% baseline (Veracode, 2025)[5], the number the sibling research walks through in full. Better than before. Not a pass for a bank shipping a payments service or a hospital shipping a patient-record system.

The flat line stops being a mystery once you look at what these models are trained and measured on. Benchmarks reward code that runs, passes the tests, and answers the prompt. Those are visible properties: a test suite goes green or red. Security is mostly invisible. A missing authorization check, a logged secret, an injection path: the code compiles, the tests pass, the demo works, and the flaw sits there until an attacker or an auditor goes looking. The training signal that made models brilliant at the visible task is weak to absent on the invisible one.

So the capability curve and the security curve were never the same curve. Making a model better at reasoning makes it better at reasoning. It does not, on the evidence, make it careful about the things nobody wrote a reward for. The Veracode breakdown shows this weakness by weakness: the models handle SQL injection reasonably, around 82%, and collapse on cross-site scripting to about 15% and log injection to about 13% (Veracode, Spring 2026). The gaps are stubborn in exactly the places that are hardest to catch in a diff.

This is why "wait for the next model" is not a security plan. It is a bet that a curve which has crept, not climbed, over two years will arrive in time for your next audit. Even the hopeful data point, the reasoning models at 70 to 72%, hands three flawed tasks in ten to a review process that has to catch every one of them.

If the generator will not get safe on its own, the safety has to come from somewhere else: the gate the output has to pass before it ships.

An executable control can reject an unapproved dependency or detect a missing configuration if that rule is implemented and the check covers the relevant case. Record the result from the actual build, its scope and its limitations. A policy in context, a passing scanner and a human approval are different forms of evidence.

Taiga publishes 22 readiness questions across governance, security, build and run. They organize evidence review; they are not one universal automated release gate. Check the source, scope and result of each relevant control for the particular system you are accepting.

No single pass rate tells you whether your system is safe. Select controls for the failure modes that matter, inspect what the tools miss, and verify the implementation and operating responsibilities before accepting the change.

Better models are coming. They will write faster, more capable code, and on current trend they will keep handing you a security pass rate that a regulated deployment cannot accept unreviewed. Waiting for them to close that gap has been a two-year bet that has not paid off. Gating the output does not require the bet at all.