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.

A gate is not a smarter model. It is policy written down as executable checks, run on every build, producing evidence you can hand to an auditor. An unapproved dependency fails the build and names the rule it broke. A missing audit log fails the build. The check does not care which model wrote the code or how high it scored on a leaderboard. It records whether this specific artifact meets this specific bar, pass or fail. An auditor examining your change control under DORA, NIS2, or the EU AI Act asks for exactly that kind of record: evidence that every change passed a defined control, not "we used a good model."

This is what Taiga does, to be exact about it. Taiga does not make models write secure code. Nobody can, on this evidence. What Taiga does is make governed production not depend on the model being safe by default. Every run is measured against a published bar of 22 checks[7], and the output is the same standard artifact set plus a pass-or-fail result against each check. The bar is fixed and public. That is the differentiator, not the model behind it. The commercial point follows from the same fact: if better models made the gate unnecessary, they would have moved the number by now, and they have not.

You do not need the generator to reach 100% before you can ship code you can defend. You need a gate that assumes the generator is at 55% and catches what the 55% lets through. What it lets through is not a temporary condition to be patched by a download next quarter. It is governance debt that accrues quietly on every ungated merge, in exactly the categories a scanner is worst at seeing, until the balance comes due.

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.