Reviewing AI-Written Code: What to Look For

The defect profile has shifted

An application security company went through data from tens of thousands of repos and several thousand developers over six months. What it found fits into one sentence: AI fixes the typos and manufactures time bombs while it does so.

From the same source: AI-assisted developers shipped three to four times as much code, and ten times as many security findings.

(Vendor analysis, from an application security company; they do not disclose how they identified "AI-assisted" code. The shift in the defect profile, however, is confirmed by every other source.)

The practical consequence: do not look for the defect where you look for it in human code. The typo is gone. What is left does not show up line by line.

The number that will not move

The largest-sample measurement tracked more than 150 models over a long period, across 80 coding tasks, four languages and four vulnerability classes.

The result: only 55% of generation tasks produce secure code. In other words, without an explicit security instruction, every second or third case puts a known vulnerability into the code.

And here is the key chart: the syntactic pass rate has risen from roughly 50% to 95% since 2023, while the security rate has stayed essentially flat, between 45% and 55%. The code compiles better and better, and is exactly as vulnerable.

The 55% is the aggregate figure; the breakdown by language and the breakdown by vulnerability type do not run on the same set, so neither of their averages adds back up to it. What the breakdown does tell you is where to look:

This is the single most usable piece of advice in the article: models have learned parameterised queries, they have not learned output encoding. If AI wrote the code, look at output encoding and logging first, not at the SQL. And Java code deserves a round of its own.

One thing that does not help: a bigger model. According to the measurement, model size has a very small effect on security performance; reasoning models land around 70–72% — better, but not a solution.

The hallucinated import

This is the best-measured and most easily checked defect pattern of them all.

A study published at a 2025 security conference put the share of non-existent package names at 5.2% for commercial models and 21.7% for open-weight ones. A 2026 replication on five current models, over 199,845 paired prompts, narrowed that to between 4.62% and 6.10%.

So the spread between models has shrunk by an order of magnitude. The problem has not. One import in twenty may still point at a package that does not exist.

And here is what turns it into an attack surface: the replication found 127 package names that all five models hallucinated identically — and 53 of those are still free to register today. Once somebody registers one, it stops being a defect and becomes an attack.

The check takes two seconds: look up the name of every new import in the package registry before you install it.

The confidence paradox

There is a 2023 experiment worth quoting together with its own limitations: 47 participants, five tasks, the model of the day, mostly university students.

The result has two halves. First: the people working with AI assistance wrote significantly less secure code — 21% versus 43% on the encryption task, 3% versus 21% on the signing task, 12% versus 29% on sandboxed file access.

Second: those same people were more likely to believe they had written secure code.

Small sample, old model — but the second finding has shown up in other measurements since. And there is a side result that converts straight into action: the participants who trusted the AI less, and spent more effort on wording their own request, left fewer vulnerabilities in the code.

The counter-evidence you have to mention

If we wrote up only the above, the picture would be one-sided.

A 2026 long-term observation followed 508 agent-generated and 508 human-generated files across 100 repos for at least six months and more than three thousand commits. Its result contradicts the usual narrative: the AI-generated files received half as many commits in the first month, and needed significantly fewer corrective changes than the human ones.

The maintenance categories point the same way: for AI files the most common activity is adding features (21.8%), for human files it is bug fixing (16.8%).

But the authors themselves put the alternative explanation on the table: less maintenance can also mean the file is used by few people, or hard to understand. A file nobody touches never needs fixing.

One number from the same place says a lot: 83% of the maintenance on AI-generated files is done by humans. On their own files, agents contribute barely a sixth of the commits.

The tests that are supposedly always green

This is the most widespread fear, and the evidence does not support it.

A 2026 study looked at 2,232 test-touching commits across ten TypeScript projects. The AI-written tests contained more assertions (2.00 versus 1.00 on average), their coverage gain was "comparable or larger" than that of human developers, and they were no more complex — only longer.

We found no large-sample measurement of empty AI tests without assertions — only blog posts. The fear is widespread, the evidence is missing.

The real risk sits elsewhere, and it is subtler: a generated test tends to check what the code does, not what it ought to do. That stays green even when the behaviour is wrong. Which is why you start from a failing test, not from a fix.

The real cost: review

Here is the biggest number in the whole article. An analysis covering two years of data from 22,000 developers and 4,000 teams reports the following for AI-assisted code:

Median review time grew more than fivefold. Not because the code is worse, but because it is bigger — and because the reviewer has no idea what the author intended.

And one figure that is about your self-image: editor telemetry following 800 developers over two years shows that AI users perform roughly a hundred more deletions and reverts per month than non-users — for whom the figure is around seven a month. Meanwhile half of those users say their workflow has not changed.

How real is that burden? A well-known open source project everybody depends on shut down its bug bounty programme at the end of January 2026, swamped by generated, untrue reports: in a single week seven reports arrived within sixteen hours, and not one of them found a real vulnerability. The maintainer's reasoning: "we want to remove the incentive to send in garbage."

The checklist

1. DOES EVERY NEW IMPORT EXIST? -> check the package registry.
   4.6-6.1% hallucination rate, and 53 invented names still free.

2. OUTPUT ENCODING AND LOGGING. These are the weakest spots
   (15% and 13% safe rate). SQL the model already knows.

3. PERMISSIONS: does the code get more than it needs?
   Privilege escalation path: +322%.

4. SECRETS in the code, the config, the test data?
   Nearly twice as common with an AI-assisted developer.

5. JAVA CODE GETS ITS OWN PASS. 29% safe rate.

6. DOES THE TEST CHECK WHAT IT SHOULD - not what the code
   happens to do? Start from a failing test, not from a fix.

7. PR UNDER 500 LINES. The established community threshold.
   Above it, review quality collapses.

8. IS THERE AN INDEPENDENT REVIEWER? More than three quarters
   of merged agent PRs are merged by the submitter.

9. NOT REVIEWED BY WHOEVER GENERATED IT. Fresh context is
   needed - the model is biased towards code it just wrote.

Point eight and point nine matter most, and those two are the ones most often skipped. The project instruction file will not solve it for you either: the limits of project instructions post puts numbers on that.

Common misconceptions

• "Generated code is fine these days, look, it compiles." Compilability went from 50% to 95%, the security rate stayed between 45% and 55%. Those are not the same metric.
• "Bigger model, safer code." Model size has a very small effect on it.
• "AI always writes empty tests." The AI tests that were measured work with more assertions and cover at least as much. The risk lies elsewhere.
• "AI code needs more fixing afterwards." A long-term observation says less — but possibly only because few people touch it.
• "Development got faster." Median review time grew by 441%. The time did not vanish, it moved to the reviewer.

What to take away

The defects in generated code are not where the defects in human code are. The typo is gone, and permissions, architecture and secrets came in its place. Review has to be reorganised around that: imports, output encoding, logging, permissions, secrets — in that order, and Java code gets a pass of its own, where the safe rate is 29%. The two organisational rules that are worth the most: PRs under five hundred lines — not a measurement but the established community threshold — and an independent reviewer, because PRs merged without review are up 31.3%.

The detailed numbers on the security side belong to the security bill of AI code post; handing out that first agent task is what the first task with an agent post covers; and how much of all this is worth leaving to a machine is where the AI in code review post takes over.