An agent is asked to change how a discount code gets validated. It finds the function, rewrites the logic, adds a test, and the test passes. The diff is eleven lines, cleanly formatted, with a sensible commit message. Nothing about it looks risky. Three days later a nightly reconciliation job starts failing, because a different service called the old function directly and depended on a return value the new version quietly stopped producing. The agent never opened that service. It had no reason to. Nothing in the file it was editing pointed there.
Nobody wrote a bad line of code in that story. The function is correct on its own terms, and the test that shipped with it passes. What broke was never visible in the diff, because it was never in the diff. It was downstream of it, in a part of the system the change never touched and that nobody reviewing the change ever saw. That downstream set, the full list of things that could break because of a change regardless of whether the change looks anywhere near them, has a name in software change management. It is the blast radius. Knowing it before a change ships is a different discipline from writing a correct change, and it is the discipline that AI-assisted development is currently missing.
Origin: blast radius, before it meant a code change
The phrase is borrowed from explosives: how far the damage reaches from the point of detonation. Site reliability engineering picked it up for the same reason incident responders did, because it names the first question that actually matters once something breaks. Not what caused this, but how far does this go. AWS's Well-Architected Framework builds a whole reliability practice around the idea under the name bulkhead architecture, itself borrowed from shipbuilding: a hull is divided into sealed compartments so a single breach floods one compartment instead of the entire ship. A cell-based cloud architecture does the same thing to a service. Ten cells serving equal shares of traffic mean a bad deployment to one cell affects at most a tenth of requests, not all of them. The infrastructure is deliberately shaped to keep blast radius small before anything goes wrong, because containing damage after the fact is far more expensive than bounding it in advance.
Software change management borrowed the same word for a narrower, more everyday question: not what fails when the system fails, but what could be affected by this specific change. Every code change has two descriptions. One is the diff, the literal lines added, removed, or rewritten. The other is everything downstream of those lines: every caller of a function that changed, every consumer of an API whose response shape moved, every test that exercises the changed path, every service that assumed a default the change quietly altered, every scheduled job that calls old behavior nobody remembers is still load-bearing. The diff is small and visible. The blast radius is often large and invisible, because dependency in a real codebase rarely runs in a straight line from the file being edited to the thing it might break. It runs through interfaces, shared state, message queues, cron jobs, and contracts that were never written down anywhere except in the behavior of the code itself.
This matters as a discipline, not just a vocabulary word, because the size of a diff and the size of its blast radius are not the same measurement. A one-line change to a widely called function can have a larger blast radius than a five-hundred-line change to a file nothing else imports. The gap between how big a change looks and how far it actually reaches is where most production incidents live, and it is a gap that predates AI by decades. What has changed is who, or what, is now expected to close it, and how much time they have to do it in.
Present: when the diff outruns the map
For most of software history the two measurements stayed loosely correlated because of who was producing the diff. A person who has worked in a codebase for a year carries an informal map of it in their head. They know, roughly, that touching the pricing module means checking the invoicing job, because they got paged about it once. That tacit map is not written down anywhere, it is slow to build, and it walks out the door when the person leaves. But it existed, and it quietly stopped a lot of dangerous changes from shipping, because the person writing the change had a nagging sense that something else needed to be checked first.
An AI coding agent does not have that map, and it is worth being precise about why, because this is not a matter of the model being careless. A large language model reasons over whatever has been placed in its context window: the files it opened, the ones a human pointed it at, the results of the searches it ran. It infers structure from what it has been shown, the way a new hire would after reading a handful of files, except it does this in seconds and writes with the same confident tone regardless of how much of the system it actually saw. This is the same mechanism behind context rot in long agent sessions: the model's read of a codebase is a function of what fit in the window, not a function of what is actually true about the codebase. A caller that lives in a file the agent never opened is invisible to it in exactly the way it would be invisible to a new hire who has not read that file yet, except the agent still writes the change, runs its own test, and reports success.
Two recent bodies of research point at the same gap from different angles. In 2023, Stanford researchers testing the model behind GitHub Copilot found that participants with access to an AI coding assistant wrote measurably less secure code than a control group across most of the tasks they were given, and, in the more uncomfortable finding, were more likely to believe their code was secure than the participants working without one. Confidence went up. Correctness, on the axis the study measured, went down. Separately, GitClear's 2025 analysis of roughly 211 million changed lines across repositories at Google, Microsoft, Meta, and other large organizations found that the share of copy-pasted code climbed from 8.3 percent in 2020 to 12.3 percent in 2024, while the share of code that was refactored, meaning moved and reconciled with its surroundings rather than duplicated, fell from 24.1 percent to 9.5 percent over the same years. That was the first year in the data that copy-paste overtook refactoring. Neither finding says AI-generated code is simply wrong more often. Both point at the same underlying pattern: code is increasingly added and rewritten locally, in the shape the immediate task calls for, without the accompanying work of reconciling it with everything nearby that already depended on the old shape. That reconciliation is exactly the work a human's tacit map used to do without being asked.
The scale of the exposure is not hypothetical. A 2025 study published in Science tracking generative AI's diffusion through GitHub found that 29 percent of new Python code in the United States was AI-assisted by early 2025, up from about 5 percent in 2022. Around the same time, Microsoft chief executive Satya Nadella said that 20 to 30 percent of the code in Microsoft's own repositories was already being written by AI. Whatever the exact figure at any one company, a large and growing share of the changes moving through production systems are being written by something with no persistent structural model of the system it is editing. The industry already has a name for the outcome when a shipped change causes a production failure: change failure rate, one of the longest-running and most cited measures of software delivery performance, which in its 2024 benchmarking put elite-performing teams at roughly 0 to 5 percent and low performers well above 15 percent. That gap between elite and low performers has historically been explained mostly by process: review discipline, test coverage, deployment practice. An agent that writes fast and sees narrowly adds a new variable to that equation, one that has nothing to do with how careful the process is on paper and everything to do with whether anyone, human or model, actually knew what the change touched before it shipped.
Present: how teams estimate blast radius today
None of this is a new problem, and the industry has not been guessing blind. Four techniques, usually layered together, are how most engineering organizations approximate blast radius today, and each is a genuine, useful answer with a specific, well-understood limit.
Static analysis and call graphs build a model of which functions call which other functions, then walk that model outward from a changed line to see what else touches it. Tools like CodeQL take this further, treating a codebase as a queryable database of data flow rather than plain text, so a reviewer can ask a real question, such as which callers eventually receive this value, and get a real answer. The limits are structural, not incidental. A large-scale study of call-graph-based impact prediction, run across ten open-source Java projects using more than 17,000 injected faults, found that more sophisticated graph models captured more of the true impact but at a real cost to precision, and that the simplest call graph often gave the best balance between catching real impact and drowning it in false positives. Impact analysis by call graph is real and useful. It is also a tradeoff, not a solved problem, and it typically runs at review time, after the change already exists, rather than before anyone starts writing it.
Dependency graphs at the scale of an entire codebase are the more ambitious version of the same idea, and the clearest account of what that costs comes from Google's own engineers. In a widely cited 2016 paper, Rachel Potvin and Josh Levenberg described why the company keeps essentially its entire codebase, billions of lines across roughly nine million files, in one monolithic repository rather than splitting it apart: a single repository lets tooling see every dependency at once, which is what makes atomic, cross-project changes and large-scale automated refactoring possible in the first place. That is a real, working answer to blast radius. It is also an answer that costs what Google spent to build the custom version control and tooling that make a single-repository dependency graph usable at that scale. Almost nobody else has that infrastructure, which means almost nobody else has that graph either, however much they might benefit from one.
Test coverage heuristics take a more modest, empirical route: instead of reasoning about the code's structure, watch which tests actually touch which files when they run, and use that history to predict which tests a given change should trigger. Microsoft's Test Impact Analysis in Azure DevOps works exactly this way, recording which source files each test exercises on a baseline run and then selecting only the tests whose recorded dependencies overlap with a new commit. It keeps CI fast and is genuinely useful, but it inherits the coverage gaps of the test suite it is built on. A dependency nothing tests is a dependency this method cannot see, and it falls back to running everything whenever it cannot reason about what changed, which is itself an admission that the map is incomplete.
Code owners are the oldest technique of the four and the most human. A CODEOWNERS file maps paths in a repository to the people who are supposed to understand them, and automatically pulls those people into review when a change touches their area. It is a proxy for blast radius built entirely out of social knowledge: the assumption is that the right reviewer will recognize, from experience, that this change reaches further than it looks. That is the tacit map described earlier, formalized into a file. It is valuable precisely because a person can catch things no static tool sees. It is also the first thing to go stale as a team turns over, and it says nothing about a change an AI agent proposes in a repository, or a service boundary, before a single human reviewer has looked at it.
The common thread across all four is worth naming plainly. Every one of them was designed around a change that a human was going to sit with for a while: write it, run it locally, wait for a CI pipeline, wait for a reviewer to have time. Each technique either infers structure from history, as test coverage and code owners do, or reconstructs it after the fact from the code itself, as static analysis and dependency graphs do, and each is bolted onto a review step that assumes there is time for a person to look closely. An agent that proposes a change in nine seconds and can be asked to open a pull request in the next nine does not remove the need for any of these techniques. It removes the slack they were quietly relying on.
Future and impact: from an inferred guess to a queryable fact
It helps to separate three different ways a blast radius claim can be produced, because they carry very different guarantees.
The first is assembled by hand: a CODEOWNERS file, a wiki page, a runbook someone wrote after the last incident. This is accurate on the day someone writes it and decays from that moment on, because nothing forces it to track the actual code as the actual code changes.
The second is inferred by the model in the course of doing the work, which is what happens by default whenever an agent reasons about the effect of its own change using only what is in its context window. This is not a smaller version of the first problem. It is a different kind of answer, because the model is not consulting a record of the system, however stale. It is guessing, fluently and in the same confident register it uses for everything else, from a partial view it cannot see the edges of. The guardrails that responsible teams put around agentic systems exist for exactly this reason: probabilistic reasoning fails quietly, so the parts of a system that actually have to hold need a check that does not depend on the model having judged correctly in the first place.
The third is computed: something parses the real codebase, not a description of it, builds the actual call and dependency graph, and answers what depends on this as a query against that structure rather than a guess about it. That answer changes the moment the code changes, because it is derived from the code, not written about the code by someone who will eventually stop updating it. This is the difference between a blast radius reconstructed during an incident review, after the damage already told you where it was, and a blast radius checked before the change ships, when it still costs nothing to change course.
Spiderbrain, built by Perform Digital, is one implementation of that third approach. It parses a codebase into a deterministic dependency graph, the same input producing the same graph every time, a property the product verifies with roughly 350 automated checks on every release. Spiderbrain exposes blast radius analysis over the Model Context Protocol to coding assistants such as Claude, Claude Code, and Cursor, and through a command-line npx spiderbrain impact query, walking that graph to show what a proposed change is likely to affect before it ships, rather than reconstructing the answer afterward from an incident. Parsing itself runs locally on the developer's own machine; only a source-free map of structure and scores, not the underlying source, goes to Spiderbrain's EU-based servers for scoring. More on how that graph is built and kept current is in the deterministic context graph behind it.
None of this makes a change immune to breaking something. A graph is only as good as its coverage of real dependency, and dynamic behavior, configuration-driven wiring, and anything resolved only at runtime will always be harder to capture than a static call. What a live, computed graph changes is the default answer to a simple question. Right now the default answer to what does this touch is either a document someone wrote a while ago or a guess assembled from whatever an agent happened to have open. Neither of those was built for a workflow where a plausible diff can exist before anyone, human or otherwise, has had time to check it against the rest of the system. The fix was never going to be asking agents to slow down. It is giving whatever writes the change, human or agent, a real answer to what depends on this before that answer has to be relearned in production.
Council summary
This post argues that blast radius, the set of everything downstream of a code change that could break because of it, has always been a harder problem than writing the change itself, and that AI-assisted development has widened the gap rather than closed it. Its central move is separating three ways a blast radius claim gets produced: assembled by hand and left to go stale, inferred by a model from whatever fits in its context window, and computed as a live query against the codebase's actual structure, arguing that only the third holds up once an agent can generate a plausible diff faster than any human map of the system can be checked against it. It grounds the AI-specific risk in named research rather than assertion, including Stanford's finding that AI-assisted code was less secure while its authors were more confident in it, GitClear's data on rising duplication and falling refactoring across 211 million changed lines, and the Science and Microsoft figures showing AI already produces roughly a third of new code at some organizations. It gives equal, honest treatment to the tools already in use, static analysis, monorepo-scale dependency graphs, test impact analysis, and code owners, noting that every one of them was built around a human having time to sit with a change, an assumption agent-speed development quietly removes. The reader's takeaway: the question is no longer how fast a change was produced, but whether anyone, or anything, actually knows what it touches before it ships.
Comments