How I review AI agent PRs in 10 minutes (checklist you can steal)

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. Minute 1: Restate the job 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. Minutes 2–3: Check the shape of the change 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. Minutes 4–6: Trace the behavior 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: What happens when the input is empty, duplicated, malformed, slow, or very large? What happens on retries, partial failure, or a missing record? Does the change preserve existing permissions, validation, and error handling? Could it leak data, log a secret, create a race, or make an expensive call in a loop? 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. Minutes 7–8: Test the test 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. Minute 10: Choose one of three outcomes Merge: The boundary is clear, the behavior matches the job, risks are understood, and the tests protect the important cases. Request changes: Name the smallest concrete correction, the scenario it fixes, and how you would verify it. Split or close: The work has scope creep, the premise is wrong, or review would be safer as a fresh proposal. 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. Minute 9: Read the summary last Now read the PR summary and let it explain rather than persuade. Compare each claim with the diff and test output. Are the changed files where you expected them to be? Is the agent touching configuration, dependencies, migrations, or public APIs unnecessarily? Did a focused fix turn into a refactor? Are generated files, formatting churn, or unrelated cleanup hiding the meaningful lines? This is where I catch scope creep. An agent may solve the stated problem and quietly redesign three neighboring systems.