Shreshth Rajan, April 2026. · visdep.com
Grep can't find the shape of a graph by searching its vertices. That's why I think the retrieval argument of the last year is only half right.
In summer 2024 I thought the thing most slowing engineering down at big companies was that nobody could hand over their mental model of the codebase. New engineers spend weeks building one. Senior engineers have one and can't transfer it. I tried a few formats on friends and a graph was the only one that stuck, so I built Visdep. It's free now.
Claude Code dropped prebuilt indexes for grep. GrepRAG beat graph methods by 7 to 15% on completion benchmarks. Cursor ships chunking, a vector database and a reranker. Prebuilt indexes are losing to search. That holds for writing code, and not for reading it.
Completing code needs the smallest context that produces the next line, and grep is good at exactly that: fast, exact, and cheap to run again. If a query misses, the agent runs another; a prebuilt context set that missed can't be fixed without redoing everything.
Reading code is a different request. You want the shape of the thing: what calls what, which layers exist, what has to stay true.
Bigger context windows don't fix that. They turn a capacity problem into a navigation problem. Anthropic calls it context rot: the fuller the window, the worse the model gets at using any one thing in it. The Navigation Paradox paper found that with the whole window available, files that were architecturally far away never got loaded at all. Exposing the dependency edges as a tool fixed it.
A senior engineer carries a graph of the system: this layer calls that one, this class holds state for those methods, this module is hot. They keep it updated as the code changes and use it to explain, debug, and onboard people.
Most AI systems hand over an answer and the structure in it dissolves when the chat ends. DeepWiki and Codemaps have the right shape because they leave something behind. What none of them do is make it writable. You can read it, share it, and feed it to a model, but editing it doesn't edit the code. I want the graph as the interface and the source of truth at once, where clicking a citation takes you to a node and editing a node edits the file.
Visdep is the small version. The graph is the interface, at method level rather than file level, and the nodes an answer used light up on it. Everything underneath is standard retrieval. Who does the navigating matters: people keep their own model of a system while they're driving it, and lose it when they aren't.
The edges everyone uses are imports, inheritance and parsed calls. They're the cheapest to compute and say the least. Finding files that change together in git history is twenty years old; Zimmermann did it in 2004. Nobody has combined that with runtime and CI data into one graph with learned weights: functions that show up in the same stack traces, tests that fail together, files edited in the same commits, modules that touch the same objects, code touched during the same incident. Every company already has this in traces, CI logs, git history and postmortems. New code has no history, so it adds to the static graph rather than replacing it.
The benchmark I want out of that is blast radius. Given a diff, name the tests that will fail, the modules that need changing, and the closest past incident. The ground truth is already in CI logs. SWE-bench Verified is saturating near 88%, while SWE-EVO puts GPT-5.4 at 25% on changes spanning 21 files on average. That gap is where understanding lives.
Code already lives in parse trees, modules, files, commits, and now embedding chunks, each built for a different reader, and Visdep adds one more. Compilers have understood the structure of code since the 1950s, and here we are running retrieval over what was already a parse tree. The structure was never missing; we keep rediscovering it one layer at a time. The layer worth building next is the one that reads the graph off how the code actually runs, not off how it parses.