Blast radius of a code change

Where the term comes from

Borrowed from incident response, where the blast radius of a failure is everything that goes down with it. Applied to a code change, it is everything that could behave differently because of it.

The useful property of the metaphor is that it puts the centre and the edge on one scale. A change has an epicentre — the code that was edited — and a periphery that is affected without being touched, and the periphery is where the surprises live.

Why it is not the diff

The diff is the epicentre only. Everything else in the blast radius has unchanged source code.

Concretely, a change to one function's behaviour reaches:

• every function that calls it,
• every route whose handler reaches those,
• every background job on the same path,
• every test that asserted the old behaviour,
• and, if the change was to a shared type, everything that constructs or consumes that type.

None of that appears in a file list. This is the core reason reviewing an agent-written change by reading its diff performs badly: the diff is large enough to exhaust your attention and it still does not contain the part you needed.

Estimating it

Walk the call and import graph outward from every changed symbol, counting hops. Then apply judgement about where to stop, because reachability is not the same as risk.

Useful heuristics:

• A changed private function with one caller in the same file has a blast radius of that file. Do not spend review on it.
• A changed exported signature has a blast radius of everything that imports it, and that set is worth enumerating exactly.
• A changed shared type is usually the largest radius per line of diff in the entire category — a two-line change to a type can reach a hundred files.
• A changed database schema has a blast radius that includes code you cannot see: other services, jobs, analytics queries, anything reading that table.

Where it stops being meaningful

Past two or three hops the concept degrades. In a connected codebase, enough hops reach everything, and a tool reporting "this change reaches 340 files" has produced a fact about your coupling rather than about your change.

The practical stopping rule: stop when the next hop's members are affected only in the sense that they call something that calls something. If a tool insists on going deeper, it should mark how far out each result was found, so the reader can discount by distance.

What widens it

Blast radius is largely a property of the codebase, not of the change. The same edit in two repositories can reach four files or four hundred.

What widens it: shared mutable state, god objects, types imported everywhere, deep inheritance, and components that expose large public interfaces. What narrows it: clear module boundaries, narrow interfaces, and dependency direction that is actually enforced.

Which makes a consistently large blast radius a design finding rather than a review finding. If every small change reaches everything, the review comment belongs on the architecture, not on the pull request.

Related

• Change impact analysis — the computed version of this.
• Architecture drift — what makes blast radius grow over time.
• Your agent changed 60 files. Where do you start?