How to Review an AI-Generated Pull Request

Reviewing an AI-generated pull request is not the same job as reviewing a human's, and treating it the same is how bad code ships. A human writes code that reflects their understanding, so their mistakes cluster around the parts they did not understand. An agent writes code that reflects the most likely pattern, so its mistakes cluster around the parts that look right but are not. You review for different failure modes. If your checklist has not changed, your review is missing things.

The core shift: with a human, you assume competence and check for slips. With an agent, you assume plausible-looking output and check for whether it is actually correct. That sounds harsher on the machine. It is realistic. The agent has no stake in whether this works in production. You do.

Start with whether it did the right thing at all

Before you read a single line for quality, check that the PR solves the stated problem. Agents are excellent at confidently solving the wrong problem, or a narrower version of the right one. Pull up the acceptance criteria and verify each one against the diff. No criteria? Then you are reviewing against a guess, which is why I write acceptance criteria before the prompt so review has something to check against.

Watch specifically for the criteria that got skipped. An agent under-delivers on the boring parts: the error path, the empty case, the cleanup. It will nail the happy path and quietly omit the timeout handling. Your first pass is a completeness pass, not a style pass. Did it do everything, or just the visible part.

Read the tests before the code

Agents write tests that pass. That is not the same as tests that matter. The failure pattern is a test suite that exercises the happy path, asserts loosely, and never touches the edge cases that break in production. A green suite from an agent tells you the code runs, not that it is correct.

So read the tests first and read them adversarially. Do the assertions actually pin the behavior, or would they pass against a broken implementation? Are the hard cases tested, or just the easy ones? If the tests are thin, the code is unverified no matter how clean it looks. This is the heart of a real test strategy for AI-generated code, and it is where the sharpest reviewers spend their time.

Hunt for the specific things agents get wrong

There is a recurring set. Invented APIs and methods that do not exist but look like they should. Error handling that swallows exceptions to make things "work." Security shortcuts, like logging a token or skipping a validation, taken to satisfy the happy path. Subtle off-by-one and boundary errors dressed in confident code. And silent scope creep, where the agent "improved" a file you never asked it to touch.

Scan for those on purpose. They are not random; they follow from how the model optimizes for plausible output. Keeping this code maintainable over time is a separate battle I cover in keep AI-generated code maintainable, but the review is where you stop the worst of it from entering the tree at all.

Do not let volume lower your standards

The real danger with AI PRs is throughput. The agent produces diffs faster than you can carefully read them, and the temptation is to skim and approve because the code looks fine and you have twelve more waiting. That is exactly how quality erodes: not through one bad review, but through a hundred shallow ones.

Hold the line. If a diff is too large to review properly, send it back to be split, do not approve it out of fatigue. A PR you cannot fully review is a PR you cannot approve, full stop. This is the same reason demo-to-shippable is the real gap: the last mile is verification, and volume makes verification harder, not easier.

The good news is that a build platform can do the first pass for you: run the criteria, run the tests, flag the known failure patterns, and hand you a PR that is already pre-screened. That is how we structure review at Bootspring, so a human spends attention on judgment calls instead of catching invented APIs by hand. Review the machine's work like the machine wrote it, because it did, and keep your standards exactly where they were before the volume showed up.