Reviewing AI-generated pull requests: the complete guide

Review an agent's pull request in this order: the shape of the change, the CI and workflow files, the code it rebuilt that already existed, one path traced end to end, the security boundaries, then the tests. Read individual lines last, and only the ones those steps point you at. The order matters because the expensive part of review moved. LinearB's 2026 Software Engineering Benchmarks, built from 8.1 million pull requests across more than 4,800 organisations, found AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up: over 16 hours, against roughly 200 minutes for everything else. Once somebody starts, the review finishes quicker than a human-written one. The delay sits in front of the work.

Why an agent's pull request is harder to read

A human writes a pull request as an argument. The commits are in order, the first file is the one you should look at first, and the description says what the author was worried about. An agent produces the same amount of code with none of that scaffolding. Salesforce Engineering, writing about their own surge in AI-generated code, described agent pull requests as spanning backend, config, tests and UI without preserving narrative structure. Everything the change needed is there. The reading order is gone.

Size compounds it. In LinearB's data, AI-assisted pull requests run 408 lines at the 75th percentile against 157 for unassisted ones. So the reviewer opens a change two and a half times bigger, arriving with no story, in a part of the codebase they may not have touched since the last agent went through it. I wrote more about that reading order problem in agent pull requests lose the narrative, and about the queueing effect in why AI-generated pull requests wait 4.6 times longer for review.

The thing the reviewer is actually short of is a current picture of the system. That used to decay slowly. Now it decays weekly, which is the argument in your mental model of the codebase is one week old and the reason cognitive load in code review is the right frame for all of this.

Read the shape before you open a file

Get the change into one picture before you get it into your editor. What did it touch, in which parts of the system, and what did it delete. GitHub's own review guidance for agent pull requests puts this first and gives it one to two minutes: scan the file list and the size, and decide what kind of change this is.

Two things are worth knowing in those two minutes: which subsystems the change reaches, and whether it has one centre or several. A pull request with three centres is really three pull requests, and reviewing it as one is where an afternoon goes. Deletions get a third look, since a removal is the edit most likely to be a mistake nobody notices.

Read the shape first, and the lines you still have to read pick themselves. In the render above, the amber queue route and the red struck-through worker are the two places where behaviour actually changed hands. The green batch path is new code with no existing callers, which is the safest kind. That ordering comes off the picture at a glance; recovering it by scrolling a diff takes considerably longer.

If the change is large enough that this step feels hopeless, the time-boxed version is in how to review a 400-line pull request in ten minutes. If it is in code you do not know well, how to review a pull request you didn't write is the one to read: the useful property there is that the parts the change did not touch stay on the page.

Check the CI and workflow changes first

An agent that edited .github/workflows, a test config, a lint config or a coverage threshold has changed the thing that is supposed to be checking it. GitHub calls this CI gaming and lists it as the first of five red flags in agent pull requests, and it is the one that quietly invalidates the rest of your review. A skipped test, a lowered threshold or a relaxed matcher makes every green check downstream meaningless.

Give it two or three minutes and ask one question of each edit: does this make a failure less likely to be reported. A workflow that now runs on pull_request_target, or that interpolates a branch name into a shell command, needs a security review of its own. The other four flags are worth knowing on sight, and I mapped each one to what it looks like drawn in five red flags in agent pull requests.

Look for what it rebuilt instead of reused

Agents write plausible code faster than they find existing code. GitHub cites a January 2026 study, "More Code, Less Reuse", which found that agent-written changes carry more redundancy and more technical debt per change, and that reviewers feel better about approving them anyway.

Spend three to five minutes searching for the utilities the pull request introduces. Take the name of each new helper, search the repository for the nearest existing thing, and see whether you already had one. A second date formatter, a second retry wrapper, a second HTTP client with its own timeout policy: each is cheap to accept and expensive to live with. Drawn, this looks like a new green node sitting next to an existing node that does the same job, which is a shape you notice instantly and a duplication you can miss for months in a diff.

Trace one path end to end

Pick the path that matters most in this change and follow it from entry point to storage. Request comes in, gets validated where, hits which service, writes what, returns what. GitHub allows five to eight minutes for this, and it is the step that finds the real bugs, because a change can be locally correct in every file and still be wrong in sequence.

A data-flow view answers this directly: the ordered pipeline of the change, one step at a time, in the order the steps happen. Architecture tells you what a change touches; data flow tells you in what order. Architecture, sequence or data-flow is the longer comparison.

Check the boundaries

Authentication, authorisation, input validation, secrets, anything that talks to a paid or destructive external API. Nine or ten minutes into the review, this is what is left, and it deserves the attention because the failure mode of agent code is specifically here. The 2026 paper "Is Vibe Coding Safe?" evaluated SWE-Agent running Claude 4 Sonnet and found 61% of its solutions functionally correct and 10.5% secure.

Ask whether the change moved a boundary: a route that used to require a session, a query that used to be parameterised, an external call that now has no timeout. Boundaries are the easiest thing to see drawn, because an external system is its own lane and a new arrow crossing into it is visible from across the room. Vibe coding review goes deeper on code nobody read while it was being written.

Make the tests prove something

Read the tests as evidence, not as a checkbox. GitHub calls the failure here hallucinated correctness: tests that assert the implementation rather than the requirement, mocks that make the interesting case impossible to fail, and confident prose in the description about behaviour nothing exercises.

The question to ask each new test is what would have to break for this to go red. If the answer is "the function would have to stop existing", it is not a test. If the pull request changed a behaviour, find the test that would have failed before the change. Its absence is worth a comment. There is a copy-pasteable version of all of this in a code review checklist for agent-authored code.

Does anyone actually review these?

Often not. The 2026 paper "These Aren't the Reviews You're Looking For" examined 33,596 agent-authored pull requests and found 61.38% received no recorded human review at all. Of the review comments that did exist on agent pull requests, 71.58% were written by agents, and 25.92% of reviews contained agent-steering commands rather than review feedback, against 1.63% for human-authored pull requests.

A large share of merged agent code reached production without a person forming an opinion about it. I walk through the paper in six in ten agent pull requests are never reviewed by a human. The arithmetic behind it, one reviewer against a team of agents, is in ten times the pull requests, one reviewer.

Does it matter which agent wrote it?

Somewhat. The method above holds for all of them, and what changes is the context you have around the change. A pull request from a session you were sitting in is a different object from one an autonomous agent opened at 3am while you were asleep.

I wrote a version of the routine for each of the common ones: Claude Code, Cursor background agents, OpenAI Codex, the GitHub Copilot coding agent, and autonomous agents like Devin, Jules and OpenHands, where there is no session to ask and no author to tag.

Handing the change to somebody else

Review is rarely one person. You approve, then somebody on-call has to understand the thing at 2am, and somebody in another timezone has to know it landed. Pasting a diff link does none of that work.

What travels well is a picture with a route through it. How to explain a pull request without walking through the diff covers the async version, and we drew ten landmark pull requests shows what changes of each size look like once they are drawn, from an eight-file Kubernetes Ingress PR up to a hundred-file scheduler rewrite.

A generated prose summary does not travel either. It reads well and leaves you where you started, because it describes the code in a second language you still have to map back onto the first. AI pull request summaries vs diagrams runs one pull request through both.

Where a tool fits

Last, deliberately. The method above works with nothing installed; it is just slower, because you build the picture yourself out of the file list.

We built PR Lens to do the first step for you. It draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request itself, updated in place on every push. Green is new, amber is changed, red is gone, and removed components stay on the page with a line through them. The parts the change did not touch stay drawn, which is what makes the picture a map rather than a patch. It is MIT licensed, free for open source, and runs four ways: the GitHub App, a GitHub Action with your own model key, the CLI, or an agent skill your coding agent runs with the model it already has.

It finds no bugs. That is on purpose. Copilot code review has processed over 60 million reviews and more than one in five code reviews on GitHub now involve an agent, so defect-hunting is well covered. What no bot does is hand you back the shape of your own system after an agent has finished rearranging it.