Graphify: is a knowledge graph of your codebase worth it?

Every AI coding session starts the same way. The assistant greps, opens files, greps again, and slowly rebuilds a picture of the project that it already built yesterday and threw away. Graphify is one of the most popular attempts to fix that: build a map of the project once, then let the assistant query the map instead of rereading the code.

It became one of the fastest growing AI tools of the year, so I wanted a clear answer to a simple question: is it actually worth adding to my workflow?

Short version: yes for documents and notes, much less for day to day code questions. Here is why.

Where Graphify comes from

On April 1, 2026, Andrej Karpathy described his personal knowledge workflow: dump papers, notes and screenshots into a folder, let an LLM compile them into a wiki, and browse it in Obsidian. The idea spread fast, and within about two days Safi Shamsi shipped Graphify, a tool that takes the same idea further by turning a folder into a real graph instead of a flat wiki.

Since then the project has moved under Graphify Labs, joined Y Combinator, and gathered tens of thousands of GitHub stars.

What it actually does

Graphify is a Python package (graphifyy on PyPI, with two y’s) plus a /graphify skill for your AI assistant and an MCP server.

uv tool install graphifyy   # or: pipx install graphifyy
graphify install            # registers the skill with your assistant

Then, inside Claude Code, Cursor, Codex, Gemini CLI or one of the other supported assistants:

/graphify .

Under the hood it builds the graph in two layers:

Code is parsed locally with Tree-sitter. Functions, classes, imports, calls and inheritance come straight from the syntax tree. No LLM, no API key, and the same input always gives the same graph.
Everything else (Markdown, comments, PDFs, diagrams, images, even video transcripts) goes through an LLM that extracts concepts and the relationships between them.

The result is merged into a single graph, clustered into communities with the Leiden algorithm, and written to a graphify-out/ folder:

graph.html: an interactive graph you can open in a browser, click through and filter by community.
GRAPH_REPORT.md: a readable summary with the main communities, the most connected nodes (“god nodes”), surprising connections and group relationships (“hyperedges”).
graph.json: the full graph, which the CLI and the MCP server query.

Once it exists, you can ask it questions directly:

graphify query "how is authentication handled"
graphify path "Router" "Database"
graphify explain "AuthMiddleware"

Two design choices stand out. First, there are no embeddings and no vector store. Answers come from walking the graph, which means you can ask how A connects to B, something vector search can’t really do. Second, every edge is tagged as EXTRACTED (read directly from the source) or INFERRED (guessed by the model). Very few AI tools tell you which of their claims are facts and which are guesses. This one does.

The promise: fewer tokens, better context

The pitch is about context. Instead of an assistant reading a dozen files to answer “how does auth work here?”, it reads a compact report or queries the graph and gets the relevant nodes in a few hundred tokens.

The project’s docs cite a 52 file corpus where a query drops from roughly 123k tokens of raw files to about 1.7k tokens against the graph. That is a striking number, but it comes from one specific corpus. Treat it as a direction, not a guarantee.

What happens on a real codebase

The most useful independent test I found is Praveen Vijayan’s write-up. He ran Graphify against plain ripgrep on a real TypeScript monorepo of about 600 files under active development, and his conclusion is that Graphify is really two products shipped as one.

The build artifacts are genuinely good. The report grouped around a hundred planning documents into coherent streams of work, including a chain of related bug fixes written weeks apart that nobody had ever linked together. Community labels made a better table of contents than the folder tree. Import cycle detection came for free. None of this is something grep can give you.

The query interface is weak on code. On targeted questions, rg won every time: faster, far fewer tokens, and almost entirely on topic, while the graph query returned large lists of mostly unrelated nodes. The root cause is structural. Files that everything imports (barrel files, shared utils, the app factory) become giant hubs, and a two hop traversal from almost anywhere reaches a large share of the codebase.

Stale graphs are dangerous. After a single day of normal work, a renamed function was still reported by graphify explain, with its old line number and its relationships, all labeled EXTRACTED. A wrong answer stamped with the highest confidence label is worse than no answer, because it removes the reflex to go and check.

Other reviews point in the same direction. The convenient “everything stays local” story only holds for code: documents, PDFs and images are sent to an external LLM backend for extraction. And the interactive visualization becomes hard to use past a few thousand nodes.

So, is it worth it?

It depends almost entirely on what you point it at.

Good fit:

Large piles of prose that nobody has cross linked: notes, ADRs, RFCs, postmortems, planning docs.
Legacy codebases with little or no documentation, where any map beats no map.
A first pass on an unfamiliar repo, to get oriented before you dive in.
Mixed material (papers, transcripts, screenshots) where there is no AST or language server to rely on.

Poor fit:

Precise questions like “where is X defined” or “what calls Y”. That is what rg and your editor’s language server are for, and they are exact and never stale.
Projects with a strong documentation culture. If your architecture rules are already written down, the graph is an inferred, slightly outdated copy of them.
Fast moving code without an automatic refresh. A graph that is wrong but confident is a liability.

A note for Rails developers

I write mostly Ruby on Rails, and I suspect Rails is a tricky case for Graphify. Rails code relies on Zeitwerk autoloading rather than explicit require statements, so the import edges a Tree-sitter based tool depends on may be sparse, and much of the wiring lives in conventions (naming, associations, callbacks) rather than in syntax. I have not measured this yet, so take it as a hypothesis, but I would not expect the code graph of a Rails app to be as rich as a TypeScript or Python one.

How I would use it

If you want to try it, this is the setup that keeps the good half and avoids the bad half:

Scope it. Run it on docs/, your notes vault or your planning folder first, not the whole monorepo. That is where the value is, and it keeps the LLM extraction cost down.
Read the report, don’t just query it. GRAPH_REPORT.md is the real deliverable. Read it once end to end.
Use queries to find entry points, not answers. Look at which nodes a query starts from, then switch to rg and open the files yourself.
Keep the graph fresh. graphify update . re-extracts code without LLM calls, so it is cheap to run in a post-commit hook.
Check for drift before trusting a code answer. The graph records the commit it was built from in graph.json. A quick check before querying is enough:

built=$(jq -r .built_at_commit graphify-out/graph.json)
echo "graph is $(git rev-list --count "$built"..HEAD) commits behind HEAD"

Never take INFERRED at face value. The tags are only useful if you actually look at them.

Conclusion

Graphify points at a real problem: AI assistants have no memory of how a project fits together. The ideas behind it are solid, especially deterministic code parsing and the honest EXTRACTED / INFERRED labels.

But in practice it is an excellent tool for documents and a mediocre one for code. Point it at your notes and your docs, keep grep for your code, and treat whatever it tells you about a function as a hint until you have checked it.