You review AI-generated code by treating it as an untrusted pull request from a stranger: read the full diff, verify every import and API call actually exists, run the test suite and linters, check error handling and security-sensitive lines, and confirm the licence of anything copied in — then fix what fails before it merges.
Never merge AI code just because it looks clean and the tests pass on the first run. The single most useful habit is to ask "what would break this?" for each function and write a test that answers it, because AI code fails in specific, predictable ways rather than random ones.
Why AI code needs a different review than human code
AI models generate code the same way they generate prose: by predicting the most plausible next token. That means the output is optimised for looking correct, not for being correct. A function name, a library method, or a config key can be invented wholesale and still read perfectly.
The failure modes cluster in a few places: hallucinated packages (a plausible-sounding npm or PyPI name that does not exist, which is also a supply-chain risk if someone later registers it), APIs called with the wrong argument order or a parameter that was renamed two versions ago, missing error handling on the happy path, off-by-one and boundary bugs in loops, and quietly dropped edge cases the original ticket mentioned. Human reviewers often catch these because they remember the API; AI reviewers frequently do not, so the check has to be mechanical rather than memory-based.
According to our AI tool database, which tracks 360 AI tools with pricing and capability snapshots recorded at verification time, the most recent verification date being 2026-09-18, the tooling landscape shifts fast enough that any review process needs to be pinned to specific versions rather than "whatever the assistant suggests." That is the practical reason to lock dependencies and run the review against the lockfile, not against the model's memory of a library.
A review workflow you can actually run
Step 1 — Read the diff line by line, out loud if needed. Mandatory. Do not skim. For each new import, confirm the package exists and is the one you meant. For each API call, open the current docs for the pinned version and check the signature. This is where hallucinated libraries die.
Step 2 — Run the existing test suite before writing anything new. Mandatory. If AI code breaks tests you already trusted, that is your first signal. If there are no tests, that is the actual problem, and step 3 becomes the whole job.
Step 3 — Write a test for the boundary, not the happy path. Mandatory for anything touching money, auth, dates, or user input. Ask: what happens with an empty list, a null, a negative number, a leap day, a 10 MB string? AI code usually handles the example in the prompt and nothing else.
Step 4 — Run linters and type checkers. Mandatory. Tools like ESLint, Ruff, mypy, or TypeScript's compiler catch unused variables, unreachable branches, and type mismatches that are invisible in a quick read. Wire them into CI so the check runs on every push, not just when you remember.
Step 5 — Check security-sensitive lines by hand. Mandatory. Look for string-built SQL, unsanitised input passed to a shell, secrets hardcoded in config, and permissive CORS or file permissions. AI assistants are happy to write `subprocess.run(f"rm -rf {path}", shell=True)` if the prompt implies it.
Step 6 — Confirm provenance and licence. Mandatory if the code resembles a known snippet. AI output is not automatically yours; a copied GPL block in a commercial codebase is a legal problem, not a style one.
Step 7 — Add integration and end-to-end tests. Optional but strongly recommended once the unit layer is clean. These catch the wiring mistakes that unit tests miss.
A worked example
Say you ask an assistant to "add CSV export to the reports page." It returns a tidy function that imports `fastcsv-parser`, calls `parseStream(file, { delimiter: ',', skipHeader: true })`, and writes rows to disk. The code reads well.
Then you check: `fastcsv-parser` is not in your lockfile and does not exist on the registry — a hallucinated package. You swap it for `csv-parse`, which is already a dependency, and re-run. The test you wrote for "empty file" then fails, because the original function returned `undefined` instead of `[]`, and the caller assumed an array.
Two fixes, both caught by mechanical checks rather than by reading harder. That is the pattern: the model's fluency is not the problem; the absence of verification is.
Where this workflow does not save you
This process is slow. On a large diff it can take longer than writing the code yourself, and for throwaway scripts or internal one-offs, full review is overkill — a quick import check and a smoke test is proportionate. It also does not catch design-level mistakes: AI code can be perfectly correct line by line while solving the wrong problem, and no linter will tell you that.
Finally, it assumes you have tests and CI to begin with; if you do not, the honest answer is that AI code review is a downstream problem and test coverage is the upstream one. Build the safety net first, then let the assistant write into it.