AI-generated pull requests are getting better at looking finished. That is exactly why I review them with a small, repeatable bar instead of trusting a green check, a long summary, or my first impression.
Here is the tight version of my 10-minute review. It is designed for the moment when an agent has opened a PR and you need to decide whether it deserves attention, revision, or a merge.
Read the issue, acceptance criteria, and the PR title. Then write one sentence in your own words: “This change should do X, for Y, without breaking Z.”
If you cannot write that sentence, do not start reviewing the diff yet. Ask for clarification or inspect the surrounding code until the boundary is clear. A fuzzy request makes every later judgment fuzzy too. Look at the file list and the diff size before reading individual lines.
“While I was here” is not automatically a bonus. Split unrelated work into a separate PR, or send the change back with a narrower boundary.
Follow the main path from input to output. Read the changed code as if you were the caller, not as if you were grading the agent’s explanation.
Check the happy path, then ask:
I also compare the implementation with local conventions. An elegant pattern in the abstract can still be the wrong pattern for this repository. Consistency is a maintenance feature.
Do not treat the presence of tests as proof of coverage. Read what the assertions actually distinguish.
A useful test should fail when the important behavior regresses. Look for the boundary cases you named in minute one, plus at least one negative path. If the test only checks that a function returns something, or snapshots a large object without meaningful assertions, it may be test-shaped documentation rather than protection.
I call it summary theater when the description is polished, specific-sounding, and only loosely connected to what changed. “Improved reliability” is not evidence. “Added validation” is not evidence until you can point to the validation and its tests. A summary is useful as an index; it is never a substitute for verification.
A short review is not a shallow review. It is a time-boxed way to spend attention on the highest-risk claims first. If the change cannot clear this bar in ten minutes, that is useful information: the PR needs a better boundary or a deeper review, not a faster “LGTM.”
I wrote the longer version of this approach here: I stopped rubber-stamping AI PRs — here’s the 10-minute review bar I use.
If you want a ready-to-use starting point, my AI Agent Code Review Kit packages the checklist, Cursor rules, and prompts. For a second set of eyes on one difficult change, the Agent PR Audit is available too. — Riven Desk
Run the smallest relevant test command yourself, then inspect the diff for untested branches. Weak tests are a common failure mode because they let an agent demonstrate motion without demonstrating correctness.
Now read the PR summary and let it explain rather than persuade. Compare each claim with the diff and test output.
This is where I catch scope creep. An agent may solve the stated problem and quietly redesign three neighboring systems.