Graphify: Giving Your AI Coding Assistant a Map

The problem it solves

AI coding assistants read files. A lot of files. Every time you ask Claude Code or Cursor to work on something, it figures out your codebase from scratch. On a big project, that means burning context window on file reads before it even starts thinking about your question.

Graphify does something else. Run it once, and it builds a structural map of your project as a knowledge graph. Your AI assistant queries the graph instead of reading files. It knows which functions call which, where dependencies are, how modules connect. No re-scanning the whole tree each time.

What you get

Run graphify . and you get three files in graphify-out/:

• graph.html — interactive visualisation in the browser. Nodes are functions, classes, modules. Edges are dependencies, calls, imports. You can filter, search, click around.
• GRAPH_REPORT.md — highlights "god nodes" (heavily connected things), surprising cross-file connections, and questions worth asking about the codebase.
• graph.json — raw graph data your AI assistant can query.

We opened the HTML view on a client project and immediately spotted a utility module that half the codebase depended on. Nobody had documented it.

Under the hood

Code parsing happens locally. Graphify uses tree-sitter to pull structure from source files (functions, classes, imports, call relationships) without sending anything to an API. Supports 31+ languages.

Non-code files like Markdown, PDFs, and images go through an LLM for concept extraction. You pick the backend: Anthropic, OpenAI, Gemini, or Ollama for local inference.

There's also an MCP server, so Claude Code can query the graph directly with structured calls like query_graph, get_node, shortest_path.

Setting it up

pip install graphifyy
graphify .

For Claude Code integration, add the MCP server:

{
  "mcpServers": {
    "graphify": {
      "command": "graphify",
      "args": ["mcp"]
    }
  }
}

After that, Claude Code queries the graph instead of reading files one by one.

What worked well

The graph report surfaces things you probably know but haven't written down. Which files are load-bearing, which connections are unexpected, where complexity clusters. On a mid-sized Python project (~40k lines), the "god nodes" list matched exactly what we'd have pointed out in a review.

The PR dashboard (graphify prs) shows open PRs with graph-based impact analysis: which parts of the codebase a PR touches, what's downstream. Useful for figuring out review priority.

No telemetry. Code parsing stays local. Both matter when you're working on client projects.

Where it didn't

Python and JavaScript projects work out of the box. Monorepos with mixed languages or unusual structure need more fiddling.

The graph gets stale. If you're making rapid changes, you re-run the indexing. There's no file-watcher mode that keeps things in sync. For a morning of focused work, one re-run is fine. All-day sessions, expect a few.

LLM extraction for non-code files adds cost and latency. Mostly code? Doesn't matter. Large docs directory? It'll take longer and cost API calls.

When it makes sense

If you're using Claude Code on a codebase with more than a few dozen files, try it. The graph gives structural awareness that file-by-file reading can't match.

Even without the MCP integration, the visualisation and report are useful on their own. We've started running it as a first step on new client codebases, before writing any code.

Open source at github.com/safishamsi/graphify. There's a video walkthrough and a quick overview if you want to see it before installing.