Build1 distinct publisher3 min readPublished
Swapping similarity search for a dependency graph took one engineer's review context from 150,000 tokens to 18,000. The saving is file count, not compression, so it holds only where the change sits in a sparse corner of the tree.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Divide the two context figures by their file counts. Fifty files for about 150,000 tokens is roughly 3,000 tokens per file [9]. Seven files for about 18,000 is roughly 2,570 [10]. The per-file cost barely moved. The graph fetched 43 fewer files, and that is the whole 88 percent [1][2]. Which makes the token result a statement about one repository's shape: how many files sit within two hops of the one you edited. Where an auth module is imported by two hundred others, a two-hop blast radius returns hundreds of files and the six-figure context comes straight back. That number depends on sparsity around the change, and sparsity is a fact about this repository's shape, not a property of graphs in general.
The audit log bug is the stronger argument anyway. The path the graph walked was auth.py --emits--> login_event --consumed-by--> audit_log.py, three hops away, with no import of auth.py and no string match on "auth" anywhere in the file [14]. For that path to exist, a build step had to resolve a publish and a subscribe to the same topic. The writeup gives the edge list, imports, calls, inheritance, decorates, listens-to and tested-by, and a three-command install [7][6]. It does not show how listens-to gets derived, and that is the first number I would ask for: edge recall on your own bus. Constant topic strings and decorator registration are tractable. That guarantee thins out once topics get assembled at runtime, handlers get wired by a container, or subscribers get named in a YAML file the parser never opens, and in those cases the graph ends up looking complete while it keeps grep's blind spot, just dressed in nicer formatting.
The decorator case shows the other side of the ledger. A backoff parameter with an unchanged default looked caller-safe and passed the unit tests [15]. Similarity retrieval returned about a dozen files that imported the decorator; the graph returned 31, of which 19 were additions, which puts the implied similarity count at exactly 12 [16][3]. Nineteen extra files went into context, and something has to read them. The graph put the payments webhook handler in front of the model; the judgement about the timeout still came from reading it [17]. Recall is what the graph buys.
The protocol layer is the least interesting part here, which is meant as a compliment. A standard tool interface, shipped by Anthropic in late 2024 and supported by Claude Code, Cursor, Windsurf, Zed and VS Code, means the retrieval backend is swappable behind a stable call [5].
If I were adopting this, the acceptance test would be a replay. Take last quarter's incidents. For each, ask whether a structural path existed between the merged diff and the file that actually broke, and count the ones where it did. That number is yours, and it is the only version of three-bugs-in-a-week that tells you anything about your codebase [3].
Ranked by verification strength, evidence, and original report placement.
The author's prior AI code review setup for about a year was: AI gets a PR, greps for related code, reads many files, and says "looks fine"; it mostly worked until bugs that did not show up in grep started shipping.
The author asserts the failure was retrieval rather than the model: vector search and keyword grep find files that mention auth.py but are poor at finding files that depend on it through three import hops, an event bus and a decorator.
The author rewired the retrieval layer with a code knowledge graph plugged in through MCP, and reports three bugs surfaced in the first week that vector search had been missing.
Vector search retrieves by semantic similarity ("find code about authentication" returns auth.py, login.py, password_validator.py), while knowledge graphs retrieve by structural relationship ("what depends on auth.py?" returns the call graph); the author says both are valid and answer different questions.
Before the graph, a PR touching auth.py plus one file gave the reviewer context of about 50 related files found by grepping for "auth", at roughly 150,000 tokens.
After the graph, the same PR diff gave reviewer context of 7 files from blast_radius("auth.py", hops=2), at roughly 18,000 tokens.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
science
OX Security says MCP command execution is a design choice, so server owners own the risk1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
255 tools, 71,929 tokens: the standing charge hidden in your MCP config1 distinct publisher
build
One MCP command, three JSON shapes, and a failure mode that never errors1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One engineer's notebook, checked against itself
Every number in this story — 150,000 tokens, 7 files, 90 minutes to a production fire, 800ms past a webhook timeout — comes from one dev.to post by a single practitioner, with no repository link, no incident record and no second voice anywhere in our coverage. The arithmetic is internally consistent, which is the only verification on offer and is not the same as corroboration.
Broad protocol, tool of one
Two different adoption pictures sit in the same post. MCP itself is described as running in five editors with a registry of hundreds of servers, which would be substantial if the post cited any of it. The graph tool has one disclosed user: this author, this repository, this week. Nothing indicates the team around him adopted it, and no second install appears anywhere.
The 88 percent is fewer files, not smaller ones
Divide the tokens by the files and the compression story evaporates: about 3,000 tokens per file before, about 2,570 after. The saving is 43 files not retrieved, which means it survives only where the changed file sits in a sparse corner of the dependency tree — precisely the condition the single worked example satisfies. The post's own two caveats, that graphs are not cheap to walk and stale snapshots ship bugs, are stated and then left unmeasured, and the bug narratives are strong enough that a reader may not notice the second one is also the objection.
Undisclosed and uncheckable
The post promotes a named tool with copy-paste install commands and never says whether the author wrote it, contributes to it or benefits from it. That silence could mean anything, and with no second publisher and no repository in our coverage there is nothing to test it against — so we do not score it rather than guess at motive.
Mechanism plausible, numbers unaudited
Confidence splits by layer. That structural retrieval finds dependents lexical search cannot is close to definitional, and any reader can test it on their own repository this afternoon. That it takes review context from 150,000 to 18,000 tokens and catches three shipped bugs in a week is a story we have from one person, once, about one codebase.