Frontier Models Got Smarter. Your Code Didn't Get Safer.

The models got a generation smarter in 2026. The security of the code they write didn't. Across more than 150 large language models tested over two years, the share of AI-generated code that passes a basic security review has held at roughly 55%, even as the models themselves vaulted from GPT-4-class systems to reasoning models that top the coding leaderboards (Veracode, March 2026).

That gap, capability racing ahead while safety stands still, is quietly rewriting what the industry optimizes for. For two years the scoreboard was speed: how fast you ship, how many lines the agent writes, how quickly the prototype appears. In 2026 the scoreboard is changing. This is the story of why, and what it means if you build software with AI.

The Flat Line Nobody Expected

Veracode has run the same experiment for two years: hand a stack of large language models 80-odd real coding tasks and check whether the code they return is secure. In its Spring 2026 report, spanning more than 150 models, the result was a flat line. About 55% of generated code passed; roughly 45% shipped a known vulnerability. The models got syntactically near-perfect, with over 95% of the code compiling and running, but the security number barely moved (Veracode, March 2026). The report's own summary is the headline: two years of “revolutionary” releases moved the security needle from about 55% to about 55%.

The breakdown is worse than the average. In the Spring 2026 data, some languages and vulnerability classes fail far more often than others:

By language

Python 62%

Java 29%

By vulnerability class

Insecure crypto 86%

SQL injection 82%

XSS 15%

Log injection 13%

Security pass rate of AI-generated code by language and vulnerability class (Veracode, March 2026)

These aren't exotic bugs. Cross-site scripting and log injection are the OWASP greatest hits, the vulnerabilities every security course opens with. The models can clearly write the secure version — SQL injection and crypto pass most of the time — but on the patterns that need care, they default to the plausible answer, not the safe one, the one that looks right in a demo and fails in an audit.

What 2025 Optimized For

For two years, the metric was speed. The pitch for every AI coding tool was a number with a clock attached: features shipped per sprint, lines generated per hour, the prototype that materialized over a weekend. The market rewarded it lavishly. Anysphere, the company behind Cursor, reached $2 billion in annual recurring revenue by February 2026, the fastest any business-software company has gone from zero to $2B (TechCrunch, April 2026).

There was a logic to it. If an agent can write the code, the binding constraint becomes how fast you can prompt it, and the winning move is to remove every speed bump between intent and output. “Just ship it” became a strategy, not a shortcut, and for a throwaway prototype it usually was the right call. The trouble is that “shipped” and “safe to ship” are different claims, and the distance between them never showed up on the dashboard that counted lines.

The Bill Came Due in 2026

The bill arrived in the data. A causal study presented at Mining Software Repositories 2026 tracked what happened when open-source projects adopted Cursor: a real, statistically significant jump in development velocity, followed by a “substantial and persistent increase in static analysis warnings and code complexity” that then dragged velocity back down (He et al., MSR 2026). The speed was transient. The complexity was permanent.

Other measures point the same way. GitClear's analysis of 211 million changed lines found that refactoring, the work of consolidating and cleaning code, fell from a quarter of all changes in 2021 to under a tenth by 2024, while copy-pasted code rose past code that was simply moved, a first in their dataset (GitClear, 2026). Google's DORA 2025 report, drawing on nearly 5,000 developers, found that AI adoption lifted throughput but kept its “negative relationship with software delivery stability”: more change failures, more rework (DORA, September 2025).

Developers feel it. In Stack Overflow's 2025 survey, favorable sentiment toward AI tools slid from over 70% to 60% in a single year; more developers now distrust AI accuracy (46%) than trust it (33%), and 45% say debugging AI-generated code takes them longer than writing it themselves (Stack Overflow, 2025). The tools got more capable and less trusted at the same time. We covered the underlying defect data in why vibe coding breaks at scale; the new development is that the whole industry is now reacting to it.

When It Stopped Being Theoretical

Statistics are easy to wave away until one of them has your customers' data in it. In April 2026, security researchers disclosed a flaw in Lovable, one of the most popular AI app builders, that let any free account read other users' projects — source code, database credentials, and AI chat histories among them. The root cause was a textbook Broken Object Level Authorization: an API that never checked whether the requester owned the record it returned. It was reported in early March and stayed open for 48 days before public disclosure (The Next Web, April 2026).

Lovable initially disputed that it was a breach at all, describing the exposed code as “intentional behavior” before apologizing (The Register, April 2026). But the mechanism is the lesson. Broken object-level authorization is exactly the kind of check an AI will omit unless something forces it not to: the model generated a plausible endpoint, and nobody — human or machine — verified the one rule that mattered. That is the flat security line showing up in production, with a customer list attached.

Why a Better Model Won't Save You

The instinct is to wait for the next model. It's a reasonable instinct, and the data says it's wrong. Veracode's two-year flat line spans exactly the period of the largest capability gains in the field's history; the models that top today's coding benchmarks score within a few points of GPT-4-era systems on security (Veracode, March 2026). A more capable model writes more sophisticated code, not more secure code. Those are different objectives, and nothing in “predict the next token of a plausible solution” optimizes for the second.

The pattern held into June. Anthropic shipped Claude Fable 5, its most capable model yet, on June 9, 2026; the launch led with a record coding-benchmark score (80.3% on SWE-Bench Pro) and a set of safety guardrails that route risky prompts to a more constrained model (Anthropic, June 2026). Read that again: the safety story was about routing and refusals, not about the security of the code the model produces. The frontier moved. The question this post opened with didn't.

There is one honest exception. Veracode found that extended-reasoning configurations, models that “think” before answering, did better, clearing 70–72% on the same security tests (Veracode, March 2026). That's real, and it's a lead worth pulling. But 70% still means three in ten samples are insecure, and it's a property of how you run the model, not a free upgrade that arrives with the next release.

Capability is what the benchmarks measure. Safety is what the next breach measures. In 2026 the industry finally noticed they aren't the same number.

The Pivot: From Velocity to Verification

If the model won't deliver safety, something around it has to. That realization is what's actually shifting in 2026, and it has a clear shape: stop asking the AI to be careful and start checking that it was. Thoughtworks put it plainly in a May 2026 piece on securing AI-built software (Thoughtworks, May 2026):

Telling an AI agent to be safe is not the same as enforcing that it is safe. Prompts can be overridden, misunderstood, or ignored.

You can see the pivot in where money goes. An entire product category, AI code review, now exists for the sole purpose of checking AI's output, and teams buy it as a line item rather than a nice-to-have. Evaluations, once a research-lab concern, are becoming table stakes for anyone shipping AI features. The same logic is reviving an old discipline under a new name: harness engineering, the practice of wrapping an agent in the tests, type checks, and review gates that catch what it misses — the layers we map in the 2026 AI agent stack.

The obvious question is whether AI can do the checking too, standing in for the human reviewer most teams are short on. It can, with one hard rule: the reviewer cannot be the model that wrote the code. Anthropic's 2026 research on long-running builds found that agents have a self-evaluation bias — they tend to praise their own work — so a separate evaluator agent, run against deterministic gates, catches far more than asking the author to grade itself (Anthropic, March 2026). The setup that works pairs a generator with an independent reviewer and non-negotiable automated checks. That is verification, and the flat security line is what makes it mandatory rather than optional.

What It Means If You're Shipping a SaaS

For anyone building a SaaS with AI, the takeaway is narrow and useful: you cannot ship-fast your way out of a flat security curve, so the speed you get from AI has to be matched by enforcement you don't skip. The teams that come out ahead in 2026 aren't the ones that slowed down. They kept the velocity and bolted verification underneath it — a spec the agent codes against, a tenancy rule it can't bypass, and tests and security scans that run on every commit whether or not the agent remembered to care.

This is the whole idea behind structured vibe coding: keep the speed, add the layer that makes the output trustworthy. It's also why we wired that layer into the product instead of leaving it in the docs.

The Honest Version

Two caveats, because the strong version of this argument overreaches. First, this is a recalibration, not a retreat from speed. Nobody is shipping slower on purpose; the market is still paying for velocity, and paying enormous sums — Cursor's run rate and reported talks to raise at a $50 billion valuation say the spend hasn't flinched (TechCrunch, April 2026). The shift is in what “good” means, not in how fast anyone moves.

Second, “AI code is just unsafe” is too blunt. DORA's reading is that AI amplifies whatever a team already is: strong teams with good tests and fast feedback gain from it without the instability penalty (DORA, September 2025). The problem was never that the model is bad. It's that, on average, the guardrails are missing, which is the same conclusion from the other side. The flat security line isn't a reason to stop using AI. It's the reason to stop trusting it unverified.

Frequently Asked Questions

Have more questions? See our full FAQ →