Review the delta, not the branch

Every merge request in my agent fleet gets a code review from other agents before it merges. Over 2026-09-24 and 25 I measured how long those reviews took: p50 23 minutes, p90 86 minutes. The larger cost was elsewhere, though. 70% of the time a merge request stayed open went to rounds of fixing and re-pushing after the first review.

Those rounds should be quick. The reviewer has already read the change, the author has fixed a few findings, and someone checks the fixes. In practice re-reviews took a median of 15 minutes, against 14 for first reviews. A second look cost as much as the first.

Reviewers were given almost nothing

The first thing I checked was what reviewers were handed. Of 282 review agents, 176 got only a merge-request number. With nothing else to go on, a reviewer does the sensible thing: fetch the branch, diff it against main and read all of it. For a re-review, that means reading the whole change again to find the few places that moved.

I took 12 real re-reviews and counted lines. The full branch diffs came to 14,872 changed lines. The branches' own changes since their previous review came to 3,896, which is 26%. About three of every four lines a re-reviewer read were lines they'd already approved or flagged.

A raw diff is wrong on a merged branch

The obvious fix is to diff the reviewed commit against the new head. That works until the author merges main into the branch or rebases it, which agents do constantly to stay current. From then on the diff includes everything main brought in.

One merged branch made the point. The raw diff from the reviewed commit to the new head showed 2,416 lines. The author's own change in that interval was 575.

# Illustrative
git diff <reviewed> HEAD    2,416 lines: the fix plus everything merged from main
own delta since review        575 lines: what the re-reviewer needs to read

A reviewer given the first number reads about four times as much and has to work out on their own which parts belong to the author.

Replay the reviewed tree onto today's base

The tool I use now records the exact tree each review saw. For a re-review it replays that reviewed tree onto the branch's current merge base with main, then compares the result with the new head. Whatever came in from main is on both sides, so it drops out. What's left is the author's own change since the review.

Sometimes the replay conflicts, because main touched the same lines the branch did. Then the tool falls back to an interdiff of the branch's patches, the same idea git range-diff is built on.

The re-reviewer gets that delta together with the previous findings and a size estimate. Its job has two parts. First it marks each earlier finding as fixed or still open. Then it reads the delta for new defects. That's a much narrower question than "review this merge request", with about a quarter as many lines to read.

Some deltas still need the whole branch

A delta-only review can miss a fix that broke something it didn't touch. So the tool asks for a full re-review in two cases: the delta touches a directory the reviewed change didn't, or it's over 400 changed lines. In that case it prints the whole branch first, then the delta.

I set the threshold from data. The measured fix deltas ran from 93 to 298 lines. The three rounds above 400, at 575 to 976 lines, weren't only fixes. They bundled new features or performance work in with the fixes, and that kind of change deserves a full read.

When nothing has changed since the recorded review point, the tool says no re-review is needed, and none happens.

Start the review before CI finishes

The other half of the change was ordering. Reviews used to start after the merge request was open and its pipeline had passed. Now, once the focused tests pass, review starts on the staged diff, before the merge request exists, and runs in parallel with the full gate and CI.

This doesn't make any single review faster. What it removes is the gap between a green pipeline and a reviewer starting, which was pure queue time. If the review finds something, the fix goes into the first push instead of a second round.

What I know and what I don't

The 26% comes from 12 re-reviews. That's enough to see the shape of the problem, not enough for a tight number. I measured review times before the change. I haven't run the same p50 and p90 measurement over a comparable window since, so I can't tell you what the open time is now.

I'd also be careful applying this to human reviewers. People rarely re-read a whole branch on a second pass; they skim for what moved, and they're usually right about where to look. Agents given a merge-request number do exactly what they're told, which is to read the merge request. Most of this fix was about asking them for what I wanted.

If you want to try it

You don't need my tool to get most of the benefit. Record the commit each review saw. On the next round, rebuild the branch's own change against the current merge base instead of diffing two heads, and hand the reviewer that diff plus the open findings. Send the whole branch only when the delta is large or reaches into new parts of the tree.