"Code memory for coding agents" is a hot lane right now. A 49k-star code-graph tool shows up, FalkorDB is pushing GraphRAG, and the reflex is the same one we apply to everything popular: lots of stars — let's wire it in. We ran one through our radar instead. Here's the part worth keeping: not the verdict, but the axis we used to reach it.
The lane has two very different shapes
Most "memory for your agent" is a vector database: chunk the repo, embed it, retrieve by similarity. That is genuinely good at one thing — finding code that looks like other code. Paste a function, get back functions shaped like it.
But the question I actually ask every day isn't "what looks similar to this." It's:
"If I change this function, what breaks?"
Similarity can't answer that, and not by accident. The callers of a function look nothing like the function. A logging wrapper, a retry decorator, a route handler three layers up — none of them are textually similar to the body you're editing. They're connected by structure, not by surface. Answering "what breaks" is a graph traversal — walk the call edges — not a nearest-neighbour lookup in embedding space.
That's the real divide in this lane: similarity retrieval vs structural (graph) retrieval. Almost everything in the hype cycle is the former. The thing you reach for during a risky refactor is the latter.
What we did with a 49k-star tool
CodeGraph (MIT, ~49k stars, 20+ languages, auto-syncing local index, MCP server for Cursor/Claude Code/Codex) is a serious piece of work on the structural side. We evaluated it properly — read the repo, mapped its capabilities against ours.
And we deliberately did not adopt it.
Not out of not-invented-here. Our own engine, EngramGraph, already covers the core: a tree-sitter code graph where callers <fn> is a graph walk, plus a deterministic, zero-LLM index (no embeddings to drift, cheap to rebuild, same answer every run). The decision to build rather than wire in an external daemon was already made; adopting CodeGraph wholesale would have added a dependency and an architecture conflict, not a capability.
So we filed it as Assess, and wrote down the three things it's genuinely useful for — without adopting it:
- A language-coverage blueprint. CodeGraph parses 20+ languages and recognises 17+ framework routing patterns. We don't import its code; we use its parser list as a reference map for where to extend ours next.
- A benchmark method. Its 7-codebase, four-axis measurement (cost / tool-calls / tokens / latency) is a reusable yardstick template for proving a code graph actually reduces agent exploration — not a set of numbers to copy. Their absolute figures are theirs; the method travels, the numbers don't.
- An interop signal. It exposes its graph over MCP to several agents. That's market evidence that "cross-agent code-graph over MCP" is wanted — worth watching, not worth coupling to.
The point isn't the verdict
A "no" with reasons is more useful six months later than a "yes" you can't reconstruct. The lesson that outlives this particular tool:
Tool selection in a hyped lane is not a star-count comparison. It's one question — does this solve the thing I actually ask every day? For code memory, that question splits cleanly along similarity-vs-structure. Once you know which side of that line your real problem lives on, half the shiny options on the radar quietly stop being relevant.
AI disclosure: I wrote this with AI assistance for English phrasing and structure. The repo reading and the adopt/decline decision are my own — the AI did not supply the technical judgement.
Top comments (0)