How to review AI-generated PRs

A background coding agent on your team changes the shape of code review. The PRs come more often and the author never joined standup. The mistakes look different too. Reviewing AI-generated PRs is its own skill, and almost everything written about agents skips the person doing it: the human with the merge button. Review habits tuned to human authors miss what matters and spend attention where it isn't needed. Here's the guide we wanted to exist: what to check, in what order, and what to do when the answer is no.

Why reviewing AI-generated PRs is different

A teammate's PR arrives wrapped in context. You heard the design argument, you know what they're working toward, and half the review already happened in conversations the PR never records. An agent's PR arrives with none of that. The ticket and the diff are the entire record, so the review carries the weight those conversations used to.

The volume is higher, too. An agent that clears a few tickets a day produces more PRs than any single teammate, so a review process that costs thirty minutes of archaeology per PR will not survive contact with it.

And the failure modes are inverted. Humans typo and cut corners late in the day. Agents almost never typo: the syntax is clean and the tests pass. The characteristic agent failure is misread intent. The code does something reasonable, correctly, and it's not quite the thing the ticket needed. Reviewing for human mistakes means scanning for sloppiness; reviewing agent PRs means checking aim.

The checklist, in priority order

1. Does the diff match the ticket's intent

Not the ticket's words, its intent. A ticket that says "exports are missing rows for users in non-UTC timezones" can be satisfied literally by special-casing the export endpoint, when what the reporter needed was the shared date logic fixed. Read the ticket before the diff, decide what the reporter actually needed, then check whether this diff is that. These are the highest-value minutes of the review, and this is the one check no tool can run for you.

2. Are the tests real

Agent PRs usually come with tests. The question is whether they're assertions or theater. Theater looks like tests that mock out the behavior under test, or assertions that restate the implementation. Pick the case the ticket named, confirm one test encodes it, and ask whether that test would have failed before the change. If you can't tell, ask in a comment.

3. What's the blast radius

Agents are good at making the named case pass and less reliable at knowing what else leans on the code they touched. If the diff modifies a shared helper, grep for its callers. If it changes a query, think about who else reads that table. You hold knowledge the agent may not have surfaced: which paths are hot, and which "unused" function the cron job still calls.

4. Does it reuse the codebase's idioms

The most common correctable flaw in agent PRs is reinvention: a new date-formatting function beside the existing one, a hand-rolled retry where the codebase has a helper. It works, it tests green, and it rots the codebase one duplicate at a time. This is also the easiest comment to write, because the fix is a pointer: "use formatUserDate from lib/dates.ts."

5. Skip what CI already catches

Formatting, lint, type errors, whether it builds. If your CI checks it, don't spend human attention on it. Your attention is the scarce input in this whole loop; the checklist is ordered so you spend it where no machine can.

When it's wrong, comment like you would to a teammate

State the correction plainly, on the line it applies to: "use the existing helper instead of adding one," or "revert the changes to the on-screen query, only the export was wrong." With Sinatra, the agent picks the comment up and pushes a revision to the same branch, so the loop is the one you already know from human review: you comment, it revises, you re-review. Precise comments get precise revisions; a vague "this doesn't look right" gets you a guess.

Self-review comes before your review

Sinatra reviews its own PR before requesting yours and pushes fixes for what it finds. In practice that clears out the mechanical problems (dead code, a missed obvious edge case, a test that asserts nothing, stray debug output) before a human ever looks. Your review still happens; what changes is its altitude. Less proofreading, more judging whether the change is the right change.

Two anti-patterns

Rubber-stamping. "Tests pass, the diff looks plausible, approve." The tests were written by the same author as the bug, and plausibility is exactly what modern models are best at producing. The PR is the gate: nothing reaches your main branch until a person merges it, and that only means something if the person actually reviews. If a PR is too large to review honestly, that is itself a review comment: ask for it to be split.

Rewriting locally. The diff is 80% right, so you check out the branch and quietly fix the rest yourself. It feels faster and it costs you twice: the correction never enters the record, so the agent gets no signal and next week's PR has the same flaw, and your own fix ships unreviewed. Leave the comment, let the revision come back, and reserve taking over for when a round or two of comments has failed.

Common questions

Should AI-generated PRs meet a different bar than human ones?

The same bar, applied without social pressure. You can hold the line on tests and naming without worrying about anyone's feelings, so in practice reviews of agent PRs can afford to be blunter and slightly stricter than reviews of a colleague's work.

How many revision rounds before I take over?

Two is a reasonable default. If a second precise comment doesn't land, the underlying spec was probably unclear, and the fix is a better ticket rather than a third comment. Taking over the branch after that is a choice, not a failure; the mistake is doing it silently on round one.

Does reviewing agent PRs get faster with practice?

Yes, mostly because the failure modes are consistent. After a few dozen PRs you'll check intent, tests, blast radius, and idioms in a fixed order and spend single-digit minutes on small diffs. Well-scoped tickets speed this up more than anything else, because a tight spec gives you a checklist to review against; we wrote up how to produce one in how to write tickets for AI agents.

The fastest way to build the habit is to review a few real ones. Assign an agent a small ticket and put the checklist to work on the PR that comes back: you can start for free, or read the docs to set up your repo.