Blast radius beats diff size
Every review process on earth triages by lines changed, because for thirty years lines changed was a decent proxy for effort and risk. Generation broke that proxy. What a change can reach now matters far more than how big it is.
Two pull requests land in the same hour.
One is eighteen hundred lines. An agent renamed a concept across a service, updated forty call sites, and regenerated the tests. It is mechanical, it is uniform, and it is intimidating to open.
The other is nine lines. It changes a conditional in the function that decides whether a request is permitted to read another tenant’s data.
Every review process I have seen will spend more attention on the first one. Reviewers self-select toward it because it looks like the serious work. The nine-line change gets an approving glance, because nine lines is not a thing you slow down for.
My position: diff size is now an actively misleading triage signal, and review capacity should be allocated by blast radius, which is what a change can reach, not by how much of it there is. This is not a subtle refinement. It is the difference between spending your scarcest resource on the risk and spending it on the volume.
Why size ever worked
Lines changed was never a measure of risk. It was a measure of effort, and effort correlated with risk because a human had to produce every line, and the ones that took the longest were usually the ones touching things that were hard to reason about.
That correlation carried a lot of weight quietly. Big diff meant someone had been in there for days. Small diff meant a targeted fix by someone who knew what they were doing. Both readings were usually right.
Generation severed it. An eighteen-hundred-line rename now takes four minutes and carries almost no risk, because it is uniform and mechanical. A nine-line change to an authorisation predicate takes the same four minutes and can expose every tenant in your system. The effort signal is gone and nothing replaced it, so review attention is being allocated by an input that no longer carries information.
The consequence shows up in the benchmarks. LinearB’s 2026 numbers put median review duration up over 400 percent and pull requests merged with zero review up around 31.3 percent. That is not just more work arriving. It is attention being spent badly, so that the queue grows until the overflow valve opens, and the changes that go through the valve are not sorted by consequence.
Small diff, low radius
Copy change on an internal page. Sample it. Automated checks are sufficient. This is most of your volume.
Large diff, low radius
Mechanical rename, generated test expansion. Verify the transformation is uniform, then move on. Reading all of it is theatre.
Small diff, high radius
Nine lines in an authorisation check. Named reviewer, no exceptions, and the one your current process handles worst.
Large diff, high radius
New payment path. Should not have been one change. Ask for it to be split before reviewing anything.
What makes a path radius-bearing
Blast radius is not a vibe, and you do not need a model to estimate it. It is a property of your repository that you can enumerate in an afternoon with the people who know the system.
Certain paths carry consequence out of proportion to their size. They share recognisable characteristics.
The last row is worth taking seriously as a shortcut. Your incident history already encodes a blast radius map, and you do not have to build a static analysis pipeline to read it.
Routing, not reading
Once you can classify a change by what it reaches, the review policy writes itself, and it is a routing policy rather than a reading policy.
High radius gets a named reviewer with domain knowledge, a stated criterion to check against, and no route to merge without a recorded judgement. Not “an approval”. A judgement, from a person who could tell you what would have made them say no.
Low radius gets automated checks and sampling. Sample deliberately, at a rate you have chosen, and treat what the sample turns up as information about the whole population rather than as a set of individual defects. If sampling ten percent of low-radius changes never finds anything, that is a real result and you should sample less. If it finds something every week, your classification is wrong.
The uncomfortable part is that this means openly deciding not to read some changes. Teams resist saying that out loud, so they keep a policy of reviewing everything, which they then fail to honour, and the failure distributes itself randomly instead of deliberately. A stated sampling rate is more honest than a universal rule nobody meets, and it produces better outcomes because the exceptions are chosen.
The developers already know
One practical note that saves a lot of argument.
You do not need to derive blast radius analytically. Ask three engineers who have been on-call for the system to independently list the twenty files they would least like an agent to change unsupervised. The lists will overlap heavily. The overlap is your high-radius set, it took an hour to produce, and it will be more accurate than anything you infer from call graphs in the first pass.
Then check it against your incident history and adjust. That is the whole exercise. The reason it does not get done is not difficulty, it is that nobody owns making the decision, so review policy stays uniform by default.
Where this breaks down
Blast radius is much harder to compute than diff size, and that matters. Diff size is free, universal and unambiguous. Radius requires a judgement per path, maintenance as the codebase evolves, and someone to own the list. Lists like this rot. A stale radius map that routes attention to last year’s risky paths is worse than an honest heuristic, because it carries false authority.
Large mechanical diffs are not as safe as I made them sound. A uniform rename across forty call sites is low risk only if it really was uniform. Agents produce changes that are locally plausible and globally inconsistent, and a two-thousand-line diff is exactly where one wrong call site hides. “Verify the transformation is uniform” is easy to write and genuinely hard to do at that scale.
High-radius paths are where your experts are, and they are already the constraint. Routing all consequential change to a small set of named domain reviewers concentrates load on the people who are least available. You may find you have improved the allocation of attention and made the queue worse. The answer is probably to widen who counts as a named reviewer for each area over time, which is a hiring and development problem, not a routing one.
Sampling is only defensible if the population is genuinely low consequence, and the classification is the weak link. Every failure of this scheme is a change that was classified as low radius and was not. Since the classification is the thing being trusted, the honest version needs periodic audit of the low-radius sample by someone looking for misclassification, which costs more than teams expect.
And this is one input, not a review policy. Authorship matters, novelty matters, whether the change is the third attempt at the same fix matters. I have argued for replacing one crude signal with a better one, and a better single signal is still a single signal.
The takeaway
Diff size measured effort, effort correlated with risk, and generation broke the correlation. Continuing to triage by lines changed means spending your scarcest reviewers on your safest changes while nine-line authorisation edits go through on a glance.
Classify your paths by what they can reach. Route high-radius change to a named human with a stated criterion. Sample the rest at a rate you have chosen deliberately, and say out loud that you are doing it.
If you take one thing into next week: ask three of your on-call engineers to each list the twenty files they would least like changed unsupervised, take the overlap, and check how many of last month’s merges touched those files without a named reviewer.