Graph-derived test selection for Claude Code and Codex
Published 29/10/2026
Running the whole test suite after every agent edit is safe and slow. Running nothing is fast and reckless. The middle path is to run the tests that can actually reach the code that changed, and to work that set out from the code itself rather than from a guess.
What "graph" means here#
A graph is a list of things and the lines between them. For a codebase, the things are files and the lines are facts the code already states:
- this file imports that one;
- this function is called from over there;
- this test reaches these files, directly or through what it imports;
- this doc mentions this file.
None of that has to be drawn by hand. A small reader per language can pull it out of the source, which means the map is regenerated rather than maintained, and cannot drift from the code it describes. Think of it as a road atlas printed from satellite photos instead of from memory.
From graph to test set#
With the graph in hand, picking tests for a change is a walk:
- Start at the files the change touched.
- Follow the "reaches" lines backwards to every test that depends on them.
- Run those tests, and only those.
Two rules keep it honest:
- No edges is not no risk. A file no test reaches gets a small, configured critical set run against it, never silence and never the whole suite.
- Some paths deserve everything. Code where a mistake is expensive (payments, auth, the deploy path) can be marked proof-grade, so every test that reaches it always runs.
Why it matters for agents in particular#
An agent that runs the full suite fills its context with thousands of lines of passing output, then pays for every one of those tokens again on each later turn while they sit in the conversation. Picking the right tests is a speed win for a person; for an agent it is a speed win and a context win.
The same graph pays off elsewhere. Before an agent edits a file for the first time, it can be told who calls the file, which tests reach it and which decisions govern it, in a briefing of a hundred tokens or so, instead of spending several turns reading around to find out.
Where ADE fits#
Atlas ADE generates graph.json from your code with ade graph (Python and TypeScript/JavaScript readers are built in), uses it to pick the tests at the test stage of every change, and feeds the same graph to the first-edit briefing. ade graph --check fails in CI when the committed copy is stale. See How it flies for the whole loop.