Reading AI-Generated Code for the Vulnerability Patterns That Repeat

A quiet shift happened inside security teams over the last year: instead of treating AI-generated code as a special new category requiring new expertise, the workshops that started running internally in 2026 have converged on a much simpler premise. The vulnerabilities aren't new. What's new is the volume they're arriving in, and the speed at which they need to be caught. The workshop material isn't "how AI code is different" — it's "here's the small set of patterns that keep recurring, learn to spot them fast, because you're going to see a lot more code than you used to."

That reframe matters because it changes what "getting good at reviewing AI code" actually requires. It's not a new discipline. It's the old discipline of secure code review, applied with more urgency because the volume went up an order of magnitude and the reviewer's time didn't.

Why the same patterns keep showing up

Language models generate code by pattern-completing against what they've seen — vast amounts of code from public repositories, tutorials, and documentation, much of which itself contains outdated or insecure patterns, because that's simply what a large fraction of real-world code looks like. A model isn't reasoning from first principles about whether a given input should be sanitized; it's producing the statistically likely continuation of a prompt, and the statistically likely continuation often mirrors code that was written without security as a primary concern, because most code in the training distribution wasn't written with that as a primary concern either.

This is why the same handful of vulnerability classes show up again and again across completely different projects and completely different prompts — they're not a bug in one model's training, they're the default shape of "code that looks correct and typically runs" across the broader corpus the model learned from. A reviewer who internalizes the short list of recurring patterns can catch a large share of real issues without needing to read every line with equal suspicion.

The patterns worth knowing cold

A few categories account for a disproportionate share of what actually gets found in these audits:

Input handling that trusts the input. Code that takes a user-supplied value and uses it directly — in a query, in a shell command, in an HTML template, in a file path — without validating or escaping it first. This is the parent category behind SQL injection, path traversal, and the XSS and log injection failures common enough to deserve their own dedicated look at why those two specifically recur so often. It shows up because "take the input and use it" is the simplest, most common shape of example code the model has seen, and the sanitization step is often a separate, less prominent pattern that gets dropped when the model is optimizing for a concise, working-looking answer.

Credentials and secrets treated as ordinary strings. Covered in depth in the piece on the 3.2% leak rate — the model has no separate handling for values that happen to be sensitive, so they get generated and reproduced exactly like any other string in the pattern it's completing.

Permissive defaults. CORS configured to allow any origin. File uploads accepted without type or size restriction. API endpoints with no rate limiting. These aren't things the model gets "wrong" exactly — permissive configuration is genuinely the fastest way to get a demo working, and a model optimizing for "does this run and satisfy the prompt" will reliably choose the permissive option over the restrictive one, because the restrictive option usually requires more code and more context the model doesn't have about your actual security requirements.

Missing error boundaries around trust transitions. Code that doesn't validate what comes back from an external API, a database, or a file read before acting on it — assuming the happy path is the only path. This one is subtle because the code looks complete; it has a function, it does the thing, it just doesn't ask "what if this returns something I didn't expect."

Authorization checks that verify authentication but not authorization. Confirming a request came from a logged-in user is not the same as confirming that user is allowed to access this specific resource. This distinction is easy to miss when scanning quickly, and it's exactly the kind of gap a model will happily leave out because the prompt asked for "a function that returns the user's order," not "a function that returns the user's order and confirms the requester is that user."

Why pattern recognition beats line-by-line reading

The instinct when someone says "review this more carefully" is to read every line slowly. For AI-generated code at the volume most teams are now producing, that doesn't scale, and it's not actually where the leverage is. A reviewer who's internalized the five or six recurring patterns above can scan a pull request in a fraction of the time a full line-by-line read would take and still catch the overwhelming majority of real issues, because those patterns account for a disproportionate share of what actually gets found.

This is closer to how experienced security reviewers already worked before AI-generated code existed — pattern recognition built from having seen the same mistakes enough times to spot them at a glance. What's changed is that this skill now needs to be taught deliberately and early, rather than absorbed slowly over years of incidental exposure, because the volume of code needing this kind of scan has grown faster than the organic rate at which engineers used to develop the instinct.

Turning this into something a team actually does

Knowing the patterns is necessary but not sufficient — the workshops that work well pair pattern knowledge with a habit, not just a lecture. A few things separate teams that actually catch these issues from teams that know about them abstractly but still ship them:

• A checklist that lives inside the PR template, not in a wiki page nobody opens — the five patterns above, phrased as yes/no questions a reviewer answers before approving.
• Deliberately reviewing a batch of known-bad AI-generated examples together as a team, the same way security teams have long run tabletop exercises — pattern recognition improves faster with repetition on real examples than with abstract description.
• Treating this as a rotating responsibility, not a specialist's job — on a small team without a dedicated security function, every engineer needs enough of this pattern vocabulary to catch issues in their own generated code, because there's no one else who's going to.

The workshops succeeding at this in 2026 share one trait: they stopped treating AI code review as a mysterious new discipline and started treating it as applied pattern recognition against a short, well-understood list — which is a skill any engineer can build in a few focused sessions, not a specialization that requires years to acquire.

That's genuinely good news. The vulnerability classes aren't exotic. They're old, well-documented, well-understood categories that security teams have been teaching for two decades. What changed is the volume of code that needs this lens applied to it — and volume is a training and process problem, not a fundamentally new technical one.

Part of the "From Vibe Coding to Production" series on aiskill.market.