How to Review a 2,000-Line AI Pull Request

Quick answer
Start with scope: what the change claims to do, which files it touches, and what it should not have touched.
Review risky surfaces before syntax: authentication, authorization, data writes, migrations, money, and anything that runs on a schedule.
Read the tests next, because they tell you what the agent believed the requirement was.
Then read the diff by concern, not by file order, using the commit history or a diff tool that groups changes.
Approve only when you can state the behaviour change in one sentence and name the test that proves it.

Where do you start with a large generated change?

With the boundary. List the files changed and compare that list with the task. The most common failure in a large agent change is scope creep: an unrelated refactor, a formatting sweep, a dependency bump nobody asked for. Those are cheap to identify and expensive to miss.

Then read the author’s summary critically, knowing it may be agent-written. Treat it as a claim to verify, not an explanation to trust.

# What did the branch actually touch?
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
# Where is the risk concentrated?
git diff origin/main...HEAD -- '*auth*' '*migrat*' '*payment*' '*.sql' | head -200

Which parts should you read first?

Anything that decides who can do what, anything that writes or deletes data, anything that moves money, and anything that will run without a human present. These are the surfaces where a fluent, plausible mistake becomes an incident.

Configuration changes deserve their own pass. A changed timeout, a retry count, or a resource limit looks harmless in a diff and changes behaviour under load. The same applies to dependency updates, which change code you did not read.

How do you use the tests as evidence?

Read the new tests before the implementation. Well-written tests state the requirement in executable form, and comparing them with your understanding is faster than reverse-engineering intent from the diff. If the tests assert something different from the task, the change is wrong regardless of how clean the code is.

Check what the tests do not cover. Agents write tests for the path they implemented, which is the happy path they imagined. Missing cases are usually failure handling, authorization, and concurrency.

How do you finish a review without skimming?

State the change in one sentence, then name the test that proves it. If you cannot, you have not reviewed it. Timebox the passes rather than the whole review, and stop when the timebox ends without a clear sentence — that is a signal to split the change, not to read faster.

Record what you checked. A short review note — scope, risky surfaces, tests, open questions — turns a one-off read into something the next reviewer can build on, and it makes skimming visible to you.

Where this bites vibecoders
The instinct is to scroll the diff and look for something obviously broken. Fluent generated code rarely has anything obviously broken; it has a missing check on line 800. Read the risky files, not the whole diff, and read the tests first.

Where AI coding assistants get this wrong

Trusting a generated pull request summary as an accurate description.
Reading the diff in file order until attention runs out.
Skipping the migration or configuration files because they are small.
Assuming the tests cover the requirement rather than the implementation.
Approving a change that also contains unrelated refactors.
Letting the agent resolve review comments without checking the resolution.

Checklist

Compare the changed file list with the task.
Read authorization, data, and money paths first.
Review configuration and dependency changes explicitly.
Read the new tests before the implementation.
State the behaviour change in one sentence.
Name the test that proves it, or request one.

FAQ

Should I ask the agent to explain its own change?

Yes, as a starting point, because it can point you at the files it thinks matter. Then verify. A model explaining generated code can rationalise a mistake as easily as it made one, so treat the explanation as a map, not as evidence.

Is it acceptable to review only the risky parts?

For a large change, a risk-focused pass beats a uniform skim. Be explicit about what you did not read, and require tests for the rest. Silent partial review is the dangerous version; declared partial review is a reasonable trade-off.

What if the change is too large to review at all?

Split it. Ask the author to separate the refactor from the behaviour change, or to land the mechanical part first. Reviewing an unreadable change is worse than delaying it, because approval transfers responsibility without transferring understanding.

How do I review generated migrations?

Check the lock behaviour on the largest table, whether the migration is reversible, and whether it runs in a transaction. Generated migrations often look correct and lock a production table for minutes. Test on a copy with realistic row counts.