Review AI-written code like a senior engineer.

The fastest safe way to review AI-written code is to review by risk, not by line. Confirm the change does what you asked, run it, read the dangerous parts closely, and let automated tools read the rest. Reading every line of a 900-line diff with equal care is how reviewers get tired and miss the one line that matters.

This guide gives you a repeatable method, the failure patterns AI code shows most, and a checklist you can use today.

01Why AI code needs a different kind of review

Human code review grew up around people who write a little code slowly. Coding agents turn that around. They produce a lot of code quickly, and it almost always looks tidy, which makes it easy to trust.

The data says that trust should be earned. Veracode tested code from more than 150 language models and found that tidy is not the same as safe:

Code that compiles and reads well can still be wrong in ways a quick skim will not catch. The answer is not to read slower. It is to read smarter.

02Step one: review the intent before the diff

Before you open a single file, ask the agent for a short summary. You want to know what it changed, why, and what it chose not to do. Then compare that summary with your original request.

Before I review, summarize this change for me:
1. What problem it solves, in one sentence.
2. Every file you changed and why, one line each.
3. Anything you changed that I did not ask for.
4. Assumptions you made, and what would break if they are wrong.
5. How you tested it, and what you did not test.

Point three is the one to read twice. Agents like to be helpful, and “helpful” sometimes means renaming a function you depend on or rewriting a file you did not mention. Unrequested changes are where surprises hide.

03Step two: run it before you read it

Reading code to find out whether it works is slow. Running it is fast. Do the cheap checks first:

1. 01

   Run the test suite

   All tests should pass. If the agent added tests, run them against the old code too. A test that passes either way proves nothing.

2. 02

   Use the feature like a user would

   Click through the main path once. Then try one unhappy path: an empty form, a wrong password, a slow network. Agents often build the happy path well and skip the rest.

3. 03

   Look at what changed on disk

   Check for new files you did not expect, such as lockfile churn, generated files, a stray .env or debug logs.

If any of these fail, stop and send it back. There is no point reviewing logic that does not run.

04Step three: triage the diff by risk

Not every line deserves the same attention. Sort the changed files into three buckets before you read closely.

This is how senior engineers review large changes. The goal is to put your full attention where a mistake would hurt a user or leak data.

05The AI failure patterns to hunt for

Coding agents make a recognizable set of mistakes. Knowing them turns review into a search rather than a slog.

• Invented APIs. A function, option or package that sounds right but does not exist, or does not exist in your version.

• Weakened tests. An assertion removed, a test skipped, or an expected value changed to match the new output.

• Swallowed errors. A broad try and catch that logs nothing and returns a default, so failures become silent.

• New dependencies. A package added for something a few lines of code would do. Check that it is real and maintained, because attackers register names that AI tends to invent.

• Duplicated helpers. A fresh utility that already exists elsewhere in your codebase under another name.

• Hardcoded values. Keys, URLs, IDs or limits pasted inline instead of read from configuration.

• Quiet scope creep. Formatting changes across whole files, which hide the real change inside noise.

06Let tools do the boring reading

Humans are bad at spotting a missing null check on line 640. Tools are great at it. Before you review, make sure these ran and came back clean:

# Types and lint (JavaScript or TypeScript projects)
npx tsc --noEmit
npx eslint .

# Known vulnerabilities in dependencies
npm audit --omit=dev

# A quick look for secrets (a real scanner such as gitleaks catches more)
git diff --cached | grep -nE "(api[_-]?key|secret|token)\s*[:=]"

Your project may use different commands, and that is fine. The principle is the same in every language: types, lint, tests, dependency audit and secret scanning run first, automatically, ideally in CI. Your human review then starts from a clean baseline. Dedicated AI code review tools now bundle many of these checks into one pass, if you would rather not wire them up yourself.

07Ask a second model to be the skeptic

A useful trick is to ask a different model, or a fresh session, to review the diff with an adversarial brief. It does not replace your review, but it often finds the thing you were too close to see.

You are a skeptical senior engineer reviewing this diff before it ships to production.
List only real problems, most severe first. For each one give the file and line, what goes wrong, and a concrete input that triggers it.
Focus on: security, data loss, error handling, edge cases, concurrency, and tests that no longer test anything.
Do not comment on style. If you find nothing serious, say so.

Treat its findings as leads, not verdicts. Confirm each one yourself before you act on it.

08A review checklist you can reuse

09FAQ

Want to go deeper? Read our checklist for securing AI-generated code, learn how tests keep an agent honest, or set up a pair programming workflow that ships.