The review-loop guides · a straight answer

How to review AI-generated code before you ship it

The agent wrote it in a minute and it runs. That's not the same as correct — and "it runs" is exactly the trap. Here's the review that catches what LLM code gets wrong.

Short answer: review AI-generated code against its own failure modes, not a generic checklist. LLMs produce code that runs and reads well while being subtly wrong — invented APIs, unstated assumptions, security left as an exercise, tests that assert nothing. Read every line before you accept it (never merge code you can't explain), run it against the cases the prompt didn't mention, and get a human to look at anything user-facing — because "compiles and passes" is the bar the AI already cleared, not the one that matters.

The dangerous property of AI-written code isn't that it's bad — it's that it's plausible. Human junior-dev mistakes look like mistakes. LLM mistakes look like senior code: clean names, confident comments, a tidy structure wrapped around a wrong assumption. So a review that just asks "is this readable?" passes it every time. You have to review for the specific ways generated code fails.

The AI-code red flags

Tap each to expand. These are the ones worth a deliberate look on generated code — where "looks fine" and "is fine" most often diverge.

▲Hallucinated APIs and packages›

Method names, config keys, and library functions that sound exactly right and don't exist. Worse: an npm install of a package name the model invented — a real supply-chain risk if a squatter has claimed it. Tell: check every unfamiliar function against the actual docs, and every dependency against its real registry page before installing.

▲Unstated assumptions about your data›

The code handles the happy path you described and silently assumes the rest — non-null fields, sorted input, one currency, UTC, an array that's never empty. Tell: run it against empty, huge, null, duplicate, and out-of-order inputs — the cases your prompt never mentioned.

▲Security left as an exercise›

String-built SQL, unescaped user input rendered into HTML, secrets hard-coded or logged, auth checks assumed to exist upstream, permissive CORS. The model optimizes for "works," not "safe." Tell: trace every path from user input to a database, the DOM, or the shell, and confirm it's parameterized/escaped.

▲Tests that assert nothing›

A green suite that only exercises the happy path, mocks away the logic under test, or asserts toBeDefined(). Coverage numbers with no teeth. Tell: for each test, ask "what real bug would this fail on?" If there's no answer, it's decoration.

▲Silent scope creep›

You asked for one function; it refactored three files, renamed things, swapped a library, or added a dependency you didn't ask for — buried in a large diff that looks like progress. Tell: read the whole diff, not the summary. Reject changes outside what you asked for.

▲Outdated or averaged-out patterns›

Deprecated APIs, an old framework idiom, or a "median of the training data" approach that ignores your codebase's conventions. Tell: does it match how the rest of your repo does this? Consistency beats the model's default.

The half of "review" that code review misses

Reading the code tells you it's correct. It can't tell you the result is good — whether the page it renders is clear, whether the flow makes sense to someone who isn't you. That's a different review with a different reviewer: a human looking at the running output. For anything user-facing, ship the rendered page to a couple of real people and let them pin what's confusing right on it — if an agent built it, it can share the live page via an MCP tool and read the notes back to fix them. That's twocents: code review checks the code; this checks what your users will actually see. Do both before you ship.