44% of AI code-generation tasks introduce a vulnerability. Your pipeline doesn't know which 44%

Two numbers, and they only mean something together.

In Veracode's 2026 GenAI Code Security Report, 44% of AI code-generation tasks introduced a known security flaw — the average security pass rate across models tested was 56%. Separately, by DX's analysis, AI now authors roughly half of all committed code.

So: a large and growing share of what lands in your repository comes from a process that gets security right a bit more than half the time. And nothing in the output marks which half you got. There is no flag, no warning, no tell. The 44% and the 56% look exactly alike on the way in.

That is the actual problem. Not that AI writes insecure code sometimes — humans do too. It is that the failure is unlabelled and now arrives at volume.

And 44% is an average, which hides the shape of it. The benchmark is close to dependable on some flaw classes and close to useless on others, so "roughly half the time it's fine" is the wrong model to walk away with:

Security pass rate by flaw class

The average is 56%. Almost nothing is actually 56%.

• Cryptographic algorithms

  87%

• SQL injection

  83%

• Cross-site scripting

  15%

• Log injection

  12%

Filled is the share of generation tasks that produced secure code. The empty remainder introduced a known flaw. The vertical hairline on each track is the benchmark-wide 56% average — the number the headline quotes, and one that no individual class here sits near.

Veracode, 2026 GenAI Code Security Report (2026-07-28). Measured under a security-focused benchmark with no security-specific guidance given to the model — not a measurement of all AI-written code in production.

The reflex, and why it doesn't hold

Say this to most security teams and the answer comes back quickly: add more scanning. Turn on SAST. Add SCA. Put a scanner in the pipeline and let it catch what the model got wrong.

Keep the scanners — genuinely, this is not an argument against them. But notice what you are asking them to do, because it is not what they are built for.

A scanner reports after the code exists. In most pipelines, after it has merged. It produces findings, into a queue, that a human triages. That model worked when the inflow was bounded by how fast people could write code, because the queue drained about as fast as it filled.

The inflow is no longer bounded that way. You have added a writer that never gets tired, and left the triage capacity exactly where it was. A scanner in that arrangement is not a control. It is a very thorough smoke alarm that someone reads on Monday.

The telemetry says the process is already buckling

This is not a projection. Faros AI analyzed two years of engineering telemetry across 22,000 developers and more than 4,000 teams, comparing each organization against itself between its lowest- and highest-AI-adoption periods. Four findings, in the order that makes them worth reading:

• Pull requests merged per developer: +16.2%. The throughput gain is real. It is also more modest than the discourse suggests.
• Median time in code review: +441.5%. Review did not keep pace. It fell behind by a factor that dwarfs the throughput gain.
• Pull requests merging with no review at all: +31.3%. Not because anyone decided to stop reviewing. Because the queue got longer than the day.
• Incidents per pull request: +242.7%. For every change merged, the probability of a production incident more than tripled.

Low to high AI adoption, measured within the same organizations

Everything moved. Only one of these was the goal.

What improved

• ▲Pull requests merged per developer

  +16.2%

What it cost

• ▼Median time in code review

  +441.5%

• ▼Incidents per pull request

  +242.7%

• ▼Pull requests merged with no review

  +31.3%

The hairline on each track marks +100% — the point at which a measure has doubled. Both of the two largest costs run past it. Neither the throughput gain nor the rise in unreviewed pull requests comes close.

Two years of engineering telemetry; 22,000 developers across more than 4,000 teams. Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash. Observational telemetry compared within each organization, not a controlled experiment — it shows what happened as adoption rose, not that AI caused it.

Put the first and last together. Throughput rose about 16%. The incident rate per change rose about 243%. Whatever you think of AI-assisted development, that is a bad trade, and it is a trade almost nobody consciously made.

The honest caveat, because this post does not get to skip it: that is observational telemetry, not a controlled experiment. It shows what happened in organizations as adoption rose, not that AI caused each incident. The direction is consistent across four independent metrics, which is why it is worth taking seriously — but it is correlation, and you should read it as such.

Why the queue is the wrong place to stand

The deeper problem with catching this downstream is not throughput. It is where the finding lands relative to the decision.

A scanner finding arrives after a person already decided the change was fine. Reversing that decision now costs a revert, a conversation, and someone's afternoon. So findings get deferred, batched, accepted-with-a-ticket. Not through negligence — through the ordinary economics of interrupting work that looks finished.

A check that runs before anyone forms an opinion costs nothing to act on. Nobody has committed to anything. There is no decision to reverse and no awkwardness in reversing it. The same finding, moved earlier, changes from an argument into a fact about the change.

That is the whole reason to put the gate where we put it: not because policy evaluation is cleverer than scanning, but because the same information is worth far more before the merge than after it.

What this looks like in practice

At TruStacks the agent crew opens every change as a pull request, and every proposal is evaluated against a signed policy bundle before a human sees it. Rules are code, the code has tests, the bundle is versioned and signed, and your own overlay rules can tighten it but never loosen it.

By the time a person opens the PR, the mechanical questions are answered. Is the image digest pinned. Is the scan present. Did this service just acquire an ingress it should not have. What is left is the judgment a policy engine cannot make and a person is uniquely good at: does this change make sense, here, now, for this system.

And the human still merges. There is no configuration flag that changes that — not because the agents are untrustworthy, but because the merge is where accountability lives, and 44% is a very good reason to keep a name attached to it.

What this argument is not

It is not that AI-generated code is bad and you should write less of it. We are an AI company; the crew that opens these pull requests is agents. The throughput is real and worth having.

It is not that scanners are useless. Keep them. They catch entire classes of problem no policy bundle was written to look for, and defense in depth is defense in depth.

The argument is narrower, and it is about sequencing. If the only thing standing between a 44% security pass rate and production is a queue that a human drains at human speed, you do not have a control — you have a backlog with good intentions. Move the deterministic part earlier, and spend the human on the part that actually needs one.

Agents propose. Policy decides. Humans approve.

The 44% and 56% figures are from Veracode's 2026 GenAI Code Security Report (July 2026); pass rates vary sharply by flaw class, from 83% on SQL injection to 15% on cross-site scripting. The share-of-committed-code estimate is DX's, cited by Veracode. The telemetry figures are from Faros AI's The Acceleration Whiplash (April 2026), measured within each organization between its lowest- and highest-AI-adoption periods. Every figure here is in our source registry with its sample and caveats attached.