My code graph does not need a new name

“Graph engineering” is three weeks old and already means four different things. That is not a new idea arriving. That is a word doing the work an idea should be doing.

The thing underneath it already has a name, and I have been running one across my own repositories for weeks before the term existed.

Where the word came from

On 18 July 2026, Peter Steinberger asked in public whether we had moved from loops to graphs. Hours later Hamel Husain posted “Loop Engineering Is Dead,” and the term took off from there. Within days, reviewers found no standard definition and no benchmark against loop engineering. Worse, the word collides across four unrelated meanings depending on who is using it: a control graph for agent orchestration, a knowledge graph over a codebase, an execution trace, an improvement graph for iterative refinement. A term that means four things routes no decisions. It is a vibe, not a spec.

The thing already has a name

Strip the branding off and what people mean by the code-understanding version is a code knowledge graph. GraphRAG is the retrieval-augmented flavour of it. Aider calls its own version a repo map. None of this is new, and pretending otherwise is the actual problem with the coinage: a fresh label makes something that already has three years of prior art look like it needs to be reinvented.

What mine actually is

I run one across my own workspace on a schedule: 15,254 nodes and 20,861 edges in the merged tree graph, spanning twelve project repositories, each project’s graph pinned to the commit it was built from. Nine of the twelve are wired up as MCP servers, so an agent working in one of my repos queries the graph directly instead of grepping the tree and hoping the string it searched for is the one that matters.

Why deterministic wins

Here is the part worth being precise about, because a January 2026 paper actually tested it rather than asserted it. Chinthareddy’s “Reliable Graph-RAG for Codebases” (arXiv:2601.08773) benchmarks three retrieval pipelines on real Java codebases: vector search alone, a knowledge graph built by an LLM reading the code, and a knowledge graph built deterministically from the code’s own syntax tree. On one benchmark repository, the LLM-built graph skipped 377 files outright, quietly, with no error. The deterministic graph did not. On correctness for multi-step questions about how a codebase actually fits together, the deterministic graph won.

My code graph is built the deterministic way. A tool called Tree-sitter reads the source directly and derives the graph from its structure; no model sits in that step and no API key is needed for it. I want to be exact about the boundary of that claim, because the honest version is more useful than the impressive one: the docs and notes living in the same corpus, my project READMEs and planning files, do go through an LLM for semantic extraction, and that half of the graph is not deterministic. I am not going to describe the whole thing as reliable when only part of it earns that word.

The mechanism

Grep answers “where does this string appear.” A graph answers “what breaks if I change this.” That is the entire argument for building one, and it is also the entire cost of one: a graph is correct for exactly as long as the commit it was pinned to, and then it is a precise, confident description of a repository that no longer exists. Nothing about a graph erases the need to know when it was last built.

Where it breaks

Four of the twelve project graphs are not wired up as MCP servers yet. One output folder nested itself inside its own output by a build mistake, and nobody noticed for weeks, which says something about how often anyone actually looks inside graphify-out/. And none of this helps until a repository is big enough to get lost in. My smallest graph, for a parked side project, has 50 nodes. A graph there is a solution with no problem attached to it.

The method, and where it is weak

Every number in this piece was checked live on 23 August 2026, not carried over from when I first built the graphs: the 15,254/20,861 count came from the graph’s own stats tool, the twelve-repo and nine-server counts came from listing the actual output folders and the actual servers running, and the 50-node and nested-folder claims were re-checked on disk rather than remembered. The arXiv paper’s abstract was read directly, not summarised secondhand.

Two honest limits. I did not re-run Chinthareddy’s benchmark myself; I am trusting a peer-reviewable, single-author paper’s own numbers on Java codebases that are not mine, and treating that as evidence rather than proof for my own, differently-shaped repositories. And the semantic half of my graph, the part built from documents rather than code, inherits every limit of LLM extraction that the paper found in its own comparison: it is the less reliable half, by the same mechanism, and I have not measured how much less.

The reframe

The naming fight was never really about graphs. It is that nobody wants to admit the thing they are excited about is a knowledge graph with better plumbing, built on a technique that already had a name before the plumbing got interesting.

Written with AI as a tool: research, structure and drafting with Claude; the judgment and every claim are mine.

Source post: Post | LinkedIn