Playbooks
How to review a 400-line pull request in ten minutes
Four passes on a clock: the shape of the change, its edges, one traced path, then evidence. A method for reviewing large agent-written pull requests without reading every line.
Four passes, none of them a read of the diff from top to bottom. Two minutes on the shape of the change, two on its edges, four tracing one path from entry point to storage, two asking what proves it works. The 400 lines are not hypothetical. LinearB's 2026 benchmarks, built from 8.1 million pull requests across more than 4,800 organisations, put AI-assisted pull requests at 408 changed lines at the 75th percentile, against 157 for pull requests written without assistance.
The advice you usually get is to send it back and ask for something smaller. That works on a colleague who still has the change in their head. It works badly on agent output, where the branch is already pushed, CI is already green, and the session that wrote it has ended. So this is a method for the pull request that actually arrived.
Why ten minutes is the right budget
The same LinearB benchmarks found AI-generated pull requests wait 4.6 times longer than human ones for a reviewer to pick them up: over 16 hours, against roughly 200 minutes. Agentic pull requests waited 5.3 times longer at the 75th percentile. Once someone starts, AI pull requests finish faster than human ones, about 194 minutes against 252.
Read those two numbers together and the expensive part is getting started. A 400-line diff across a dozen files reads as an open commitment of unknown size, so it waits for a block of time that never arrives. Faros AI reports the other half of the same story: under high AI adoption, the share of pull requests merged with no review at all rose 31.3%.
Ten minutes is a commitment you can make between two meetings. Ten minutes with a method also beats an hour without one, because an hour spent reading a diff in file order mostly buys you the memory of having read it.
Ten minutes is enough to understand a change and not enough to read it. Those are two different jobs. Reading is what you do to the three files that matter, after you know which three they are.
The ten minutes
| Minutes | What you do | What you are deciding |
|---|---|---|
| 0 to 2 | Look at the shape of the change | Whether it touches what its title says it touches |
| 2 to 4 | Read CI, config and deletions | Whether the safety net still holds |
| 4 to 8 | Trace one path end to end | Whether the new path is correct |
| 8 to 10 | Ask for evidence | Whether anyone has run it |
GitHub published a similar clock in its guidance on reviewing agent pull requests: file list and size in the first minute or two, CI changes next, then a search for duplicate utilities, one critical path traced between minutes five and eight, security boundaries, and test evidence by minute ten. I have reordered the middle and given the first step a picture, for the reason in the next section.
Minutes 0 to 2: get the shape of the change
Open the file list and answer one question out loud: what does this change do to the system?
If you cannot answer in a sentence, that is the file list failing, not you. Twelve filenames in a sidebar tell you where a change lives. They do not tell you what it does. This is the two minutes a drawn pull request collapses into a glance: the components the change touches, drawn against the system around them, with new parts in green, changed parts in amber, and removed parts in red and struck through.
What you are checking is narrow. Does the shape match the title? A pull request called "add rate limiting to the upload route" that draws three new services in the data lane is not necessarily wrong, but its title is, and every assumption you make for the next eight minutes comes from that title. A mismatch caught in minute one is worth more than any comment you write in minute nine.
Minutes 2 to 4: read the edges before the middle
Three kinds of file sit at the edge of a change and get read last, which is backwards.
CI and workflow files come first. GitHub names CI gaming as one of five red flags in agent pull requests: a failing test now skipped, a coverage threshold lowered, a job quietly moved to a trigger that rarely fires. Read every diff under .github/ in full. It is usually twenty lines and it is the only part of the pull request that can make the rest of it lie to you.
Configuration and permissions come next. A new environment variable, a widened CORS list, a token scope that grew, a queue that now retries forever. These lines are short, boring, and where the incident comes from.
Deletions come third. Removed code is the easiest thing to skim past in a diff and the most expensive thing to be wrong about. In a drawn change, what was removed stays on the page with a line through it, so a retired worker that something still calls is visible rather than inferred.
Minutes 4 to 8: trace one path all the way through
Pick the path the pull request exists for. Follow it from its entry point to whatever it writes: route, handler, queue, worker, store. One path, the whole way, including what happens when a step fails.
This is the only stretch that resembles reading code, and it is deliberately one path. Two paths cost twenty minutes and tell you less than one path plus the shape. Agent-written code tends to be locally plausible, which means the defects collect at the joins: a retry added to a call that is no longer idempotent, an error caught one layer above the place that could have handled it, a new queue whose consumer assumes ordering that the producer never promised.
If the code is in a part of the repository you do not know, this pass still works, because you are checking that the path is coherent rather than that the codebase is. How to review a pull request you didn't write is that case at length.
Minutes 8 to 10: ask what proves it works
Two minutes, one question. What evidence is there that anyone ran this?
A test that exercises the new path counts. A CI run counts. A screenshot of the new screen counts. "Verified locally" in the pull request body does not, and neither does a description of the diff written by the model that wrote the diff. GitHub calls that failure mode hallucinated correctness, and puts agentic ghosting beside it: nobody is around to answer your question, because the author was a process. Prose about code is cheap to produce and easy to believe, which is most of why a summary does not cut review time.
If the evidence is missing, that is the review. One comment, naming the path you traced and the case you want covered, is a better use of minute ten than four style notes.
What if ten minutes says the change is wrong?
Then it saved you fifty. Stop and write one comment about the structure: the component that should not exist, the duplicate of a helper already three directories away, the seam where this should have been two pull requests. Point at the seam the shape shows you, because "please split this" without a seam gets you the same change in two commits.
The rest of the checklist can wait until the structure is settled. When it is, the checklist for agent-authored code is the pass I run before approving.
Where the picture comes from
I built PR Lens because the first two minutes of this method kept being the expensive ones. It draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request, updated in place on every push. Green is new, amber is changed, red is gone, and the parts of the system the change did not touch stay on the page, so what you get is a model of the system rather than a patch. Every comment links to a canvas where the same diagrams are full size, with pan, zoom and a walkthrough that tours the change one step at a time. That link is also the fastest way to explain a change to someone without walking them through the diff.
It is free for open source, MIT licensed, and runs as a GitHub App, a GitHub Action with your own key, a CLI, or a skill your coding agent already has open.
If you know which agent wrote it
The clock is the same for every agent, but the first two minutes change depending on what made the change and what you can still ask it. Each of these is the same method with the specifics filled in:
- Claude Code pull requests, where the session that wrote the code can usually still draw it for you.
- Cursor background agent pull requests, which arrive from a cloud VM with artifacts attached.
- OpenAI Codex pull requests.
- GitHub Copilot coding agent pull requests, where Copilot's own review already sits in the same thread.
- Devin, Jules, OpenHands and other autonomous agents, where there is no session left to ask.
If you want the argument underneath all of this rather than the clock, it is in the complete guide to reviewing AI-generated pull requests.
Questions people ask
How long should reviewing a large pull request take?
- Budget ten minutes for the first pass on a 400-line change, and spend it on structure rather than lines. Two minutes on what the change touches, two on CI and configuration, four tracing one path end to end, two asking for evidence that someone ran it. If those ten minutes turn up a structural problem, stop and comment; the remaining fifty minutes would only have found smaller ones.
Should I just ask for smaller pull requests instead?
- Ask, but do not wait for it. Splitting works on a colleague who is still holding the change in their head. It works poorly on agent output, where the branch is pushed, CI is green, and nobody is around to restructure it. Review the pull request that arrived, then use what you learned to ask for a split at a specific seam.
Is it safe to approve code I have not read line by line?
- You are approving a change to a system, so the question is whether you can say what it changed. Read the lines on the path the pull request exists for and the lines at its edges: CI, configuration, permissions and deletions. Skip nothing that moves a safety net, and read as little as possible of the rest.
What should I look at first in an AI-generated pull request?
- The shape: which components the change touches, what is new, what moved, and what was removed. GitHub's own review guidance starts with the file list and size for the same reason. A diagram of the change answers that in seconds instead of minutes, and a mismatch between the shape and the title is the single most useful thing you can find early.
Sources
Keep reading
Turn it on
Install the App and every pull request in the repositories you pick gets drawn. Or hand the prompt to the agent you already have open.