The blast radius of AI code changes

The blast radius of AI code changes is everything a change can affect beyond the task it was made for: other features that call the same code, other tasks that were already accepted, and the evidence those acceptances rested on. It matters more with agents than with people because an agent asked to fix one thing will often take the shortest path, which is frequently a shared helper, and then verify only the thing it was asked to fix. The result is a passing check next to a quiet breakage somewhere else. You cannot shrink the radius after the fact, but you can measure it: find what depends on the changed code, rerun those checks, and compare what you found with what your project records say depends on it. The gap between the two is usually where the regression hides. This page walks through a small probe of exactly that gap and what a reviewer should do about it.

Why agent changes reach further than the task

A task description draws a boundary around intent: make checkout truncate fractional cents. It does not draw a boundary around code. If the rounding lives in a shared helper, the cleanest diff is a one-line change to that helper, and an agent aiming for a clean, passing diff will make it.

Three things then widen the radius. First, the agent's verification is shaped by the task, so it runs the checkout test and stops. Second, other consumers of the helper were finished earlier, often in a different session, and nothing in the current context mentions them. Third, the change is semantic rather than structural: the function keeps its name, signature and return type, so no compiler, type checker or import error points at the other callers.

None of this needs a careless agent. A careful person with the same narrow brief and the same narrow test would do the same thing. The difference is volume: agents make many such changes quickly, and each one is reviewed against its own task. That is why blast radius belongs in review as a separate question, asked every time shared code changes: who else calls this, and what did they expect it to do?

A worked example: one rounding helper, four cards

On October 30, 2026, a regression probe was run against a BRAIN FLUID development build (RC2) using a disposable four-card project. ENG-1, a shared cents() helper, was DONE. ENG-2, checkout must truncate fractional cents, was TODO and depended on ENG-1. ENG-3, CSV export keeps nearest-cent rounding, was DONE, but its import of the helper was deliberately not declared as a relationship. ENG-4, deliver the app, depended on ENG-2 and ENG-3.

A scripted change then turned round(value * 100) into int(value * 100). This was a test stimulus: the edit and every report were written by the test script, not by BRAIN FLUID and not by a live agent.

The results split cleanly. The checkout check total(1.239) == 123 passed, which is exactly what ENG-2 asked for. The export check row(1.235) == "124" failed with "123", because the exporter relied on the old rounding. One line, two features, one green check and one red one. A reviewer who looked only at the task's own test would have accepted a change that broke a feature already marked finished.

What the declared impact query found, and what it missed

The probe then asked the question a reviewer would ask: which work depends on the changed source? The declared-relationship impact query walks recorded links from a changed source through its evidence and claims to the cards that depend on it [D6]. It nominated ENG-2 and ENG-4. It did not nominate ENG-3, the exporter that actually broke, because the import connecting ENG-3 to the helper had never been recorded. It did report its coverage as incomplete rather than presenting two cards as the full answer [D6].

Two other observations matter. Evidence recorded for the changed source flipped from current to stale, so the record showed that something previously checked no longer matched its files [C6]. And nothing else happened by itself: no regression card was created, ENG-3 was not reopened and nothing concluded that the helper change caused the export failure. The query runs on request and follows declared links only [D6].

The lesson is general. Any impact analysis built on declared relationships is exactly as complete as the declarations. A missing link does not produce an error; it produces a shorter list. A short impact list should never be read as a small blast radius.

What a reviewer should do when shared code changes

Treat any change to a shared module as the trigger for a short, fixed routine.

First, name the changed symbols. For each function or constant whose behavior changed, write one sentence on old and new behavior: rounded to the nearest cent, now truncates.

Second, find consumers from the code, not from the task list. Search for imports and call sites of each symbol, including tests, scripts and anything that reads its output in another format. Compare that list with what your tracker says depends on the module. Every consumer the code shows but the tracker does not is a missing declaration and the most likely place for a regression. Declared and inferred dependencies fail in different ways, so use both.

Third, rerun the consumers' checks, not just the task's. If a consumer has no check that would notice the change, that is a finding in itself, as covered in why narrow tests miss regressions.

Fourth, record what you found: the missing link, the failing check and a new task for the regression, linked to the change that caused it. The cross-file review workflow covers the rest of the diff.

QUESTIONS

What does blast radius mean for a code change?

It is the set of things a change can affect beyond its intended target: other features that call the changed code, tasks already accepted on the assumption that the code behaved a certain way, and the checks that proved them. A small diff can have a large blast radius when it touches a shared helper whose behavior other modules rely on.

How do I find what else an AI agent's change affects?

Start from the code. List the symbols whose behavior changed, search for every import and call site, and rerun those consumers' checks. Then compare that list with the dependencies your tracker or plan records. Consumers that appear in the code but not in the plan are the most likely place for an unnoticed regression.

Can an impact analysis tool miss affected code?

Yes. A tool that follows declared relationships misses anything nobody declared, and a tool that reads imports misses dynamic loading, configuration and data contracts. In a probe on a development build, a declared-relationship query missed an exporter whose import had not been recorded, though it did report its coverage as incomplete.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance
• What is a project management harness?

RELATED HARNESS PAGES

• My AI agent fixed one bug and broke another feature Your AI agent fixed one bug and broke another feature? Find the shared code, find its other consumers, rerun their checks and record it as linked work.
• Declared vs inferred dependencies in change-impact analysis Declared vs inferred dependencies in change-impact analysis: what task links and import graphs each catch, where each is blind, how to combine them.
• Why narrow acceptance tests miss AI regressions Why narrow acceptance tests miss AI regressions: a task's check can pass while a shared change breaks another consumer. A worked example and a fix.
• Reviewing cross-file changes made by AI agents Reviewing cross-file changes made by AI agents: check scope, read shared modules first, test interface changes and handle generated files apart.
• When a dependency changes, which approvals go stale? When a dependency changes, which approvals go stale? How evidence tied to source bytes goes stale, and what a stale flag does and does not tell you.