Resources

How Graphify works

Concepts · from AST to answer

Last updated July 1, 2026

A code knowledge graph isa machine-readable map of a codebase: functions, classes, files, database tables, and docs become nodes; calls, imports, definitions, and references become typed, directed edges. Because the relationships are stored explicitly, an AI assistant can answer structural questions by traversing edges instead of searching text — the same "things, not strings" idea Google introduced for web search in 2012, applied to code.

Graphify builds that graph on-device and hands it to your coding assistant to query instead of grepping. This page explains the machinery: how the graph gets built, what an edge really is, why traversal beats similarity search for code, and how your assistant talks to it. New to the vocabulary? Keep the glossary open alongside.

How the graph is built

Everything happens on your machine. When you run /graphify . in your assistant (or graphify from the terminal), the pipeline has two distinct stages, and the distinction matters:

Code is parsed, not read by a model. Graphify bundles 36 grammars for tree-sitter — in its own words, "a parser generator tool and an incremental parsing library" — and walks the AST of every source file locally. Functions, classes, imports, and calls become nodes and edges because the parser found them — deterministic, no API call, no hallucination.
Everything else is read by your model.Docs, PDFs, SQL schemas, Terraform — the things an AST can't capture — are connected into the graph using whichever model backend you configure (Claude, OpenAI, Gemini, DeepSeek, Ollama, and others). These edges are labeled as inferred, never passed off as parsed fact.

The output is three local files: an interactive graph.html, a GRAPH_REPORT.md that surfaces god nodes, communities, and surprising connections, and the raw graph.json. Nothing is uploaded anywhere. The full walkthrough is in the docs.

What an edge is — and why provenance matters

An edge is a typed, directed claim about your codebase: this function calls that one, this module imports that one, this doc describes that service. Any tool can make claims; the question is whether you can tell which ones to trust. Graphify attaches a confidence tag to every edge:

EXTRACTED — straight from the AST. The parser found it.
INFERRED — a model connected the dots. Usually right, labeled as a judgment call.
AMBIGUOUS— evidence Graphify couldn't fully resolve (dynamic dispatch, reflection, string-built imports). Kept, and flagged as uncertain rather than silently guessed.

This provenance model is the quiet backbone of the whole product: when your assistant answers a question by traversing the graph, you can see exactly which hops are parsed facts and which are inferences. A similarity score can't offer that.

Why a graph beats embeddings and grep

Grep finds strings. Embeddings find lookalikes. Neither finds connections— and connections are what most hard questions about code are made of. "What breaks if I change this?" is a multi-hop question: caller of a caller of a caller. Chunk-based retrieval breaks past one or two hops because chunking severed the links before retrieval ever started; grep answers only the single hop you can express as a string. The retrieval literature has converged on the same diagnosis — approaches like GraphRAG (Edge et al., 2024) add a knowledge graph on top of chunk retrieval to recover exactly this lost structure.

A graph answers by traversal. graphify query pulls everything connected to a symbol; graphify path walks the exact route between two entities; graphify explain tells you why an edge exists. The answer arrives as a path through your real code — traceable, inspectable, and cheap to keep fresh, since changing a file updates its nodes without re-indexing the world. The detailed head-to-heads are at Graphify vs RAG and Graphify vs vector databases. (And the honest limit: for fuzzy search over large volumes of prose, embeddings are still the right tool.)

How your assistant queries it

Two doors into the same graph:

As a skill. graphify install registers Graphify in the assistants you use — 17 of them, including Claude Code, Cursor, Codex, Copilot, Gemini CLI, and Aider (full list). The assistant runs the CLI commands itself when it needs codebase context.
Over MCP. Graphify ships a Model Context Protocol server (stdio or HTTP). MCP describes itself as "an open-source standard for connecting AI applications to external systems," and that's exactly the role the graph plays here: any MCP-capable assistant calls it as a native tool instead of shelling out. Setup is in the MCP section of the docs.

Either way, the payoff is the same: instead of pasting whole files into the context window, the assistant receives the relevant subgraph — the entities and relationships on the path to the answer — and spends its tokens on the task rather than on retrieval. Git-hook integration keeps the graph rebuilt as the code changes.

On-device by design

Graphify's privacy model is structural, not a policy promise. Parsing runs locally with bundled grammars; the graph lives in files on your disk; there is no account, no hosted index, and no telemetry. The one honest caveat: your assistant's own model calls work the way they always did — Graphify adds no new place your code travels, but it doesn't change where your assistant sends its prompts. Details on the security page. Teams that want this same graph powering PR review inside their own VPC should look at Graphify Enterprise.

Where to go next

See the concrete scenarios this enables in use cases, look up any term in the glossary, or skip straight to the quickstart — the whole thing is open source under MIT, and free means free.

Common questions

How does Graphify build the graph?

In two stages, both on your machine. Code is parsed — not read by a model — using bundled tree-sitter grammars for 36 languages, so functions, classes, imports, and calls become nodes and edges deterministically. Everything an AST can't capture (docs, PDFs, SQL schemas, Terraform) is connected in by whichever model backend you configure, and those edges are labeled as inferred. The output is three local files: graph.html, GRAPH_REPORT.md, and graph.json. Nothing is uploaded.

Is a code knowledge graph the same as RAG?

No. RAG chunks your code, embeds the chunks, and retrieves the ones that look most similar to a question — it finds lookalikes, not connections, and breaks past one or two hops because chunking severs the links. A code knowledge graph stores functions, files, and their real relationships as typed, directed edges, so an assistant answers by traversing an explicit path instead of guessing from snippets. For fuzzy search over large volumes of prose, embeddings are still the right tool.

What does a confidence tag on an edge mean?

Every edge carries provenance so you can tell parsed facts from judgment calls. EXTRACTED means it came straight from the AST — the parser found it. INFERRED means a model connected the dots. AMBIGUOUS means Graphify saw evidence it couldn't fully resolve (dynamic dispatch, reflection, string-built imports) and flagged it as uncertain rather than silently guessing.

How does my coding assistant query the graph?

Two ways into the same graph. As a skill: graphify install registers Graphify in 17 assistants (Claude Code, Cursor, Codex, Copilot, Gemini CLI, Aider, and more), and the assistant runs the CLI commands itself. Or over MCP: Graphify ships a Model Context Protocol server (stdio or HTTP) that any MCP-capable assistant calls as a native tool. Either way the assistant receives the relevant subgraph instead of whole files pasted into context.