Reviewing AI-written code: a checklist for what to scrutinise

The five categories of mistake

AI-written code goes wrong in characteristic ways. Five categories cover most of the real problems:

1. Plausible-but-wrong API usage. The agent calls a method that doesn't exist on the type, or uses an old version of an API, or invents a parameter name that looks reasonable. Type-checked languages catch a lot of this; loosely-typed code does not.

2. Silently dropped requirements. You asked for X and Y, the agent built X, the tests for X pass, and Y is just... missing. The output looks complete because it ran. Skim the diff against your requirements list, not against your assumptions.

3. Over-engineering. The agent adds abstractions, configuration knobs, and "flexibility" you didn't ask for. The code works but is harder to maintain. Watch for new files, new exports, new options.

4. Sycophantic patches. When the agent is corrected, it sometimes patches just enough to make you go away; adding a special case rather than fixing the underlying issue. Look for narrow conditionals that exist only to handle the specific case you flagged.

5. Confidently-wrong reasoning. The agent's explanation of what the code does is wrong, and the code matches the wrong explanation. You read the explanation, agree with it, and never check the actual behaviour. Run the code; don't take the agent's word.

A 10-minute review checklist

A workable review pattern, in order:

1. Read the diff against requirements, not the agent's description. Open your original prompt or task spec. Walk through the diff item by item. Anything missing? Anything extra?

2. Run the code. Don't just look at it. Actually run it on a real input you didn't test in the prompt. Edge cases, empty inputs, malformed inputs. AI code passes happy paths reliably and breaks on edges that weren't in the test suite.

3. Check the tests. Are the tests testing the actual behaviour, or are they testing what the agent assumed? Tests written by the agent often pass because the agent designed them to. Read the assertions, not just the test count.

4. Look for new dependencies. New imports, new packages, new external calls. Each one is a decision worth confirming.

5. Spot-check the explanation. Pick one section of the agent's description and verify it matches the code. If the explanation says "we cache the result," check that the code actually caches the result.

6. Read it once more, fresh. A second pass with a clear mind catches things the first pass missed. AI code reads convincingly the first time, less so the second.

This review should take 5-15 minutes for a typical change. If you find yourself reading for an hour, the change is too big; break it down.

Set up the codebase to make review easier

A few investments make AI-written code dramatically easier to review:

Strict type checking. TypeScript with no any, full strict mode, and strict null checks catches a huge fraction of plausible-but-wrong API usage automatically. Same for Rust, Kotlin, etc. Languages that allow loose typing pay a tax on AI-assisted code review.

A test suite that runs in seconds. If running the tests takes a minute, you'll skip them. If they run in five seconds, you'll run them constantly. Fast tests are an AI-coding multiplier.

A pre-commit hook that runs lint and types. Errors caught at commit time never make it into a PR. The agent often produces lint errors that a quick npm run lint would catch; automate this.

A short AGENTS.md or similar. A one-page document about your codebase's conventions; naming, file structure, error-handling patterns; helps the agent produce code that doesn't need stylistic review every time.

Focused PRs. Small PRs are easier to review whether the author is human or AI. Encourage one-concept PRs.

None of this is unique to AI-assisted work. AI assistance just rewards the codebase hygiene that you should have anyway, and punishes the absence of it more sharply.