💡 Originally published on devtocash.com — where this guide stays updated. I write hands-on DevOps/SRE deep-dives there weekly.
The pitch, and the question worth asking
Graphify is an open-source skill that builds a queryable knowledge graph from a codebase — code, docs, papers, diagrams — so an AI coding assistant can answer questions about a repository without stuffing the whole thing into context. That's a real problem. Every agent that touches a codebase pays for the context it reads, and what a DevOps AI agent costs to run comes down to exactly this: the tokens you re-send on every turn.
So the question isn't "is a knowledge graph a good idea." It's "does this one produce something accurate enough to trust, cheaply enough to keep running?" I installed it, pointed it at a real production repository, and measured. Everything below is from that run.
Installation: lighter than expected
The package name has a double y — the import name and the PyPI name differ from the tool name, which cost me one failed install:
python3 -m venv .venv && . .venv/bin/activate
pip install graphifyy # not "graphify" — that name doesn't exist on PyPI
That pulled graphifyy 0.9.29 plus tree-sitter with about 25 language grammars, networkx, numpy, and rapidfuzz. No model weights, no embedding service, no vector database. For a tool in the AI tooling category that is a genuinely restrained dependency tree, and it matters — it means the core extraction runs offline.
The CLI exposes a graphify install --platform claude that copies the skill into your assistant's config directory (Claude, Cursor, Codex, Aider, Gemini and a dozen others), plus a separate graphify-mcp binary if you'd rather wire it in as an MCP server — the same integration shape as a read-only Kubernetes MCP server.
The test: a real Next.js repo, measured
I ran the no-LLM extraction path against a production blog repo — 99 MDX articles, 56 TypeScript files, plus config and scripts:
graphify update /path/to/repo
The numbers, straight from /usr/bin/time -v:
| Metric | Result |
|---|---|
| Files processed | 202 (~253,000 words) |
| Graph produced | 2,718 nodes · 2,666 edges · 189 communities |
| Wall clock | 4.83 seconds |
| Peak RSS | 74.5 MB |
| API/token cost | 0 |
Seventy-four megabytes and five seconds. That's the headline, and it's the strongest thing about the tool. This runs comfortably on a 2GB VPS alongside everything else, which is not something you can say about most "AI-powered code understanding" products. The extraction is tree-sitter AST parsing, so it's deterministic and free — an LLM (Gemini, via an optional API key) is only involved if you opt into semantic extraction for docs and images.
The report labels every edge with its provenance, and on this run it was 100% EXTRACTED · 0% INFERRED · 0% AMBIGUOUS. I like that the tool distinguishes these at all. An inferred edge and a parsed edge are not the same claim, and a graph that blurs them will quietly mislead an agent that trusts it.
Where it's genuinely good: code structure
Asking it to explain the repo's central module returned exactly what I'd want an agent to see:
graphify explain "posts.ts"
Node: posts.ts
Source: src/lib/posts.ts L1
Community: posts.ts
Degree: 22
Connections (22):
<-- blog/[slug]/page.tsx [imports_from] src/app/blog/[slug]/page.tsx:L2
<-- sitemap.ts [imports_from] src/app/sitemap.ts:L2
--> getAllPosts() [contains] src/lib/posts.ts:L68
--> getRelatedPosts() [contains] src/lib/posts.ts:L105
...
Every edge carries a real file:line. I spot-checked several against the source and they were correct. For an agent, this is the difference between "I think this function is used somewhere" and a verifiable citation it can open. That's the same discipline that makes context engineering for on-call agents work: give the model a bounded, structured, checkable surface instead of a pile of text.
It also surfaced something I didn't ask for. The community-hub list included MDX filenames I didn't recognize, which turned out to be a stale articles/ directory — 20 old draft duplicates of live posts, sitting in the repo but not served by the site, because the post loader only reads content/posts. Harmless, but genuinely useful to have pointed out. A structural view catches clutter that a file listing doesn't.
Where it fell short — and why it decided things for me
Then I asked it for the path between two articles that link to each other. I verified the link exists first, with grep:
grep -o "/blog/kubernetes-rbac-deep-dive-2026" content/posts/...-imagepullbackoff-...mdx
# -> /blog/kubernetes-rbac-deep-dive-2026
graphify path "...imagepullbackoff...mdx" "kubernetes-rbac-deep-dive-2026.mdx"
# -> No path found between ... and ...
The link is unambiguously there in the prose. The graph doesn't model it. Breaking down the 2,666 edges by relation explains why:
| Relation | Count |
|---|---|
contains |
2,486 |
imports |
75 |
calls |
52 |
imports_from |
41 |
extends |
8 |
cites |
2 |
About 93% of the graph is contains — a file pointing at the symbols inside it. The genuinely relational edges (imports, calls, extends) total 176, roughly 6.6%, and every one of them is code. In this no-LLM mode the MDX files become nodes, but the markdown links between them never become edges. That's a defensible design decision — it's an AST extractor, and prose links aren't AST — but it's the exact edge type I needed.
The verdict: not for me, and that's not a criticism
For a content repository where the valuable relationships live in prose rather than in imports, this doesn't replace what I already have. A small generated knowledge.json already models every post, its category and tags, and the full internal-link graph — the relationships Graphify's code mode doesn't see. Adding a second graph that's strong where I'm not weak is complexity without payoff.
One practical warning either way: graphify update writes a graphify-out/ directory into the repo you point it at — 6.6 MB across graph.json, an interactive graph.html, and a cache. Gitignore it before your next commit:
echo "graphify-out/" >> .gitignore
Use it if your repo is a real codebase — thousands of files across several languages — and you want an agent to navigate imports and call chains with citations instead of grepping blindly. The speed and the 74MB footprint make it cheap to keep fresh with graphify update in a hook, and the zero token cost means the graph itself never shows up on your model bill.
Skip it if your repo is small enough to read directly, or if the relationships you care about are semantic rather than syntactic. In the first case the graph is overhead; in the second, the code-mode extraction won't capture what you're after — you'd be relying on the optional LLM path, which reintroduces the cost you were trying to avoid.
That's the honest split. It's a well-built tool that's fast, free, and precise about its own confidence levels — three things I wish more AI tooling was. It just solves a problem I don't have. For the memory-layer side of this question rather than the code-structure side, SelfMem is the closer fit, and the broader argument for treating all of this as infrastructure rather than magic is in the agent harness as infrastructure.
📌 Read the latest version of this guide — plus the full library of DevOps, SRE, Kubernetes, observability & cloud-cost guides — on devtocash.com.
Top comments (0)