AI-written pull requests arrive looking finished: tidy names, confident comments, green tests. That is exactly what makes them hard to review. Fluent code invites you to read along and nod, and a review that starts by admiring the code ends up checking it against itself.
Start from the request
Before you open the diff, write down what was asked, in one or two sentences. Then write two or three tests of your own: the main case, one edge the request mentions, and one piece of bad input. Run them on the unchanged code and watch them fail.
This takes ten minutes and changes the whole review. You are no longer asking whether the code looks right. You are asking whether it does what was asked, and you have your own evidence either way.
Map it, then read what it removed
List every file the change touches with git diff --stat, and run git status too, because new files do not appear in git diff. Which files did you expect? Which are a surprise?
Then read the removed lines first. New code is what you asked for. Removed code is what you did not ask to lose. Assistants love an unrequested tidy-up: a helper rewritten "for consistency", a check loosened so the new feature fits. Each one is a second change with no request and no review.
A changed test is a changed requirement
If the change edits or deletes an existing assertion, stop. That test was someone's description of how the system should behave. Find the decision that allows the change, or reject it. Tests written in the same prompt as the code tend to agree with the code, including where both are wrong.
Where AI code goes wrong
Look harder in the places generated code is weakest:
- Packages and APIs. Check that every new dependency exists and is the one you think, and that unfamiliar methods exist in the version you run.
- Edges. Empty, zero, one, the limits, and bad input.
- Failure paths. Missing config, timeouts, empty responses. Generated code tends to cover the path where everything works.
- Security. Input validation, access checks, queries built from strings, secrets in logs.
- Fit. A second way of doing something the codebase already does.
A line you cannot explain is a line you are trusting, not checking.
Match the effort to the risk
Not every change needs the full treatment. A label or a log line needs the suite, the diff and one edge case. A change to an existing feature needs the whole review, with your own tests first. Anything that writes data, checks input, controls access or touches shared code needs all of that, plus a run against realistic data and a second reviewer. Size is no guide: three lines of validation deserve more care than a hundred lines of new, isolated code.
Finish by recording a verdict, accept, fix or reject, with the evidence: a command and its output, or a line and the requirement it breaks.
All of this fits on one page. The free AI code review checklist has twenty steps and a risk table you can print or paste into your pull request template.