An impact graph for code that agents write

A coding agent opens a pull request that changes one stored procedure. The diff is twelve lines. The description says "optimize product query." Everything compiles.

What did it actually touch? If you've worked on a large e-commerce codebase, you know the honest answer is "probably the category page, maybe search, possibly a scheduled export nobody remembers." A person who has lived in the code for years can guess well. An agent that wrote the change twenty seconds ago can't, and neither can the reviewer who has forty other PRs open.

So we built something to answer that question from the diff, without guessing.

What's in the graph

The impact graph is a plain directed graph. Every edge means the same thing: A depends on B. If B changes, A might break.

The nodes come in a few kinds:

• Code files, split by role: data entities, settings, services, SQL procedures, controllers, views, JavaScript, scheduled jobs.
• Routes, the URLs a browser can actually hit.
• Coverage items from the coverage universe: page types, API surfaces, business rules.
• Tests, the checks that guard those items.

Most edges come from static analysis. A service calls a procedure, a controller injects a service, a view renders a model, a route maps to a controller action. The last hops, from routes to page types to business rules to tests, come from the coverage map we already maintain.

Walking the diff

Given a diff, we find the changed files, then walk the graph backward to everything that depends on them. The result is three lists: affected pages, affected rules, affected tests.

The part we care about most is that every result comes with the path that produced it. For that stored procedure, one line of the output looks like this:

ProductLoadAllPaged.sql → ProductService → CatalogModelFactory → CatalogController → Category page → price sort rule

That one line tells a reviewer a lot. The change can affect how the category page sorts by price, and here's exactly why the system thinks so. If the path looks wrong, a person can see where it went wrong. If it looks right, the planner knows to run the price sort checks first and send an explorer to the category page instead of wandering the homepage.

We considered having a model read the diff and just tell us what might be affected. It would sound confident and be impossible to audit. The graph is boring by comparison, and that's the point. The same diff gives the same answer every time, and you can argue with each hop.

Where it falls short

Static analysis only sees what's written in code it can parse. Two blind spots matter in practice.

First, it can't see inside stored procedures in any useful way. We know CatalogModelFactory calls ProductLoadAllPaged, but we don't know which columns that procedure reads, or that a change to a discount table will alter its output. A change in the database can ripple out further than the graph shows.

Second, config values. A setting like a page size or a feature flag can change behavior across half the site, and the graph sees the setting file as one node with a few readers. It has no idea which values actually matter.

Then there's the opposite problem. Some files are shared by nearly everything: a base controller, a layout view, a core settings class. Touch one of those and the walk returns most of the graph. We don't pretend otherwise. When the affected set gets that large, the answer is simply "run the whole gate," and the planner spreads exploration across the riskiest items instead of focusing it.

Why this matters more with agents

Human developers tend to make changes that match their mental model of the system. Agents make changes that match the prompt. They're often good changes. They're also happily unaware that the query they sped up feeds a sort order on a page they never opened.

Reading the diff first was already how we wanted the planner to work. The graph is what turns "read the diff" into a concrete list with reasons attached.

We haven't pointed it at a real site's codebase yet, so we don't have numbers on how often the paths are right. That's the next thing we want to find out, and we'd rather report it honestly than guess now.