Your AI code compiles. That is not the same as correct

There is a number that gets quoted whenever anyone argues about AI-generated code, and it is usually the wrong one. The interesting figure is not how often AI writes something insecure. It is the distance between two other numbers.

In Veracode's 2026 GenAI Code Security Report, across models scored on security-relevant coding tasks:

• Syntax correctness is now near-universal.
• Only 56% of generation tasks produce secure code.

Read those together rather than separately, because separately they are both unremarkable. Together they describe something specific and uncomfortable.

The code is not broken. It is wrong.

We spent a decade building tooling for a different failure mode. Compilers, linters, type checkers, and test suites are all instruments for catching code that is malformed. They are very good at it, and AI has largely stopped producing that kind of error. A model that gets syntax right essentially always is not going to hand you something that fails to build.

What it hands you instead is code that builds, runs, passes your tests, reads naturally in a diff, and contains an injection path.

That is a different category of problem, and almost none of the instincts we built up over the last decade apply to it. There is no red squiggle. There is no failing test, because the test was written against the same assumptions the flaw was written against. There is nothing in the diff that pattern-matches to wrong.

Why review is the wrong instrument for this

Ask what a human reviewer is actually doing when they read a pull request.

They are scanning for things that look off. A variable named suspiciously. A loop that seems like it might not terminate. A function that got longer than it should have. This is pattern recognition, and it is genuinely valuable, and it works because most bad code carries a tell.

Code from a competent model carries no tell. It is idiomatic. The naming is good. The structure is what you would have written. Everything about it says this is fine, and roughly half the time it is not.

Now add throughput. A reviewer might have caught this at four pull requests a week, given time and a clear head at 10am. At the volume agents produce, with the same reviewer at 5pm on a Friday, the odds are not good and they are not improving. We are asking humans to do more of the thing they are worst at, faster, and calling that a review process.

What actually scales

The alternative is not to remove the human. It is to stop spending the human on work a machine does more reliably.

A policy check does not pattern-match. It evaluates. It does not care whether the code looks idiomatic, whether the naming is good, or what time it is on a Friday. Asked whether this image is pinned, whether that scan is present, whether this service just acquired an ingress it should not have, it returns the same answer every time.

That is a categorically different capability from review, and the distinction matters:

A reviewer catches things that look wrong. A policy check catches things that are wrong. Only one of those scales with agent throughput.

Two kinds of wrong

We built a decade of tooling for the column on the left.

MalformedDoes not build, or plainly misbehaves

Well-formed and wrongBuilds, passes, reads naturally, carries a flaw

Compiler, linter, type checker

A decade of tooling investment

Malformed

✓Catches it

Reliably. This is the thing it was built for, and it is very good at it.

Well-formed and wrong

✗Misses it

The code compiles. That is the entire question this instrument asks.

Test suite

Behaviour someone thought to specify

Malformed

✓Catches it

Catches behaviour that contradicts what a test was told to expect.

Well-formed and wrong

~Sometimes

Only if someone anticipated this case. Often the test was written against the same assumption the flaw was written against.

Human review

Pattern recognition, at human speed

Malformed

✓Catches it

Good at spotting code that reads as off — the tell is what review runs on.

Well-formed and wrong

~Sometimes

Only when the code carries a tell. Competent model output is idiomatic and well-named, and carries none.

Policy gate

Evaluated on every proposal

Malformed

✗Misses it

Not its job, and it does not pretend otherwise. Keep the compiler.

Well-formed and wrong

✓Catches it

For every rule in force: is the digest pinned, is the scan present, did this service just acquire an ingress. Same answer at 5pm on a Friday as at 10am on a Tuesday.

Read the bottom row honestly. A policy gate catches what a rule was written to look for — it is deterministic, not omniscient. That is exactly why the other three rows stay in the table. The claim is not that one instrument replaces the others; it is that only one of them returns the same answer on the four hundredth pull request of the week as it did on the first.

At TruStacks every proposal is checked against a signed Rego bundle before a person sees it. The rules are code, the code has tests, the bundle is versioned and signed, and the customer's own overlay rules can only tighten it, never loosen it. By the time a human opens the pull request, the mechanical questions are already answered.

What is left for the person is the thing they are uniquely good at and a policy engine cannot do at all: does this change make sense, for this system, this quarter, this team. That is judgment, and it is what the approval was always supposed to be about.

The uncomfortable version of this argument

If you take the two numbers seriously, one conclusion follows that most vendors in this space will not say out loud.

As models get better, this problem gets worse before it gets better. A model with 80% syntax correctness produces obvious garbage that everyone catches. A model with 99% syntax correctness produces flawless-looking code that nobody questions. The improvement in fluency is not matched by an equivalent improvement in security, and the widening gap between them is precisely the region where human review fails silently.

Which means the answer is not to wait for better models. The answer is to put a deterministic check between the agent and production, and to keep the human where their judgment actually helps.

Agents propose. Policy decides. Humans approve.

Figures from Veracode's 2026 GenAI Code Security Report, published July 2026. The 56% figure describes tested generation tasks under a security benchmark given no security-specific guidance, not all AI-written code in production, and it varies sharply by flaw class — 83% for SQL injection against 15% for cross-site scripting. Both figures are recorded in our source registry with the methodology and caveats attached.