The First Reviewer on Your PR Shouldn't Be Human

Anthropic's Claude Code team just published how they review code. The takeaway: every diff gets a machine pass before humans look.

Dafallah Ibrahim

— 2 min read
Share

Code review is where pull requests go to wait. Your diff is done, tests pass, and then it sits for a day and a half because the two people who can approve it are in meetings. Anthropic's Claude Code team just published how they handle review — it's on the front page of HN right now — and the interesting part isn't their tooling. It's the division of labor.

The pattern worth stealing: a machine reviews every diff within seconds of the push. Humans only see PRs that already survived a first pass. Feedback latency drops from hours to minutes, and the humans still in the loop spend their attention on design instead of spotting missing null checks.

Why this matters

Review latency is a hidden tax on shipping. Every hour a PR waits is an hour of context rebuild when comments land, plus merge drift if the codebase moved underneath you.

An AI first pass also raises the quality floor. Human reviewers skim the fifth boring PR of the day. A model reads line 400 of that migration script with the same energy as line 1. Unhandled errors, forgotten edge cases, missing tests — the stuff people mean to check and sometimes don't.

How it works

Treat review as two different jobs. Mechanical review — bugs, unhandled errors, missing tests, breaking API changes — is pattern matching over a diff, which is what a model with repo context does well. Judgment review — is this the right abstraction, should this exist at all — stays human.

Prompting matters more than the model. "Review this" produces nitpick soup. Give it a narrow rubric, tell it to ignore formatting, and require file-and-line citations for every finding. A finding without a location can't be acted on, so it's noise.

Run it in CI or as a headless CLI step so it fires on every push — not when someone remembers to ask.

Where this helps

  • Time-zone-spread teams: pushes get real feedback in a minute instead of the next morning.
  • Large mechanical refactors: hundreds of files of renames where human eyes glaze over by file thirty.
  • Legacy code: the reviewer that actually reads three unfamiliar call sites before commenting.
  • Reviewer fatigue: humans stop rubber-stamping the tenth minor PR of the day.

Watch out

An unconstrained reviewer floods PRs with comments, and comment spam burns out contributors faster than no review at all. Keep findings advisory, never blocking.

Models hallucinate APIs. They will confidently cite a helper that doesn't exist in your codebase, so give it repo access rather than a raw diff — and don't auto-merge on its word alone.

It's still not a substitute for the senior engineer who says "wrong architecture, start over," or for a real security review. This raises the floor; it doesn't move the ceiling.

Try it yourself

Run a headless review pass on your branch before you even open the PR:

git diff origin/main...HEAD > /tmp/pr.diff

claude -p "Review this diff against a strict rubric:
1. Bugs and logic errors
2. Unhandled error paths
3. Missing tests for changed behavior
Ignore style and formatting entirely.
Cite file and line number for every finding.
If you find nothing, reply with exactly: LGTM." < /tmp/pr.diff

TL;DR

  • What changed: Anthropic's Claude Code team published how they run code review; AI-first review hit HN's front page.
  • Why it matters: machines on the mechanical pass cut review latency to minutes and keep humans on design decisions.
  • Try today: run the headless diff review above on your next PR — rubric-constrained, advisory-only.

Read more