Graphify: A Local AST-Based Knowledge Graph for AI Coding Assistants

What Graphify Solves and Who It Is For

Graphify addresses the problem of navigating a large codebase where grep and file-by-file reading are slow and lose the connections between symbols. It builds a knowledge graph from your code, docs, SQL schemas, configs, and PDFs, and lets you query it with plain-language questions or path queries. The target user is a developer working inside an AI coding assistant like Claude Code, Cursor, Codex, or Gemini CLI, who wants to ask 'what does this function depend on?' or 'how do these two modules connect?' without manually tracing references. The README positions it as an alternative to 'grepping through files', and the examples show commands like `graphify explain "APIRouter"` returning node details and connections. This is for teams that value deterministic, local analysis over embedding-based retrieval, and who are comfortable with a CLI-driven workflow rather than a background service.

The Mechanism: Tree-Sitter AST, Not Embeddings

The core mechanism is deterministic parsing with tree-sitter AST. The README states that code is parsed locally, with no LLM involved and nothing leaving your machine. This is a fundamental difference from vector-based tools: there are no embeddings and no vector store. Instead, the graph is built from explicit syntactic relationships: calls, imports, inherits, and mixes_in, resolved across approximately 40 languages. Each edge in the graph carries a confidence tag: EXTRACTED means the relationship is explicit in the source, while INFERRED means it was derived through graphify's resolution logic. This distinction is important because it tells you whether a connection was directly read from code or guessed by the tool. The graph is stored in graph.json, which you can query without re-reading your files. This design means the graph is reproducible and auditable, but it also means that semantic understanding of prose, like the intent behind a comment or the meaning of a PDF, is out of scope unless you configure a separate semantic pass that calls a model.

Getting Started: Install, Register, and Query

The README gives a 30-second setup. You install the CLI with `uv tool install graphifyy` or `pipx install graphifyy`. Then you run `graphify install` to register the skill with your AI assistant. After that, in the assistant you type `/graphify .` to map the current directory. The output is three files in a `graphify-out/` directory: `graph.html` for interactive browsing, `GRAPH_REPORT.md` which summarizes key concepts, surprising connections, and suggested questions, and `graph.json` which holds the full graph. You can then run commands like `graphify explain "APIRouter"` to see a node's source location, community, degree, and its connections with edge tags. There is also `graphify path "FastAPI" "ModelField"` which returns the shortest path between two nodes, and `graphify query "<question>"` which returns a scoped subgraph. The CLI is the primary interface, and the skill registration is what ties it into your assistant. The commands are concrete and the output format is plain text, which fits a terminal workflow.

Edge Confidence and the Limits of Inference

The edge confidence tags are a genuine strength but also a limitation. EXTRACTED edges are reliable because they come directly from the source code, such as an import statement or a method call that is syntactically present. INFERRED edges are derived by graphify's resolution, which means they can be wrong or miss context that a human would catch. The README describes INFERRED edges as 'resolved by graphify'. This is a potential failure mode: if you rely on an INFERRED edge to understand a dependency, you might be misled. The example output shows `--> RequestValidationError [uses] [INFERRED]`, which suggests that the tool can detect usage even when it is not a direct call, but the confidence tag is your only clue. For a codebase with heavy metaprogramming, dynamic dispatch, or reflection, the AST-based approach will miss relationships that only exist at runtime. You should treat INFERRED edges as hypotheses to verify, not facts.

Beyond Code: Docs, PDFs, and the Semantic Pass

Graphify is not limited to code. The README states that docs, PDFs, images, and video can map into the same graph, but with a key caveat: these require a semantic pass that uses your assistant's model or a configured API key. This means the local-first guarantee only applies to code parsing. If you include PDFs or images, data leaves your machine and you incur API costs. This split is a trade-off: you get a unified graph, but the trust model changes depending on the file type. For a code-only project, nothing leaves your machine. For a project with documentation, you must decide whether the benefit of having PDFs in the graph is worth sending them to an external model.

Performance Claims and What They Don't Tell You

The repository has a BENCHMARKS.md at its top level. Any figures the project publishes there are self-reported and should be checked against your own task, which for most readers is navigating code rather than retrieving long-term memory.

Alternatives and the Vector Store Divide

The main alternative to Graphify is a vector-based retrieval tool. The difference in approach is fundamental: vector stores embed chunks of text into high-dimensional vectors and retrieve by similarity, which is good for fuzzy semantic search but bad for exact structural queries like 'what imports this module?'. Graphify builds an explicit graph with typed edges, which is better for tracing dependencies and understanding architecture. Another alternative is a traditional code search tool like ripgrep or ctags, which are faster and simpler but provide no graph structure. Graphify's value proposition is that it gives you the graph without a vector store. If your primary need is semantic search over docs, a vector store is the right tool. If your primary need is structural understanding of code, Graphify is a fit.

Maintenance, Licensing, and Upgrade Considerations

Graphify is released under the Apache-2.0 license (the repository also ships LICENSE-MIT and NOTICE files), which permits use, modification, and distribution, including in commercial products. The project is actively developed, with the last push on 2026-11-02 and releases v0.9.101, v0.9.100, and v0.9.99 within days of each other. This high release cadence suggests fast iteration, but it also means you should expect frequent changes and potential breaking changes between versions. The default branch is named 'v8'. The installation method via `uv tool install graphifyy` suggests the package is published on PyPI under the name 'graphifyy' (note the double 'y'), which is different from the repository name. This could be a source of confusion when searching for the package. Check the CHANGELOG.md or release notes before upgrading. Budget time for testing new versions before adopting them in a production workflow.

Editorial conclusion

Adopt Graphify if you work in a multi-file codebase inside an AI coding assistant and need deterministic, local answers about structure, imports, and calls without sending code to a model. Do not adopt it if you need semantic understanding of prose-heavy documentation or if your team cannot tolerate the overhead of a separate graph.json that must be regenerated on code changes. Before committing, verify that your primary languages are covered by the ~40 tree-sitter grammars, test the quality of INFERRED edges on your own code, and confirm that the CLI's output formats (graph.html, GRAPH_REPORT.md, graph.json) integrate with your existing review workflow. The project is under active development with frequent releases, so check the changelog between versions for breaking changes.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes