How I'd do pull request review today
On this page
I don’t read every line of code before it merges anymore. For most of my career, that’s what code review meant. Now AI writes most of my code, reading all of it no longer scales, and skipping review isn’t an option either.
Claude writes about 90 percent of Claude Code’s own code, and the team behind it recently published how they do code review. This is how I’d set it up today, borrowing a lot from them.
1. Ask what could go wrong, not who read it
The line from their write-up that stuck with me: “did a human read the code?” is an imprecise proxy for “what could go wrong with this change, and which check, automated or human, is the right one to catch it?”
Once you think about review that way, it stops being one step and becomes layers: proof from the author, CI, an automated review, a security review where it matters, and a person where the risk calls for one.
2. Make CI the floor
Every pull request runs lint, type checks, the full test suite and a build, and nobody merges one that’s red. Reviewers, human or AI, shouldn’t spend time on anything a machine already checks.
3. The author proves it works before asking for review
Before a pull request is marked ready, the author, person or agent, shows that it works: test output, a passing build, and screenshots or a recording for anything with a screen. “I ran it” isn’t evidence. The output is.
I’d ask for three things in every description:
- What changed in behaviour, in a few lines a reviewer can read in a minute.
- The evidence, including what wasn’t checked. “Tested in English only, no text changed” tells me exactly how much to trust the screenshots.
- The merge danger: can a plain revert undo it, or does it change data that a revert won’t bring back? And in the worst case, who is affected and how?
4. Let the change pick its risk tier
Risk comes from what a change touches, not from who or what wrote it. I’d use three tiers:
- Low: docs, copy and translations. An automated review, then it merges on green CI.
- Medium: most product changes. A deeper automated review, and a person checks the proof.
- High: sign-in and permissions, money calculations, database migrations, outside integrations, and CI or deployment scripts. The deepest automated review plus a security review, and a person reads the diff.
Write the high-risk paths down, so nobody argues about them case by case. An agent’s approval never counts as a person’s. Ideally two people read a high-risk diff. If you only have one, the extra automated reviews stand in for the second.
- Green CI
- Proof in the description that it works
- An automated review, 1 roundA deeper automated review, up to 2 roundsThe deepest automated review, up to 3 rounds
- A security review, not needed
- No person needed: it merges on greenA person checks the proofA person reads the diff
The change picks the tier, and the tier picks the checks.
5. Cap the review rounds
An AI reviewer can always find one more thing, and left alone, an agent author and an agent reviewer will keep each other busy all night. Most of what later rounds flag was already there in the first pass.
So tie the rounds to the tier: one for Low, two for Medium, three for High. After the first round, review only what changed. Fix each flagged mistake everywhere it appears, and file problems in untouched code as separate issues. If the last round still finds problems, rethink the approach instead of patching again.
The Claude Code team added similar rules, and the share of their pull requests that passed after one round went from 65 to 78 percent.
Without a cap, two agents can keep each other busy all night.
6. Let a script catch the boring mistakes
Watch what your first review round keeps finding. Often it’s mechanical: a branch that no longer merges cleanly, a description missing its tier or its evidence, a database migration that was edited after it shipped. None of that needs an AI reviewer, let alone a person.
A small script that checks the branch and the description before review starts catches all of that. After that, review rounds go on real bugs.
7. Turn escaped bugs into rules
When a bug gets past review, the fix should add whatever would have caught it: a test, a lint rule, or a line in the coding standards the agent reads. Same when the reviewer flags the same kind of mistake on a second pull request. The pull request that fixes it says which one it added.
I’d also keep a short list of the rules a machine already checks, so reviewers trust those checks and spend their time on judgement. And one rule I’d add on day one: if a ticket says some behaviour “already exists”, the pull request needs a test that proves it. Agents are very good at believing code exists when it doesn’t.
8. Keep the setup simple
It’s tempting to build an elaborate pipeline with one agent to plan, one to build, one to review, one to test and one to judge the tests. I built one this month, and threw it away two weeks later. One agent session doing the whole job, with a fresh-context review at the end, did the same work with far fewer moving parts.
Anthropic reached a similar conclusion in when to fold subagents into your main agent loop. The one place I’d still use a separate agent is the review, because a reviewer that didn’t write the code doesn’t share the author’s assumptions.
9. Make undoing a mistake cheap
Review will miss things. So make it quick to switch off a risky integration or feature without a deploy, keep pull requests small enough to revert cleanly, and say in the description how to undo it.
What a person still does
A person decides what gets built in the first place. A person reads the high-risk diffs, checks the proof for everything else, and owns what ships, whoever typed it.
And a person keeps the numbers that tell you whether any of this works. If I were starting today, the first number I’d track is how often merged changes get reverted. If that goes up, you haven’t saved any time, you’ve only moved it.
If AI writes most of your code too, how do you decide which changes still need a person to read them?
0likes
thank you!This article first appeared on linkedin.com