What is a code knowledge graph?

A code knowledge graph is a map of a codebase as it actually connects — not as its folder structure implies. Functions, classes, modules, files, database tables, config values, and doc pages become nodes; the relationships between them — calls, imports, defines, references — become typed, directed edges. Instead of a pile of text you get statements a machine can follow: PaymentService calls StripeClient, StripeClient reads STRIPE_KEY, STRIPE_KEY is defined in the production config.

The idea is old — Google introduced its Knowledge Graph for web search back in 2012, framed as "things, not strings" — but it has a newly urgent application: AI coding assistants, which currently explore codebases the slowest possible way.

The problem it solves

Watch any coding assistant work and you'll see the same loop: grep for a string, open the files that match, read them into context, repeat. It works, but it has two structural flaws. It's amnesiac — the understanding built during a session evaporates when the session ends, and tomorrow the assistant re-derives your architecture from scratch. And it's textual — grep finds strings, not relationships, so 'what calls this function?' returns every file containing the name, including comments, tests, and an unrelated variable that happens to shadow it.

A graph fixes both. It persists between sessions, so the map is built once and queried forever. And it stores relationships directly, so structural questions become traversals — follow the edges from node to node — rather than string-matching plus hope.

How one gets built

Graphify builds a code knowledge graph in two passes, and the distinction between them matters. Code is parsed locally with tree-sitter — real AST extraction across 36 languages, no model call required to read your source. When the parser finds a call or an import, that edge is tagged EXTRACTED: deterministic, and it doesn't hallucinate. Everything that isn't code — READMEs, PDFs, SQL, Postgres schemas, Terraform — is read into the graph by your model, and those edges are tagged INFERRED: usually right, but judgment calls, labeled as such. Evidence that can't be fully resolved (dynamic dispatch, imports built from strings) is kept and tagged AMBIGUOUS rather than dropped or dressed up as fact.

Those confidence tags are the part most retrieval systems skip: a permanent record of what was found versus what was guessed, attached to every relationship in the graph.

What you can ask it

Once the graph exists, questions that used to require an archaeology session become single queries. What calls this function — and what calls those callers? What's the blast radius of changing this table? Which module is the god node everything secretly depends on? How does the webhook handler reach the database, hop by hop? These are all traversals, and their answers come with paths: real files, real symbols, every edge labeled with its provenance.

The graph also reveals shape you can't grep for at all. Densely connected clusters of nodes — communities — usually correspond to real subsystems, whatever the directory tree says. The most-connected nodes mark where changes are riskiest. Both show up in the report Graphify writes when it maps a repo.

Try it on a real repo

The fastest way to understand a code knowledge graph is to build one: uv tool install graphifyy, then graphify install to wire it into your assistant, then /graphify . in your next session. You get an interactive graph.html map, a written GRAPH_REPORT.md brief, and the raw graph.json — all local, all yours. From there, graphify query, graphify path, and graphify explain (plus the MCP tools your assistant calls) turn the map into answers.

For the deeper mechanics, read how Graphify works; for how this compares to embedding your repo into a vector store, see graph vs RAG; and for term-by-term definitions, the glossary covers the whole vocabulary.