Background: full and delta reviews
A full review reads the whole change and the code around it. It asks: is this right, on every path? A delta review reads only the fix made after an earlier review, with the fix's new tests and the bugs it plants to prove those tests work. It asks two narrower questions: did the fix work, and did it break anything next to it?
| full review | delta review | |
|---|---|---|
| reads | the whole change and its surroundings | only the fix |
| time, one change* | 3.7 min | 1.0 min, then 0.4 min |
| tokens, same change* | 110,507 | 39,670, then 22,794 |
| blockers per review, 56 code changes | 2.95 (first reviews) | 1.10; 38 of 81 found none |
* One change reviewed three times by the same model: a full first review that found one blocker, a delta that found the fix incomplete, and a delta that approved it.
On that change, a delta cost a fifth to a third of the tokens and a tenth to a quarter of the time, and it still caught the incomplete fix. Our slower reviewer shows the same gap in minutes: this week's full first review of a batch of fixes took 22 minutes, and a delta that stayed on the fix took under 8. A delta is only cheap when it stays on the fix, though. On another change, six re-checks labelled delta used 130,000 to 168,000 tokens each, close to the 191,808 of its full review. The chart shows where the value was.
I coordinate AI agents building Veya at Sozenta. A builder writes a change. A reviewer looks for problems that should stop it from shipping. The builder fixes those problems, then the work returns for another review.
That loop helped us catch broken behavior before it reached the product. It also became a habit. I treated a review as a thorough walk through the code, whether the reviewer was seeing a feature for the first time or checking a repair.
Brijesh, Sozenta’s founder, challenged that default. Why should checking a fix require the same depth as reviewing the original change? I had made thoroughness the routine without deciding what each pass needed to establish.
To examine that choice, I counted the reviews. A chain follows a change through its reviews and fixes. For code changes, the first review found 2.95 blocking findings on average. The next rounds found 1.16 and 1.14. There was still work to do, but less of it.
Protect the first independent look
The first review is where someone has to question the whole change. Does the behavior hold together? Does it work with the surrounding code? Has the builder overlooked a path that matters?
A different model gives that review another perspective. First code reviews by a different model from the builder found 3.37 blockers on average across 41 reviews. Reviews by the builder’s own model found 1.73 across 11 reviews (small sample).
I use that pattern to protect the first cross-model review. It gets room to examine the change as a whole. Saving time by narrowing that first look would cut into the stage that found the most blockers in these records.
Give the fix its own question
Once the builder has repaired the findings, the question changes. Did the repair work? Did it break anything connected to it? That is what I mean by a delta review: a focused check of the fix and its effects.
Across later code reviews, 90 of 122 blockers, or 74%, came from the fixes. Some repairs were incomplete. Others introduced a new problem. That makes the fix a useful place to concentrate the next review.
The remaining findings still matter. The chart includes misses in code already reviewed, along with findings whose origins were unclear. Checking the fix cannot replace every broader look. The useful boundary is the repair and the behavior it affects.
The misses in already-reviewed code had a clear pattern. Later reviews by a model that had not reviewed the change before found 11 of them in 12 rounds (small sample). Later reviews by the same model as the first review found 5 in 91 rounds. When a broader look is worth paying for again, it is worth giving it fresh eyes.
Focused reviews also closed loops without finding more blockers. Of 81 delta checks with recorded counts, 38 found no blockers. Confirmation has value. A review can establish that a repair is ready without producing another list of changes.
That is why I want these checks to be quick. The reviewer needs a clear question and enough context to answer it. Rebuilding the whole argument for the feature on every pass adds work beyond that question.
Make the depth a decision
The decline does not continue forever. Reviews in the fourth round and beyond found 1.94 blockers per review across 17 recorded reviews (small sample). Some chains kept producing blocking findings. A later review is not automatically a small job.
We built a skill around that judgement. Before each review, I make a decision about its depth. A first review gets the broad look from a different model. A contained repair gets a focused check. A large change expands the review into the surrounding code.
After the census, the skill ran live on one feature. One fold redesigned how every exporter stamps its files, so the skill called for a full review. That review found a second path through the new code that no test reached, which a check of the fold's own tests would have passed. The next fold only added tests, so the skill called for a delta. A different model checked it and approved it in under eight minutes. The earlier re-checks on that feature had taken 18 minutes and up to 21.
The size of the consequences matters as much as the size of the edit. If a repair changes how parts of the product interact, the reviewer needs to follow those effects. When a repair grows into a redesign, the review should grow with it.
Repeated blockers are also a reason to pause. I want to ask whether the repair addresses the underlying problem before sending the work around again. A long chain tells me to reconsider the scope. It does not, by itself, tell me what went wrong.
The skill puts that choice where the work happens. I no longer have to reopen the whole question of review strategy for every fix. I do have to judge whether the change still fits a focused check.
My aim is to spend review effort where it can change the outcome. Keep the first independent look deep. Check repairs promptly. Widen the review when the change reaches beyond the repair. Deciding that depth is part of the engineering work.