Before you merge a pull request, you probably check tests. Maybe you run a linter. You might even do a manual code review. But there's one number almost no team looks at: blast radius, how many modules your change can reach through the dependency graph.
What blast radius actually measures
Blast radius is not "how many files you touched." It is "how many files could be affected by what you touched." The distinction is the difference between a local edit and a systemic one.
If you modify a utility function called by 40 other modules, your blast radius is 40, regardless of whether your diff touches one line or a hundred. The graph structure of your codebase determines the number, not the size of your change.
A small, clean diff with a high blast radius is more dangerous than a large, messy diff with a blast radius of one. This is the insight that pure diff-review misses.
Why current tools don't show it
Most code review tools are text-centric. They show you what changed. They do not show you what is reachable from what changed. Computing reachability requires a graph traversal across your whole codebase, something that needs to be pre-built, indexed, and queryable in real time.
AI-assisted code review tools have the same limitation at a different layer: they reason about the text of your diff, not about the structural position of the changed code in your dependency graph.
The three blast radius tiers that matter
Tier 1, isolated changes (BR < 5): modifying private implementation details, local utilities, leaf-node functions. Low risk, fast to review.
Tier 2, module-level changes (BR 5, 20): touching shared interfaces, internal libraries, widely-imported utilities. Needs broader attention in review; tests should cover callers.
Tier 3, systemic changes (BR > 20): modifying foundational abstractions, core services, high-centrality graph nodes. These changes need staged rollouts, explicit caller audits, and blast-radius-gated deploy gates.
How Spiderbrain computes it
Spiderbrain builds a directed import graph from your codebase at commit time. Blast radius for any node is the number of nodes reachable from it through transitive imports, computed in O(V + E) via a BFS/DFS from the changed node set.
Because the graph is built deterministically from source, the blast radius of any function is a stable, auditable number. It does not change unless the code changes. It is the same for every team member, every environment, every run.
Using blast radius in practice
Pre-merge: surface blast radius in your CI pipeline. Flag PRs where BR exceeds your team's threshold for tier-2 or tier-3 review.
During refactoring: sort your refactor plan by blast radius, ascending. High-BR nodes are your last step, not your first, they depend on everything below them being stable.
For incident postmortems: compute the blast radius of the commit that caused the incident. High-BR + no caller test coverage is almost always the root cause pattern.
The number that changes how you review code
Once your team can see blast radius, code review vocabulary changes. "This is a small change" stops being a proxy for "this is a safe change." The question becomes: what is the structural position of this change? How many modules depend on it? Have we covered the callers?
That shift in framing is what code intelligence is for.