How to review AI-generated code in risk order: seven passes

To review AI-generated code without reading every line first, review it in risk order. Read the requirement and the shape of the diff first, then the risky areas, the callers of changed interfaces, the tests and the side effects. The line-by-line read comes last, and it is slowest where a mistake costs the most.

A changed permission check deserves more of your time than a long new test fixture. An AI reviewer can take a fast first pass, but the risky parts still need your own read.

Claude Code is the worked example. The tool behaviour below comes from each tool’s official docs, last verified on 11 October 2026. None of it was tested for this post.

Part 4 of this series asked whether the change works and meets the requirement. This part asks a different question: is the change good, safe and maintainable, and where should your review time go?

The order: triage first, line by line last

A coding agent can write a change faster than anyone can read it, so the order you read it in matters. Each step in the order answers one question:

The first six steps tell you where to spend the seventh. Google’s code review guide gives reviewers the same advice: “Look at the most important part of the change first.”

Risk order changes what you read first, and how closely. The same guide’s what to look for page says “some code deserves more careful scrutiny than other code”. It also says “you should at least be sure that you understand what all the code is doing”. For a typo in the docs, the first six steps take seconds.

Seven review passes, from the requirement to the risky lines

1. Start from the requirement

The requirement is the first filter for AI-generated code. Read the task again before you open the diff, and note what a correct change would touch. Anything in the diff that the requirement doesn’t explain is the first thing to question. A refactor nobody asked for is one example, and a new package is another. Part 4 covers turning the requirement into acceptance criteria.

2. Read the shape of the diff before any line

The shape of a diff is its size and the files it touched. It is quick to read, and it decides the rest of the review. Two git commands show it (swap main for your base branch):

git diff --stat main...HEAD          # lines changed per file
git diff --name-status main...HEAD   # A added, M modified, D deleted, R renamed

Look for files the requirement doesn’t explain, deleted files marked D, and a change too big to hold in your head. For that last one, Google’s navigation guide says to ask the author “to split up the CL into multiple CLs”. A CL is Google’s word for a change. With AI-generated code, the author you ask is the agent.

3. Mark the risk areas

Risk areas are the parts of a system where a small mistake is expensive. Every file in the diff gets a tier. High risk if it touches any row below. Low risk if it is generated code, a lockfile, a file moved with no other change, or a docs fix. Medium for the rest.

Deleted code hides well in a diff, because there is nothing new to read. A removed validation line can look like a tidy-up.

4. Follow changed interfaces to their callers

A changed interface is risky because its callers often sit outside the diff. When a function signature, return type, default value, database column or API response changes, find every caller. An example, for a function called calculateTotal:

git grep -n "calculateTotal("

Then check that each caller still gets what it expects. A review of the diff alone shows the changed function and none of its callers. Part 8 covers mapping change impact before the agent writes code. In review, you check that map against what it actually changed.

5. Read the tests as code under review

Tests in an AI-generated change get the same review as the code. Do they test this change, or something near it? And was any existing test weakened to make the suite pass? Signs of a weakened test:

• a test deleted, or a new skip
• an assertion loosened, say from an exact value to “not null”
• a snapshot updated with no reason given
• a coverage threshold lowered
• a mock that replaces the very code the test claims to test

A test that mocks the function under test passes whatever that function does. Part 10 turns checks like these into gates that block a merge. Review is where you catch what a gate can’t see, like an assertion that quietly got vaguer.

6. Look for side effects outside the changed lines

Side effects are what a change does besides its stated job. Think of a new network call, a file write, a log line, an email or a scheduled job. They often live in a helper the change calls, outside the diff. Google’s guide on context says: “Sometimes you have to look at the whole file to be sure that the change actually makes sense.”

Ask what runs now that didn’t run before, and what happens if it fails halfway.

7. Read line by line where the risk is highest

The line-by-line read comes last, and its depth follows the tiers from step 3. High-risk files get a slow read of every line. Low-risk files get a scan, which Google’s guide allows for “data files, generated code, or large data structures”. Medium files get read for what they do and whether the next person can safely change them.

Maintainability belongs in this pass. GitHub’s tutorial on reviewing AI-generated code says: “Avoid accepting code that is hard to follow or would take longer to refactor than to rewrite.”

AI review in Claude Code, Codex, Copilot, Cursor, Gemini and Windsurf

Most coding agents now come with an AI reviewer for your diff or your pull requests. Use it as the first pass: it reads every line quickly, and you spend your own attention on the risk areas.

Each row comes from that tool’s official docs, last verified on 11 October 2026; none was tested for this post.

GitHub’s code review docs state the limit directly: “Always validate Copilot’s feedback carefully. Supplement Copilot’s feedback with a human review.” Making an AI finding block a merge is a gate, and gates are Part 10.

A quiet AI review is not a clean one

Several AI code reviewers filter what they report on purpose. Codex on GitHub reports only P0 and P1 issues, the high-priority ones. Gemini Code Assist posts nothing below Medium by default and skips .github/workflows. Claude Code’s Code Review leaves out missing test coverage unless your guidance files ask for it. Windsurf PR Reviews only takes pull requests of 50 files or fewer.

So a review with no comments means the reviewer found nothing it was set up to report. Callers outside the diff and weakened tests are still yours to check.

Tell the AI reviewer where your risk lives

Each AI reviewer takes written review rules, in a rules file or a settings page, so put your risk areas there. In Claude Code, the Code Review docs describe REVIEW.md at the repository root. An example, written for the risk areas above:

# Review instructions

## Always check
- Changes to authentication, authorisation or tenant scoping
- Database migrations: can they run twice, and can they roll back?
- Changed public functions, API responses or events, and their callers
- Tests that were deleted, skipped or loosened in this change

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files and lockfiles

The same docs warn that “a long REVIEW.md dilutes the rules that matter most”. The same short list fits in AGENTS.md for Codex, .cursor/BUGBOT.md for Bugbot, .gemini/styleguide.md for Gemini Code Assist and .github/copilot-instructions.md for Copilot.

An AI review pass is not a security audit

A security review command scans a diff for known kinds of vulnerability. Claude Code’s /security-review looks at your branch for “risks like injection, auth issues, and data exposure” (commands). Anthropic’s security review GitHub Action by default leaves out findings such as denial of service and rate limiting concerns. It treats them as low-impact or prone to false positives. Its README also says it “is not hardened against prompt injection attacks and should only be used to review trusted PRs”.

A change to authentication, payments or personal data still needs a person who knows the system’s threats. Google’s guide asks for a qualified reviewer “particularly for complex issues such as privacy, security, concurrency”. Text inside a pull request can also carry instructions aimed at the AI reviewer; Part 7 covers that kind of untrusted input.

Two prompts for a risk-first review

Neither prompt relies on a tool-specific feature. If you end up running them on every pull request, they belong in a skill; Part 5 has a starter code-review SKILL.md.

Prompt 1: map the risk before the review

An example prompt for when a change lands, before anyone reads a line.

Task: review <the branch, pull request or commit> against this
requirement: <paste the requirement>

Do not review line by line yet. First build a risk map of the change.

1. Summarise what the requirement asks for.
2. List every changed file with lines added and removed.
3. Flag any change the requirement does not explain.
4. Mark each file high, medium or low risk. High risk means it touches
   authentication, authorisation, data access, money, migrations,
   concurrency, public interfaces, configuration or deleted code.
5. List every changed signature, schema, default or API response,
   and find its callers outside the diff.
6. List test files that were added, changed, deleted or skipped.
7. List side effects: new network calls, file writes, logs, jobs,
   caches or retries.

Cite the file and line for each item.
Read only what the risk map needs.
Do not edit files. Never print, expose or commit secret values.
Do not commit, push, deploy, run destructive commands or make external
changes unless I explicitly authorise it.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.

End with the files to review first, in order, and why.

The ordered file list at the end is your reading plan for steps 4 to 7.

Prompt 2: review the high-risk files

An example prompt for the files Prompt 1 marked high risk. Run it in a fresh session or a sub-agent if your tool has them, so the reviewer never sees the reasoning that wrote the code.

Task: review these high-risk files from <the change>: <list the files>
Requirement: <paste the requirement>

Review each file slowly, line by line. Check:
- Is the behaviour correct for the requirement, including failure paths?
- Can a user reach data or actions they should not?
- Do callers of every changed interface still get what they expect?
- Do the tests exercise this code, or a mock of it?
- Was any test, assertion or check weakened?
- What side effects run now, and what happens if one fails halfway?
- Can the next developer understand and safely change this code?

Report each finding with severity (critical, high, medium, low),
file and line, the evidence, and a suggested fix.
Mark anything you could not confirm as unverified, not as a finding.

Do not edit files. Never print, expose or commit secret values.
Do not commit, push, deploy, run destructive commands or make external
changes unless I explicitly authorise it.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.

Read its findings against the code yourself before acting on them.

A risk-first review checklist for AI-generated code

The checklist follows the same order as the seven passes, ready to copy:

RISK-FIRST REVIEW: AI-GENERATED CODE

□ Requirement re-read before the diff
□ Every change explained by the requirement
□ Diff size and file list checked
□ Deleted files and deleted lines checked
□ Each file marked high, medium or low risk
□ Auth, data, money, migrations, concurrency checked
□ Public interfaces, config and defaults checked
□ Callers of changed interfaces checked
□ Tests cover the change, not a mock of it
□ No test deleted, skipped or loosened
□ Side effects, and failure halfway, considered
□ High-risk files read line by line
□ AI review run, and what it filters out known
□ Security-sensitive change seen by a qualified person

New dependencies are a risk area of their own, and the next part of this series is about them.

Quick answers

How do you review AI-generated code?

Reviewing AI-generated code works best in risk order. Re-read the requirement, check the diff’s size and file list, and mark the risky areas. Then follow changed interfaces to their callers, read the tests and side effects, and read the high-risk files line by line.

Do you have to read every line of AI-generated code?

Every line of AI-generated code needs a reviewer who understands it, and the depth of the read follows the risk. A scan is enough for generated files and lockfiles, while authorisation checks, migrations and payment code need a slow read of every line.

Can an AI code review replace a human reviewer?

An AI code review cannot replace a human reviewer. GitHub tells users to supplement Copilot code review with a human review. Reviewers such as Codex on GitHub and Gemini Code Assist also filter out lower-priority findings by design.

What should you check first in an AI-generated pull request?

The first check on an AI-generated pull request is the requirement. Next comes the shape of the diff: how many files changed, which ones, and whether any were deleted. Changes the requirement doesn’t explain are the first findings.

Is an AI security review the same as a security audit?

An AI security review, such as Claude Code’s /security-review, scans a diff for common vulnerability types, and falls short of a security audit. Changes to authentication, payments or personal data still need a reviewer who knows the system’s threats.

More on AI coding is in the AI category.