What is the blast radius of a code change?
The blast radius of a code change is every feature and system that could fail because of it, and their users. It is often much wider than the diff, the set of changed lines, because other code calls those lines and other programs read what they produce. Estimating it shows what to check before the change ships.
A diff shows what changed, and pull request size measures how much a reviewer has to read. Neither one shows what depends on the changed lines.
A feature inside the blast radius that stops working after the change is a regression. The existing behavior that a change could break is sometimes called its regression surface. After a failure, a debugging session works backward and looks for the recent change whose blast radius includes the broken feature.
The term comes from explosives, where it names the area a blast damages. Reliability engineers use it for how far one failure spreads. The Principles of Chaos Engineering ask teams that run chaos engineering experiments to "Minimize Blast Radius." In agent security, the term also means how much an agent's access lets it damage, which least privilege and a sandbox limit.
How do you estimate blast radius?
Estimating blast radius is a form of change impact analysis. A developer follows the change outward from the diff in five steps:
- The developer lists the changed files, e.g. with
git diff --name-only origin/main...HEAD, and the functions changed in them. - The developer finds the direct callers of each changed function, then the indirect ones, until the search reaches a feature that people use. A build tool's dependency graph can list the modules that depend on the changed code.
- The developer lists the shared state that the change writes, e.g. a database column that another feature reads.
- The developer lists the outputs that leave the codebase, e.g. a file that another team's system imports.
- The developer maps each feature reached to the users and systems that depend on it, and ranks them by the harm a failure would cause.
Ranking by harm is part of risk-based testing, which directs test effort by how likely a failure is and how much harm it would cause.
Teams also limit how far a change can reach, in three common ways:
- Feature flags. A team ships code behind a feature flag that is switched off, then turns it on for a small share of users. A failure in that code reaches only those users, and a person can often switch the flag off without a deploy. A flag covers only the code that checks it.
- Staged rollouts. A staged rollout, often called a canary release, sends a release first to a small group of users and widens it only while error rates stay normal.
- Parallel change. The developer adds a second version of a shared function and moves callers to it one at a time.
What is an example of a wide blast radius?
Here is an illustrative example. Acme Co. sells furniture online. A developer at Acme asks a coding agent to "Let customers edit their delivery address during checkout." The agent changes one line in the shared helper formatAddress(), which now joins the street and the city with a line break instead of a comma. The agent's test for the address form passes, and its output says "done."
Before the merge, the developer searches for the helper's callers:
$ git grep -n "formatAddress(" -- src
src/checkout/address-form.tsx:41: <p>{formatAddress(address)}</p>
src/checkout/confirm-email.ts:18: body += formatAddress(order.address);
src/cli/export.ts:27: row.push(formatAddress(order.address));
src/lib/format.ts:12:export function formatAddress(a: Address) {
The search finds three callers. The address form is the feature the task named. The order confirmation email would show the address on two lines, which customers could still read. The export command, acme export --format csv, quotes each field, so its file would stay valid CSV with a line break inside each address.
Step 4 follows that file, orders.csv, out of the codebase. Each night a warehouse system imports it and reads one order per line. If the change shipped, each order would arrive as two broken lines, the importer would reject both, and paid orders would stop shipping. The blast radius covers the address form, the email, the export, the warehouse import, the warehouse staff, and the customers whose orders would wait.
This example is simplified. A real codebase could also have callers that this search misses, e.g. a template outside src.
What changes when a coding agent writes the code?
A request names a feature, but a coding agent's diff can land in code that other features share. At Acme, the request named the address form, and the diff changed a helper with three callers. A reviewer who estimates from the task alone misses that reach, and out-of-scope edits, e.g. an unrequested rename, widen it further. That gap is one way coding agents break working features.
A long session stacks many changes, and its blast radius covers each of them. On the SWE-CI benchmark, most models kept a codebase free of regressions in fewer than a quarter of long-running maintenance tasks. Small commits that each build let git bisect narrow a later break to one change.
A team can ask the agent to list the callers, shared state, and exported outputs of each shared function it changed. A person checks that list with a search of their own and names the systems outside the repository.
What are the limits of estimating blast radius?
An estimate of blast radius has four common limits:
- Text search misses dynamic calls. Code that calls a function through a name built at runtime does not appear in a search for that name.
- Code tools stop at the repository. A system that imports an exported file often lives in another team's codebase, and its owners may be the only people who can name it.
- Shared data hides links. Two features that never call each other can read the same database column, and neither one's imports show the link.
- An estimate is a list, not a result. The list shows where to look, and running those features shows whether they still work. A feature left off the list gets no check.
When a feature in the estimate fails, running the same steps on the code before the change tells a regression from a pre-existing bug.
How is blast radius different from test impact analysis?
Test impact analysis selects which existing tests to run for a change, using a map from code to tests. Blast radius is what the change could break, even where no test covers it. Both start from the diff, and a good map covers part of the blast radius.
A feature with no test sits inside the blast radius and outside any selection. A system in another repository is outside both the map and the tests. Test impact analysis answers which tests to run, and a blast radius estimate shows which features still need a test or a manual check.
What should run when a change has a wide blast radius?
Run the features on the estimate in order of harm, not only the feature the task names. A user journey test checks each one the way a user reaches it. For an output that leaves the codebase, check the output the way its consumer reads it, e.g. by importing the exported file line by line.
What passed before needs to remain true, unless someone explicitly decides otherwise. RunStory considers your prompts and code changes to decide what to test. A testing agent uses your software in a separate environment, tries relevant workflows, and checks the results while you keep working. It is in private alpha for CLIs and web apps.
FAQs
Where does the term blast radius come from?
The term blast radius comes from explosives, where it names the area a blast damages. Reliability engineers use it for how far one failure spreads, and developers use it for how far a code change reaches.
Can a small diff have a wide blast radius?
A small diff can have a wide blast radius when it changes code that many features share, e.g. a formatting helper. At Acme, a change of one line to such a helper would have broken the warehouse import of exported orders. Diff size measures what a reviewer reads, not how far a change reaches.
How do feature flags limit blast radius?
Feature flags limit blast radius because a team can turn code on for a small share of users first, so a failure in that code reaches only them. A flag covers only the code that checks it, so an edit to shared code outside the flag still reaches its callers.
Who should estimate the blast radius of a change?
The developer who makes a change should estimate its blast radius, and a reviewer should check that estimate. When a coding agent made the change, a person checks the agent's list of callers with a search of their own and names the systems outside the codebase.