Graphify: the graph that grounds every change
When an agent changes a codebase it didn't write, the riskiest thing it can do is guess at the structure. Graphify is how we take the guessing out: we turn the whole codebase into a graph the agents read before they touch anything.
The problem: editing blind
Most AI coding tools work a file at a time. The agent opens a file, reads what's in front of it, and makes a change. That's fine for a toy. In a real codebase it means the agent can't see who calls the function it's editing, what depends on the type it's renaming, or where a request actually ends up. So it infers — and at scale, inference breaks things nobody asked it to touch.
We saw this directly: an architecture surface that was meant to show the system sat empty for a while because nothing was feeding it a real model of the code. The agents were reasoning about structure they couldn't actually see.
What graphify is
Graphify is a producer that parses your codebase into a graph. The symbols — functions, modules, types — become nodes; the relationships between them — calls, imports, references — become edges. On a mid-sized project that's a few hundred files turning into a couple of thousand connected nodes. It's captured once and kept current as the code changes, so the agents don't read the code as a pile of text — they read it as a structure they can ask questions of.
Why a graph, and not search
Search finds strings. A graph answers questions: what calls this? what breaks if I change this signature? where does this flow actually go? Those are exactly the questions you have to answer before a safe change — and they're about structure, not text.
The short version: grep tells you where a word appears. A graph tells you what depends on it.
How the agents use it
Before an agent makes a change, it grounds itself in the graph — the real callers, the real dependencies, the real shape of the thing it's about to edit. The change is proposed against structure it can see, not an assumption it made from one open file.
The same graph also draws the architecture map you look at. So the picture on your screen and the model the agents reason over are the same thing — there's no second diagram to drift out of date.
Why we think it matters
Two reasons. First, far fewer "it fixed X and quietly broke Y" moments, because the agent knew what Y was. Second, it's what lets the map stay honest: the view you trust and the model the agents use come from one source, re-indexed as the code changes.
Keeping that graph correlated to the code — re-indexing on every build instead of letting it fall behind — is the part that takes discipline. So we treat the producer as a first-class part of the system, not a nice-to-have. A map is only worth trusting if it's generated from what's actually there.