TL;DR

An AI‑driven code edit can pass all local checks yet explode downstream because the agent searches for similar snippets, not for the structural callers that depend on the edited file. Conventional review surfaces only the diff, not the transitive blast radius. The fix is a dependency‑aware layer that maps call‑graphs before any change is merged.

The 3 a.m. incident: a single middleware tweak that broke three services

It was Wednesday, 02:17 AM. The on‑call engineer woke to a Slack ping: “Production is returning 401 from three unrelated services.” The stack consisted of:

All four repos shared a tiny auth‑middleware utility located at shared-lib/auth-utils.js. The file exports a single helper, verifyToken(token), that validates a JWT and returns the decoded payload.

An AI coding agent (triggered from a pull‑request comment) suggested a refactor: replace the custom jwt.verify wrapper with the library’s built‑in jwt.decode for a “speed win.” After the agent ran the repository’s unit test suite where all 317 tests passed, the PR was merged. Two days later, the three downstream services started throwing TokenExpiredError at runtime, despite none of their source files appearing in the diff.

    

      
1
      
// shared-lib/auth-utils.js: before the AI edit
    
  
    

      
2
      
const jwt = require('jsonwebtoken');
    
  
    

      
3
      
 
    
  
    

      
4
      
function verifyToken(token) {
    
  
    

      
5
      
  // Strict verification: signature + expiration
    
  
    

      
6
      
  return jwt.verify(token, process.env.JWT_SECRET);
    
  
    

      
7
      
}
    
  
    

      
8
      
 
    
  
    

      
9
      
module.exports = { verifyToken };
    
  

    

      
1
      
// shared-lib/auth-utils.js: after the AI edit
    
  
    

      
2
      
const jwt = require('jsonwebtoken');
    
  
    

      
3
      
 
    
  
    

      
4
      
function verifyToken(token) {
    
  
    

      
5
      
  // The agent replaced verify() with decode()
    
  
    

      
6
      
  // (decode does NOT validate signature or exp)
    
  
    

      
7
      
  return jwt.decode(token);
    
  
    

      
8
      
}
    
  
    

      
9
      
 
    
  
    

      
10
      
module.exports = { verifyToken };
    
  

The change is three lines, each of which passes the local test harness because the suite only checks that a well‑formed token yields a payload. The real production traffic includes expired or tampered tokens that now slip through, causing downstream services to reject the request later in the pipeline. The breakage is invisible in the diff, yet it is the direct cause of the outage.

Why this keeps happening: agents retrieve “similar” code, not “connected” code

Most production‑grade AI coding agents operate in two stages:

1. Context retrieval: they embed every file in the repo (or a large chunk of the codebase) into a high‑dimensional vector space.
2. Similarity search: given a natural‑language prompt, they pull the k nearest vectors and feed those snippets to the LLM.

Embedding similarity is low-cost and works well for local refactors (e.g., “rename this variable”). It fails when the impact of a change is defined by structural connections rather than textual likeness. The auth‑middleware edit above is a perfect illustration: the function name verifyToken appears in many places, but the call‑graph that links it to downstream services lives in separate repos that never surface in the top‑k similar snippets.

Because the retrieval step never surfaces those dependent modules, the LLM never “sees” the downstream effect when it generates the edit. The model therefore assumes the change is safe, and the downstream breakage only appears later, when the edited code is executed in a different context.

The core distinction: similarity vs. structure

Similarity graph

Nodes = code fragments (files, functions, classes).
Edges = cosine similarity above a threshold in embedding space.

• Properties: dense, fuzzy, symmetric.
• Use case: surface “examples that look like this” for autocomplete or documentation generation.

Structure (dependency) graph

Nodes = same code fragments.
Edges = static or dynamic analysis links (import, function call, data flow).

• Properties: directed, often sparse, reflects execution order.
• Use case: impact analysis, build tooling, runtime tracing.

    

      
1
      
Similarity graph          Structure graph
    
  
    

      
2
      
   (A) ───► (B)               (A) ──► (B)
    
  
    

      
3
      
    ▲      ▲                 ▲          ▼
    
  
    

      
4
      
    │      │                 │          │
    
  
    

      
5
      
   (C) ◄─── (D)               (C) ◄───── (D)
    
  

In the similarity graph, auth-utils.js may be close to files that also import jsonwebtoken, regardless of whether they call verifyToken. In the structure graph, there is a directed edge from each downstream service’s route handler to verifyToken. That edge is the only path that conveys the blast radius.

The series will repeatedly return to this distinction because every failure mode we discuss can be traced to a missing edge in the structure graph.

Why conventional code review doesn’t catch it

A typical pull‑request review looks like:

1. Diff view: shows added/removed lines.
2. File list: limited to files touched by the commit.
3. Static analysis warnings: confined to the changed files.

What the reviewer does not see:

In the auth‑middleware example, the diff is three lines, the reviewer can verify that the LLM didn’t introduce a syntax error, and the CI pipeline reports green. The reviewer never sees:

• payments/routes/pay.js → auth-utils.verifyToken
• profile/routes/profile.js → auth-utils.verifyToken
• analytics/collectors/event.js → auth-utils.verifyToken

Because those edges are outside the PR, the reviewer cannot reason about the downstream impact. The result is a false sense of safety that matches the observed pattern of “the change looks harmless, but production blows up.”

What actually has to change: a call‑graph‑aware guard layer

To stop the blind‑spot, the edit pipeline needs an intermediary that:

1. Builds a live dependency graph for the entire monorepo (or federated set of repos).
2. Maps the proposed edit to the set of downstream nodes that would be affected.
3. Fails the edit (or flags it) if the blast radius exceeds a policy threshold.

Minimal architecture

Pseudocode sketch

    

      
1
      
// 1. Build graph (run periodically or on each PR)
    
  
    

      
2
      
const graph = await buildCallGraph(repoRoot);
    
  
    

      
3
      
 
    
  
    

      
4
      
// 2. Identify edited symbols
    
  
    

      
5
      
const edited = parseDiff(diff).symbols; // e.g. ['verifyToken']
    
  
    

      
6
      
 
    
  
    

      
7
      
// 3. Compute downstream impact
    
  
    

      
8
      
const impacted = new Set<string>();
    
  
    

      
9
      
for (const sym of edited) {
    
  
    

      
10
      
  const downstream = traverseDownstream(graph, sym);
    
  
    

      
11
      
  downstream.forEach(node => impacted.add(node.filePath));
    
  
    

      
12
      
}
    
  
    

      
13
      
 
    
  
    

      
14
      
// 4. Enforce policy
    
  
    

      
15
      
if (impacted.size > MAX_IMPACT) {
    
  
    

      
16
      
  throw new Error(`Edit affects ${impacted.size} files: exceeds policy`);
    
  
    

      
17
      
}
    
  

The key point is the guard runs before the edit is merged. The AI agent still generates the change, but the pipeline refuses to ship it unless the impact is explicitly acknowledged. This turns an accidental blast‑radius event into a visible risk that can be triaged.

CodeFundi: mapping blast radius before the edit ships

CodeFundi provides the missing dependency layer out of the box. It continuously indexes a repository’s call‑graph, then, on every PR, returns a blast‑radius report that lists every downstream file, service, and data‑flow path that would be touched by the proposed change. The report can be attached to the PR, used as a gating condition in CI, or fed back to the AI agent so it can rewrite its suggestion with the full impact in mind.

FAQ

Why does my AI coding assistant break unrelated files?
Because the assistant’s retrieval step is based on embedding similarity, which does not capture the call‑graph edges that connect the edited symbol to downstream code. The assistant never “sees” the dependent files, so it can’t reason about the downstream effect.

Do Cursor and Copilot understand code dependencies?
Both tools excel at surface‑level pattern matching and generate edits based on textual similarity. They do not natively perform static call‑graph analysis, so they share the same blind spot described above.

What is blast radius in software engineering?
Blast radius is the set of code locations (files, functions, services) that will be affected when a particular change is deployed. It is a structural property derived from the dependency graph, not a measure of how many lines were edited.

Next step: Curious how large a blast radius a single edit can have in your own codebase? Try the live demo and map your own repo's blast radius.