A team of six engineers adopts AI coding assistants. Three months later, pull request volume is up 40%. The PRs are longer, they arrive more often, and the time available to review each one hasn't changed — there are still six people and the same hours in a day. Something has to give, and what gives is scrutiny per line of code.
None of this is hypothetical. It's the operating reality of most development teams in 2026, and it has a direct security consequence that this year's data lets us quantify precisely.
What the 2026 data says
Veracode has been systematically measuring the security of LLM-generated code since 2025. Their GenAI Code Security report, covering 80 curated coding tasks run against more than 100 models, found that generated code introduces known security vulnerabilities in 45% of cases. Not exotic ones: SQL injection (CWE-89), cross-site scripting (CWE-80), log injection (CWE-117) and weak cryptography (CWE-327) — categories any SAST scanner has detected reliably for a decade.
The March 2026 update adds two more uncomfortable findings. First: the security pass rate has been stuck at roughly 55% across the entire measured period, while coding-capability benchmarks for those same models kept improving. Models write increasingly correct code — syntax correctness now exceeds 95% — that is exactly as insecure as before. Second: larger models don't do better. Vendors' public claims about security-aware training don't correspond to measured outcomes in standardized testing.
There's a third data point, older but more relevant than ever, from a Stanford study presented at ACM CCS: participants with access to an AI assistant not only wrote significantly less secure code than the control group — they were also more likely to believe their code was secure. The relationship between trust in the assistant and security of the result was inverse: the participants who trusted the AI most produced the most vulnerable solutions.
Put the three pieces together: generated code fails on security nearly half the time, the trend isn't improving with better models, and the human accepting it tends to review it with less skepticism than they'd apply to their own code. That's the real-world scenario — not the demo.
The problem isn't the AI — it's the arithmetic
It would be a mistake to read this data as an argument against coding assistants. Human-written code contains vulnerabilities too; none of the categories the models fail at is new. The difference lies elsewhere: in the relationship between code volume and review capacity.
Microsoft and Google stated as early as 2025 that 25–30% of their new code is AI-generated, with some internal repositories above 50% — and the figures climb every quarter. An organization's new code is no longer produced at the speed its engineers type; it's produced at the speed they accept suggestions.
Human review, meanwhile, hasn't scaled. Reviewing code costs the same per line as it did in 2020 — more, actually, because reviewing code you didn't write means reconstructing an intent that doesn't exist: nobody "thought" that code. When input volume multiplies and review capacity stays constant, scrutiny per line drops with mathematical inevitability. It's not a discipline failure. It's arithmetic.
The result: the SQL injection that used to have two chances of being caught — once when written, once when reviewed — now has roughly zero point something: the model generates it fluently, and the human reviewer, with twice the PR queue and the extra confidence Stanford documented, approves it.
Automated scanning stops being a best practice
For years, running SAST and secrets detection on every push was a maturity recommendation: serious teams did it, everyone else leaned on code review. That second option just stopped existing. If human review can no longer sustain per-line scrutiny, automated analysis in the pipeline goes from being the second safety net to being the only one that scales at the same rate as code generation.
A scanner doesn't fatigue on the fortieth PR of the day. Opengrep rules detect the SQL injection with the same reliability on line 10 as on line 10,000, whether it was written by a human, a model, or a human accepting what a model proposed. And the four categories Veracode identifies as the models' systematic failures — SQL injection, XSS, log injection, weak cryptography — are precisely the terrain where static analysis is strongest.
An example of the kind of code passing through reviews right now:
# Assistant suggestion — compiles, passes the tests, closes the ticket@app.get("/users/search")def search_users(q: str, db: Session = Depends(get_db)): """Search users by name with partial matching.""" query = f"SELECT id, name, email FROM users WHERE name LIKE '%{q}%'" return db.execute(text(query)).fetchall()Correct typing, a docstring, impeccable naming conventions — and textbook SQL injection in the interpolation of q. The prepared-statement version would have cost the model exactly the same effort, but the training corpus contains millions of examples with direct interpolation, and Veracode measured what that produces: faced with the choice between the secure and the insecure pattern, models picked the insecure one 45% of the time.
There's something worse than the error: its presentation. Human reviewers calibrate their skepticism on surface signals — messy code, inconsistent naming, missing comments — and AI-generated code triggers none of them. It's uniform, documented, and looks like the work of someone careful. The fluency acts as camouflage: precisely the combination a hurried reviewer's heuristics have no defense against. A scanner doesn't use surface signals — it follows the data flow, and the interpolation of q into the query is equally detectable wherever it came from.
There's a second, less discussed front: secrets. AI assistants reproduce the patterns they see, and examples with hardcoded credentials are abundant both in their training data and in the context developers hand them. A developer who pastes a config file into a prompt to ask for help can get back code with that same credential embedded — and accept it along with the rest of the suggestion. Secrets detection on every push (Gitleaks, in Gerion's case) covers exactly the gap that rushed review leaves open.
Measuring debt at the speed it's generated
That leaves the management question: if code — and with it security debt — is generated faster, how do you know whether your remediation capacity is keeping pace?
Counting findings doesn't answer that. The useful metric is the ratio between the speed at which debt enters and the speed at which it leaves. Gerion's Financial Impact Engine expresses both in the same unit: aggregate Security Debt in euros, and the period's Fix Rate. If your team adopted AI assistants in the last quarter, comparing those two curves before and after adoption is the data point that answers the question your CISO will ask sooner or later: are we generating security debt faster than we're paying it down?
For most teams we've seen, the honest answer is that they don't know — because they measure debt in number of critical findings, a metric that can't distinguish between a CVE on a feature branch and an AI-generated SQL injection that just landed on main with a 10× multiplier.
The practical takeaway
Coding assistants have changed the economics of writing software and they're not going away — nor should they. What does need revisiting is a security architecture designed for a world where code was written by hand and reviewed at leisure. Three concrete adjustments:
- SAST and secrets detection on every push, no exceptions. Not as a maturity aspiration — as the only control whose per-line cost doesn't grow with volume.
- Treat AI-generated code with the same scrutiny as an external contributor's. The Stanford study is clear: the bias runs in the opposite direction, and correcting it takes process, not willpower.
- Measure security debt as a flow, not a snapshot. The relevant question in 2026 isn't how many findings you have — it's whether your Fix Rate is growing at the same pace as your code generation velocity.
Veracode's 45% isn't an argument for scanning AI-generated code. It's an argument for scanning all code, always — because you can no longer afford to assume someone read it carefully before it reached your production branch.