Blast radius diagrams: what a change touches, drawn against the system

The blast radius of a change is everything the change can reach: the files someone edited, plus the routes, workers, queues and stores on the far side of those edits that now behave differently. A diff lists the first half and says nothing about the second. The gap grows with the size of the change, and changes got bigger. LinearB's 2026 benchmarks, taken from 8.1 million pull requests across more than 4,800 organisations, put AI-assisted pull requests at 408 changed lines at the 75th percentile against 157 for unassisted ones. A blast radius diagram puts both halves on one page.

What blast radius means for a code change

The phrase comes from operations, where the blast radius of an incident is the set of things that fall over with it. Review borrows it unchanged. Given this diff, if it is wrong, what else stops working?

The answer has four parts, and only one of them is in the diff:

• the components the change added,
• the ones it modified,
• the ones it removed,
• and the ones it left alone that are now sitting downstream of something new.

That last group is where the surprises live. A pull request that adds one queue and one worker has edited two files and changed the failure mode of every producer that writes to the route in front of them. Blast radius is everything a change can reach, and a diff only lists the part somebody edited.

Why a diff cannot show you the blast radius

A diff is ordered by file path, which is an ordering the code does not care about. Nothing in it says which of those hunks call each other, and nothing says which untouched file is now on the receiving end of a new call. The reviewer rebuilds that graph in their head, file by file, from names.

Two things make that reconstruction harder now than it was. Agent-written changes spread across backend, config, tests and UI in one pull request, as Salesforce Engineering has described, so there is no narrative order to lean on. And Faros AI reports that under high AI adoption the share of pull requests merged with no review rose 31.3%, which is what happens when reconstruction costs more than the reviewer has.

GitHub's own guide to reviewing agent pull requests puts "trace one critical path" in the five-to-eight-minute slot of a ten-minute review. That instruction only makes sense because the path is not written down anywhere. A blast radius diagram is the path, written down.

The parts a change did not touch belong in the picture

This is the design decision most diff-to-diagram tools get wrong, and it is the one that decides whether the picture is useful. If you draw only the changed nodes, you have drawn the diff again in boxes.

PR Lens treats untouched context as a first-class state in the contract. Every node, edge and flow step in a graph document carries one of four deltas: added, modified, removed or unchanged. The schema package is explicit about why:

unchanged elements are the context a reviewer needs to judge blast radius, so they belong in the document rather than being filtered out.

The PR Lens schema, packages/schema

The agent skill says the same thing to the model writing the document: a diagram of only the changed nodes says nothing about blast radius, so mark the unchanged neighbours and keep them.

Delta colour: green new, amber changed, red gone

Colour carries the delta so you do not have to read a legend. Green outlines and a NEW badge for what arrived. Amber and CHANGED for what was edited. Red for what is going, and removed components are ghosted back and struck through rather than deleted from the drawing, so you can see the shape of the thing that used to be there. Untouched components keep the neutral card.

Three colours and a strike-through is the whole vocabulary, which is as much as a picture can carry and still be read in one pass. A diagram that needs a key is a diagram you read twice.

Reading one: fifteen components, three lanes

The diagram at the top of this post is a feature landing across a small system. Three lanes hold it: UI, core and infrastructure. Fifteen components sit in those lanes. Four are added, five are modified, two are removed, and four were never touched by the diff at all.

Read it in that order and the change explains itself. POST /api/plans is amber, so the endpoint moved. Behind it, buildPlan, schedulePlan, batchResults and auditTrail are green, so the work behind the endpoint is new. legacyPoller and pollQueue are struck through, so the old scheduling path is going. And Dashboard, authorize, recordMetrics and Object storage are plain cards, which tells you the front end and the auth boundary are not part of this, and saves you opening either.

Most of what a blast radius diagram does for you is rule things out, and ruling out is the part of a review that never gets written down.

The order I read them in is backwards from the way they are drawn. Struck-through components first, because a deletion is the only thing in a pull request that can break code nobody in the review is looking at. Then the one edge the change is really about, which the renderer draws thicker and gives a glow. Then any plain card sitting directly downstream of a green one, because that is a component whose behaviour changed without its source changing, and it is exactly the case a file-by-file read misses. Everything else can wait for the diff, or not get read at all.

Blast radius at monorepo scale

The technique does not fall apart when the change is large; the lanes do the work.

Six lanes, thirty-seven components: web apps, API, services, packages, data and external systems. Thirteen components are added, ten modified, three removed, and eleven untouched. You still cannot hold that change in your head from the file list. You can see at a glance that it does not reach Stripe, Sentry or the identity provider, which decides how much of an afternoon this pull request is going to cost you.

There is more on how one renderer covers a one-file fix and a change this size in one renderer, three sizes.

When blast radius is the wrong question

Blast radius is a question about extent. Plenty of changes raise a question about order instead: what calls what, in which sequence, and how many times. A refactor that turns 2,000 requests into 4 has a small blast radius and an important sequence.

A data-flow view answers those: participants, ordered steps, one dot crossing one arrow at a time. Architecture, sequence or data-flow diagram works through which question each one answers. Most pull requests want the architecture view first and a flow only if there is a sequence worth animating.

Getting one on your own pull requests

Four routes, all of them producing the same picture.

The GitHub App at github.com/apps/coldtea-pr-lens is the shortest one: pick the repositories once, and every pull request opened in them is drawn and redrawn on each push. The hosted App keeps a baseline of the repository and tracks it across commits, which is how it has anything to draw the changed components against.

If you would rather keep the model call in your own CI, the GitHub Action runs coldteadotai/pr-lens/packages/action@v0 from a workflow file with your own key. The CLI, @coldtea/pr-lens-cli, draws a change on your laptop before you push it. And the agent skill reasons with whatever model your coding agent already runs, so there is no key at all.

How to visualise a pull request as a diagram ranks all of the ways to get a picture out of a change, including the ones that have nothing to do with us.