DEV Community: Syed Fahad

I turned Click into a 3,498-node code graph and plugged it into Claude Code over MCP. Here's the setup.

Syed Fahad — Wed, 11 Nov 2026 13:06:24 +0000

Every time I ask Claude Code "who calls this?", I watch it grep, open a file, grep again, and open three more. It gets there. It just takes the long way round.

So this week I gave it a map instead. I took Click, the Python CLI library (~17.8k ⭐), built a knowledge graph of it in about 3 seconds, and served that graph to Claude Code as MCP tools. Below is every command, plus the real output, so you can do the same on your own repo in ten minutes.

I work on Graphify, the tool I'm using here. If this ends up useful, a ⭐ on GitHub helps a lot.

TL;DR: pip install "graphifyy[mcp]", run graphify update . in your repo, then claude mcp add the graphify-mcp server. Claude Code gets 10 graph tools for nodes, neighbours, paths and PR impact.

What you need

Python 3.10+ and a repo you know well (I used Click at commit 8abb77a, so the numbers below are reproducible)
Claude Code installed (claude on your PATH)
About ten minutes

Step 1: install the CLI and the MCP extra

pip install "graphifyy[mcp]"
graphify --version

graphify 0.9.104

The package on PyPI is graphifyy (two y's). The command is graphify. The [mcp] extra adds the graphify-mcp server.

Step 2: build the graph

From the repo root:

git clone https://github.com/pallets/click && cd click
graphify update .

Re-extracting code files in . (no LLM needed)...
[graphify watch] Rebuilt: 3498 nodes, 6798 edges, 213 communities
[graphify watch] graph.json, graph.html and GRAPH_REPORT.md updated in graphify-out

That took 3.3 seconds of wall-clock time on my box for 156 files. No API key, no embeddings, no vector database. It parses the code with tree-sitter and writes three files into graphify-out/:

graph.json, the graph itself, which the MCP server reads
graph.html, an interactive view you can open in a browser
GRAPH_REPORT.md, a summary with the most connected nodes and the communities (think subsystems)

Before wiring anything up, I like to sanity-check that the graph "gets" the codebase. The most connected nodes in Click are exactly what you'd guess if you've used it:

graphify god-nodes --top 5

God nodes (most connected):
  1. Context - 185 edges
  2. Command - 110 edges
  3. Parameter - 98 edges
  4. CliRunner - 82 edges
  5. Option - 66 edges

Context sitting at the top with 185 edges is the right answer. Almost everything in Click touches it.

Step 3: register the server with Claude Code

Run this in a normal terminal, not inside a Claude Code session, and use an absolute path to graph.json:

claude mcp add --transport stdio graphify -- graphify-mcp /absolute/path/to/click/graphify-out/graph.json

Start a new Claude Code session and run /mcp. You should see graphify listed.

If you use Cursor or another JSON-config client, the same server goes in mcpServers:

{
  "mcpServers": {
    "graphify": {
      "command": "graphify-mcp",
      "args": ["/absolute/path/to/click/graphify-out/graph.json"]
    }
  }
}

Step 4: see what Claude Code actually gets back

The server exposes 10 tools. I listed them straight from the server with an MCP client:

query_graph, get_node, get_neighbors, get_community, god_nodes,
graph_stats, shortest_path, list_prs, get_pr_impact, triage_prs

Here's what three of them return on Click. This is the exact text Claude Code receives, so it's worth seeing once.

graph_stats tells the agent how big the graph is and whether it's fresh:

Nodes: 3498
Edges: 6798
Communities: 213
EXTRACTED: 77%
INFERRED: 23%
AMBIGUOUS: 0%
Built at commit: 8abb77a8432e03ed14a95f972b44f905279415a7 (matches HEAD)

That last line is my favourite. The agent can tell whether the graph matches the code it's looking at.

get_neighbors answers "what does this touch, and what touches it?" in one call. Here it is for _resolve_context() in shell completion:

Neighbors of _resolve_context():
  --> .make_context() [calls] [INFERRED 0.85] at=src/click/shell_completion.py:L706
  --> Command [uses] [INFERRED 0.95] at=src/click/shell_completion.py:L692
  --> Context [uses] [INFERRED 0.95] at=src/click/shell_completion.py:L696
  --> Group [uses] [INFERRED 0.95] at=src/click/shell_completion.py:L712
  <-- .get_completions() [calls] [EXTRACTED] at=src/click/shell_completion.py:L363

Every edge has a direction, a relation, a file and line, and a tag. EXTRACTED means it was read straight from the source. INFERRED means Graphify resolved it, with a confidence score. So the agent knows which hops it can trust as-is.

shortest_path answers "how does A reach B?":

Shortest path (1 hops):
  echo() --calls [EXTRACTED]--> resolve_color_default()
Path confidence: EXTRACTED (weakest hop 1: calls)

Step 5: prompts I'd try first

Once it's connected, ask questions that are about structure, not about one file:

"Use the graphify tools: what calls _resolve_context() and what does it depend on?"
"Find the shortest path from echo() to resolve_color_default() and explain each hop."
"Which community does CliRunner belong to, and what else is in it?"
"What are the 10 most connected nodes in this repo? Give me a one-line tour of each."

Saying "use the graphify tools" in the first prompt or two makes it obvious which tools you want. The rest is just asking the questions you'd normally answer with five greps.

Two small things that make it nicer

Names that collide get flagged, not guessed. Click has three different echo() functions. Ask for one by bare name and Graphify tells you so (node IDs trimmed):

Ambiguous: 'echo()' matches 3 nodes in different files.
  src/click/testing.py
  src/click/utils.py
  tests/test_utils/test_prompt.py
Retry with path::symbol using one of the paths above

For an agent, one extra call beats confidently walking down the wrong function.

Big answers stay inside a budget. query_graph caps its output (2,000 tokens by default) and says when it trimmed something, so the agent knows to narrow the question instead of assuming it saw everything.

Keeping the graph fresh

After you change code, rerun:

graphify update .

It only re-extracts code, so it's quick. graphify watch . rebuilds on every change if you'd rather not think about it.

If you don't want to run any of this locally, hosted Graphify indexes your GitHub repos and keeps the graph fresh for you. Claude Code connects to it with one command:

claude mcp add --transport http --scope user graphify https://api.graphify.com/mcp

Then sign in from /mcp. There's no API key to paste.

Try it on your repo

pip install "graphifyy[mcp]"
graphify update .
claude mcp add --transport stdio graphify -- graphify-mcp $(pwd)/graphify-out/graph.json

The MCP server docs cover HTTP mode for teams and every flag. If it helps, a ⭐ on GitHub means a lot, and I hang out in our Discord if you get stuck.

What's the first question you'd ask an agent that can see your whole codebase as a graph? Drop it in the comments and I'll run it on Click.

9 open-source tools that give AI coding agents real context

Syed Fahad — Tue, 10 Nov 2026 13:11:55 +0000

My coding agent is great at writing code and pretty bad at knowing where it is. Ask it to change one function and it greps, opens six files, guesses, and sometimes edits the wrong thing.

So I went through the open-source tools people use to fix that. Here are the nine I'd actually point a friend to, what each one is good at, and how to try it in a couple of minutes.

Quick disclosure: I work on Graphify, which is #1 here. Every tool on the list earns its spot. (If Graphify ends up useful to you, a ⭐ on GitHub genuinely helps.)

TL;DR: "context" means three different things for an agent: the structure of your code, the docs of other people's libraries, and plain fast search. Pick one tool per job instead of one tool for everything.

Star counts were checked on GitHub on Nov 9, 2026.

Your own codebase: structure and relationships

1. Graphify: a knowledge graph of your repo

Graphify (Apache-2.0, ~145k ⭐) turns a codebase, plus its docs, SQL schemas, configs and PDFs, into a queryable knowledge graph. Parsing is local and deterministic (AST, no embeddings, no vector store), and every edge is tagged EXTRACTED (read straight from the source) or INFERRED (resolved by Graphify), so you can see why two things are connected.

pip install graphifyy
graphify path "FastAPI" "ModelField"
graphify explain "APIRouter"

You get a graph.json, an interactive graph.html, and a GRAPH_REPORT.md with the most-connected "god nodes" and Leiden communities (your subsystems). It runs as a /graphify skill in Claude Code, Cursor, Codex and Gemini CLI, and there's an MCP server via graphifyy[mcp]. If you'd rather not run anything locally, the hosted version is at app.graphify.com.

Use it when the question is "how does X connect to Y?" or "what breaks if I touch this?"

2. Serena: IDE-grade symbol tools over MCP

Serena (~31k ⭐) gives your agent the things your IDE already knows: find symbol, file outline, find references. It does this by driving real language servers (LSP), and the README lists support for over 40 languages. Licensing is per component: the SolidLSP client is MIT and the Serena app is GPL-3.0-or-later.

Use it when you want symbol-level navigation and edits instead of text search.

3. Aider's repo map: the idea worth stealing

Aider (Apache-2.0, ~50k ⭐) is a terminal pair programmer, but the part I keep coming back to is its repo map. It builds a graph where files are nodes and dependencies are edges, ranks it, and sends the model only the most-referenced symbols that fit a token budget (--map-tokens, 1k by default).

Use it when you live in the terminal, or just read the doc. It's one of the clearest explanations of why structure beats dumping files.

4. Repomix: pack the whole repo into one file

Repomix (MIT, ~29k ⭐) packs a repository into a single AI-friendly file. The --compress flag uses Tree-sitter to keep signatures and drop implementation details, and --mcp runs it as an MCP server.

npx repomix@latest --compress

Use it when you're pasting a small or medium repo into a chat model, or handing a snapshot to someone else's agent.

Search: finding the right lines fast

5. ast-grep (+ its MCP server): search by syntax, not text

ast-grep (MIT, ~16.5k ⭐) is a Rust CLI for structural search, lint and rewrite. You write patterns that look like code, and it matches syntax trees instead of strings. The official ast-grep-mcp server exposes it to agents:

uvx --from git+https://github.com/ast-grep/ast-grep-mcp ast-grep-server

Use it when "find every call to X with two arguments" is the real question.

6. Probe: AST-aware search with zero indexing

Probe (Apache-2.0, ~740 ⭐) is the smallest project on this list and punches well above its size. It combines ripgrep speed with Tree-sitter parsing, takes Elasticsearch-style boolean queries ranked with BM25, and returns whole functions instead of random line fragments. No embedding model, no index step.

{ "mcpServers": { "probe": { "command": "npx", "args": ["-y", "@probelabs/probe@latest", "agent", "--mcp"] } } }

Use it when you want better-than-grep results without running a database.

7. Claude Context: semantic search over your code

Claude Context (MIT, ~13k ⭐) from Zilliz is an MCP server that indexes your codebase into a vector database (Milvus or Zilliz Cloud) so the agent can search by meaning. It's the most "classic RAG" pick here, and it needs a vector DB and an embedding provider to run.

Use it when your questions are fuzzy ("where do we handle retries?") and you're fine running a vector store.

Other people's code: docs and libraries

8. Context7: up-to-date library docs

Context7 (MIT, ~64k ⭐) from Upstash fixes the "the model learned an old version of this API" problem. Its MCP tools (resolve-library-id, query-docs) pull current, version-specific docs into the prompt. Setup is one command:

npx ctx7 setup

Then add "use context7" to a prompt, or tell your agent to always use it for library questions.

Use it when the bug is the agent using a deprecated API.

9. GitMCP: any GitHub repo as an MCP server

GitMCP (Apache-2.0, ~8.5k ⭐) is a free, remote MCP server. Point your agent at https://gitmcp.io/{owner}/{repo} and it can read that project's docs and code, even if the model has never seen it. There's also a generic gitmcp.io/docs endpoint for switching between repos.

Use it when you're working against a niche library with no docs in the model's training data.

How I'd combine them

One structure tool for your own repo: Graphify for relationships across code and docs, or Serena for symbol-level navigation.
One search tool: ast-grep for exact syntax, Probe for ranked results, Claude Context if you want semantic search.
One docs tool: Context7 for popular libraries, GitMCP for everything else.

Repomix and Aider's repo map are worth knowing either way, if only to understand what "giving the agent context" actually means.

If you try Graphify, the fastest path is app.graphify.com, or pip install graphifyy and run graphify on a repo you know well. A ⭐ on GitHub helps a lot, and I'd love to hear what it finds in your repo in our Discord.

What's in your agent's context stack right now? Anything I missed that should be on this list?

I mapped a 1,095-file repo into a knowledge graph in 5 minutes. Here's what it found.

Syed Fahad — Wed, 04 Nov 2026 13:28:55 +0000

Last week I pointed an AI agent at our own repo and asked it one thing: draw me a map. Five minutes and twenty-five seconds later I had 4,022 nodes, 10,079 edges and a picture of our codebase I'd never seen before, even though I work on it every day.

Here's the full run, what came out, and how you can do the same on your repo.

The setup

The repo is Graphify-Labs/graphify, at commit dac0634. It has 1,095 files: Python source, tests, docs, examples and fixtures.

I ran it inside Perplexity Computer with the Graphify skill enabled. I typed /graphify, pasted the GitHub URL, and asked for a knowledge graph of the codebase. I didn't use a connector or upload anything. The agent cloned the public repo itself.

If you'd rather run it locally:

pip install graphifyy

Then point it at any folder and let your coding agent (Claude Code, Cursor, Codex, whatever you use) query the graph.

What happened in 5m 25s

The agent picked the 105 files that carry the code's structure out of the 1,095 and parsed them into a graph:

Metric	Value
Files mapped	105 of 1,095
Nodes	4,022
Directed edges	10,079
Communities	192
Wall-clock time	5m 25s

Every function, class and module becomes a node. Every call, import and containment becomes an edge. Then community detection groups everything into 192 clusters that roughly match how the code is organised.

What the graph told me

This is where I stopped skimming and started reading.

_read_text() is the most connected function in the repo, with 270 links. It's a tiny helper, and almost every extractor goes through it. If you're new to the codebase, this is the function to read first.

_make_id() comes second with 234 links. Every node in every graph gets its identity here. Changing it changes everything downstream, and the graph shows that before you touch it.

dispatch_command() calls 127 different functions. That's the CLI's front door. One node shows the entire surface area of the tool.

extract.py has a degree of 442. It's the gravitational centre of the project, which matches my gut feeling but now I have a number for it.

The graph also caught a stale line in our docs. ARCHITECTURE.md said to_html lives in export.py. The graph showed it's in exporters/html.py. One query, one fixed doc.

What you get at the end

The run produced three things:

An interactive map you can pan, zoom and click through.
A ZIP with graph.json, graph.html and notes, ready to drop into your agent's context.
A written report of the hubs, communities and entry points.

graph.json is what matters for daily work. Instead of grepping and re-reading files every session, your agent asks the graph "what calls _make_id?" and gets the answer from structure, not similarity.

Try it on your repo

pip install graphifyy
Run it on your project folder.
Ask your agent: "What are the five most connected functions, and what depends on them?"

I'd love to see what your graph says. Drop your node and edge counts, or the most surprising hub, in the comments. And if this was useful, a ⭐ on GitHub helps more developers find it.

Why vector search isn't enough for coding agents

Syed Fahad — Fri, 30 Oct 2026 16:21:05 +0000

Ask a coding agent "where does an expired token get rejected?" and vector search will usually find something that sounds right. The hard part is the next step. The agent has to work out how that code connects to the code it's about to change.

Since our post on code knowledge graphs vs RAG, readers have asked for one thing above all: show it end to end. One question, the code it finds, the dependency path the graph returns, and a label on every hop saying whether it was read from the source or inferred. This post does exactly that. Everything below the "Worked example" heading is real output from open-source Graphify, run on a public repo you can clone yourself.

What others have already shown

We're not the first to look at this, and the best published examples are worth reading in full:

The orphan function. In Codebase Knowledge Base Series (05), WonderLab asks about "process payment". Vector top-5 returns get_payment_history and verify_webhook_signature, which look like payments but don't answer the question. One CALLS hop from process_checkout brings in calculate_order_total, the function that does. In their words, it's "semantically distant but structurally close."
The bug three hops down. Tian Pan's Code-Specific RAG traces processPayment → validateCard → checkFraudScore → fetchUserHistory. A query surfaces the first function, "but the actual bug or context lives in fetchUserHistory. Token-based retrieval stops at the first hop."
Look-alike functions. In CodeBot, InkyLab points out that training and inference preprocessing "look almost identical. A vector search can't tell them apart." Their fix is resolved calls edges over the Ultralytics codebase.
Ranking by references. Aider's repo map uses tree-sitter to pull out definitions and references, then ranks them on a dependency graph to fit a token budget.
On a benchmark. RepoGraph (Ouyang et al.) builds a line-level definition/reference graph and retrieves ego-graphs around keywords. Plugged into four SWE-bench systems, it reports an average relative improvement of 32.8%.

They all land in the same place. Finding the starting point is the easy part. Structure is how you get from there to everything the change touches. What most of these write-ups leave out is the question readers keep asking: how far can you trust each hop? That's where Graphify's labelled edges come in.

Worked example: itsdangerous, one question

The repo is pallets/itsdangerous (commit 672971d), the small library Flask uses to sign cookies and tokens. It's small enough to check every line by hand.

Building the graph uses only the parser, with no LLM call:

$ graphify update src
[graphify watch] Rebuilt: 152 nodes, 346 edges, 7 communities

Step 1: the question finds the relevant code

$ graphify query "where does an expired timestamp raise SignatureExpired"
Graph: src/graphify-out/graph.json (152 nodes) | Traversal: BFS depth=2 |
Start: ['SignatureExpired', 'TimestampSigner', 'Raised if a signature does not match.'] | 64 nodes found

From a plain-language question, Graphify went straight to SignatureExpired and TimestampSigner, the code that handles expiry. A list of matching chunks would stop here. Graphify keeps going.

Step 2: the graph returns the path, with a label on every hop

The same query returns the edges around those start nodes. Here are the ones that answer the question, copied as printed:

EDGE TimestampSigner --method [EXTRACTED]--> .unsign() at=src/itsdangerous/timed.py:L72
EDGE .unsign() --calls [EXTRACTED context=call]--> SignatureExpired at=src/itsdangerous/timed.py:L142
EDGE SignatureExpired --inherits [EXTRACTED]--> BadTimeSignature at=src/itsdangerous/exc.py:L60
EDGE TimestampSigner --inherits [EXTRACTED]--> Signer at=src/itsdangerous/timed.py:L22
EDGE TimestampSigner --uses [INFERRED]--> SignatureExpired at=src/itsdangerous/timed.py:L142
EDGE TimedSerializer --uses [INFERRED]--> SignatureExpired at=src/itsdangerous/timed.py:L213

Then we ask for the shortest route from the serializer most apps actually call:

$ graphify path "TimedSerializer" "SignatureExpired"
Shortest path (1 hops):
  TimedSerializer --uses [INFERRED]--> SignatureExpired

Step 3: check each hop against the source

.unsign() --calls--> SignatureExpired, EXTRACTED, timed.py:L142. The parser read this straight from the call site:

if age > max_age:
    raise SignatureExpired(

That's the answer to the question, and it's backed by a line number.

SignatureExpired --inherits--> BadTimeSignature, EXTRACTED. It's in the class definition. It also matters for the change: any except BadTimeSignature or except BadSignature will catch expiry too.

TimedSerializer --uses--> SignatureExpired, INFERRED, timed.py:L213. No line has TimedSerializer calling SignatureExpired. The resolver linked them because the class body refers to the exception. Open line 213 and you'll find it isn't raised there. It's caught and re-raised:

except SignatureExpired:
    # The signature was unsigned successfully but was
    # expired. Do not try the next signer.
    raise

The inferred edge points at exactly the right line, and the label tells the agent this is the one hop worth a quick look before it edits. That's the point of provenance. Without labels, every hop looks equally certain. With Graphify, the agent knows which hops are read straight from the source and which one to verify.

What the agent ends up knowing

Say the task is "make expired tokens return a 401 instead of a 500." Here's what each approach hands the agent:

Graphify, with labelled hops:
- The exact raise site (L142, parser-backed).
- The exception hierarchy that decides which except blocks catch it (parser-backed).
- The one place a serializer deliberately re-raises it (inferred, flagged to verify).

Every hop comes with a file, a line number and a label, so the agent can make the change with the whole path in view.

Why the graph matters

Finding the code answers "where is the code about X?"
A code knowledge graph answers "what does X call, what calls X, and what catches it?" That's the question behind most risky changes, and the one WonderLab, Tian Pan, InkyLab, Aider and RepoGraph all show similarity alone can't answer.
Provenance labels tell the agent when it can move on and when to read the source first. EXTRACTED means the edge was read directly from the source. INFERRED means Graphify resolved it.

Graphify gives the agent all three in one answer.

Try it on your own repo

The fastest way to try this is the hosted Graphify app.

To run it locally, use the Graphify CLI:

uv tool install graphifyy
graphify install          # sets up the skill for Claude Code; use --platform for other assistants
graphify update .         # build the code graph
graphify query "where does an expired token get rejected?"
graphify path "TimedSerializer" "SignatureExpired"

Codex uses $graphify instead of /graphify.

Over MCP, the same operations are available as query_graph, shortest_path and get_node, so any MCP client can use them. The source is at github.com/Graphify-Labs/graphify.

What's next

Next, we want to run the same trace on a larger repo with hundreds of inferred edges, and measure how often an INFERRED hop holds up when you check it against the source. If you have a repo where vector search keeps sending your agent to the wrong place, tell us in the comments or on Discord, and we'll trace it.

Thanks to the authors linked above for publishing examples we could build on.

Syed Fahad and the Graphify team

Graphify made it to GitHub's Octoverse 2026

Syed Fahad — Wed, 28 Oct 2026 20:19:56 +0000

We're in GitHub's Octoverse 2026. I had to read it twice.

Octoverse is GitHub's yearly look at what happened in open source. This year's report has a list of the most-engaged open source repositories, and Graphify-Labs/graphify is No. 7 on the single-vendor and product-led side. That's next to microsoft/vscode, anomalyco/opencode, and BerriAI/litellm. The report covers 1 October 2025 to 30 September 2026.

Our first commit was 5 April 2026. Six months later, GitHub put us in its year-in-review.

Octoverse, built by the community

Engagement means people. You starred the repo, filed issues, sent pull requests, answered questions in Discord, and wrote about Graphify on your own blogs. That's what this list counted.

As of 29 October 2026, the repo has more than 137,000 stars and more than 13,000 forks. The graphifyy package was downloaded from PyPI more than 1.6 million times in the last month.

Two weeks ago we wrote about 125,000 GitHub stars, and before that about 8 million PyPI downloads. Octoverse is GitHub telling the same story.

What doesn't change

If you're new here: Graphify turns your codebase into a map your AI assistant can read, so its answers come from your actual code.

Your code is parsed on your machine.
Every relationship is tagged EXTRACTED or INFERRED.
You get a knowledge graph your assistant can query and walk.
Graphify stays Apache 2.0.

Type /graphify in Claude Code, Cursor, Gemini CLI, or Copilot ($graphify in Codex), and you get a map of your codebase.

Beyond the repo: what's on graphify.com

The open source engine runs on your machine, and that stays. graphify.com is where the same graph runs hosted, kept current for you.

The hosted Graphify MCP server gives Claude Code, Cursor, Codex, Copilot, and other agents one endpoint with an OAuth sign-in, so they query the graph instead of re-reading files. The Graphify integrations page lists the assistants it works with and the tools your code comes in from. Hosted plans add pull request reviews and formal verification, and a workspace can hold more than code, like a Google Drive folder.

Graphify pricing starts with a free plan for one developer, then Pro, Teams, and Enterprise. Graphify Enterprise runs self-hosted or air-gapped, with SAML single sign-on. Pre-seed and seed teams can apply to the Graphify for Startups program for 50% off Teams.

If you'd rather help build, GraphGuild is our community program for people who answer questions, write, and host events.

Thank you

This one belongs to every contributor, every bug report, and everyone who told a teammate about Graphify. Thanks also to the GitHub team for the recognition and the artwork.

If Graphify has helped you, star it on GitHub. It's the easiest way to tell us to keep going.

Syed Fahad and the Graphify team

Grounded answers: how Graphify tags what it knows

Syed Fahad — Wed, 28 Oct 2026 12:27:07 +0000

Confidence tags on a Graphify graph say how each edge was established, before an agent follows it. EXTRACTED means tree-sitter found the call, import, or definition in the syntax tree. INFERRED means a model connected it. AMBIGUOUS means the evidence did not resolve, and the edge stays flagged. Read the tag before you trust the hop.

What do the confidence tags mean?

A code knowledge graph stores functions, classes, and docs as nodes. Calls, imports, and references are the edges between them. The edge is the claim the assistant walks. Confidence tags are the label on that claim. How Graphify works builds the graph in two stages, and the tag says which stage produced the edge.

EXTRACTED comes from the syntax tree. Graphify parses code on the machine with tree-sitter. The parser finds the call, the import, or the definition, and that edge is deterministic. Parse the same file again and the parser finds the same edge. No model sits in that step. The Cursor integration describes this tag as parsed from the AST.

INFERRED is a connection a model made. Docs, PDFs, and recordings are not a tree of calls. (SQL schemas and Terraform are parsed, so their edges are EXTRACTED.) The model you configure joins a doc page to the service it describes, or a runbook to the Terraform resource it covers. Those edges are usually right. They are still a judgment, and the tag says so. A plausible link can be wrong. The tag is how you see that the link was proposed.

AMBIGUOUS means Graphify found evidence and could not resolve it. The cases named in the glossary are dynamic dispatch, reflection, and an import built from a string. The edge stays in the graph with the flag, so the unresolved link is visible as unresolved.

graphify explain shows how each connection on a node was established. GRAPH_REPORT.md separates the architecture the parser extracted from the connections the model proposed. Over MCP, graph_stats and the confidence audit in the report break the graph down by the three tags, so you can see how much of the map is parsed fact.

Why should an agent read the tag before the next hop?

An answer from the graph is a path. Each hop names a file and a line, and the edge on that hop carries one tag. The tags are different evidence. A caller the parser found and a doc the model attached can both appear in the same path, and the output keeps them distinct.

Treat every hop as fact and an INFERRED link gets the same weight as an EXTRACTED call. That is how a guessed connection becomes an edit. The glossary uses this picture: the payment worker depends on the sessions table. You want to see whether the parser found that, or a model inferred it, before you change the code.

Lean on an EXTRACTED hop when you change code. Treat an INFERRED hop as a lead, and open the doc and the symbol. Treat an AMBIGUOUS hop as a place to read the source, because the evidence stopped short of a resolved link.

A similarity score says two chunks resemble each other. It does not record whether a relationship was parsed or proposed. That difference is the subject of Code knowledge graph vs RAG.

Where do confidence tags not help?

The tag describes an edge. It does not answer "find this string." Grep returns the lines that contain the string. A misspelled word in a comment, or a URL in a config file, is that question. Grep answers the hop you can phrase as a string. A tag will not.

Fuzzy search over a large body of prose is the other miss. Embeddings are the better tool there, and Graphify does not try to beat them. A tag will not find the paragraph that only resembles the question.

What runs on the machine?

The open-source engine is Apache 2.0. Code parsing happens on your machine. There is no telemetry. INFERRED edges use the model backend you configure, and that backend can be a local one, so the judgment can stay on the machine too. The graph is files in graphify-out/: graph.html, GRAPH_REPORT.md, and graph.json.

Graphify Cloud hosts the same kind of graph and keeps it current. It is a different product.

uv tool install graphifyy

The package on PyPI is graphifyy (two y's). pipx install graphifyy also works. Then graphify install, and in the assistant /graphify .. The command reference is in the docs.

Why graphs beat vectors for agent memory

Syed Fahad — Wed, 28 Oct 2026 12:26:57 +0000

A code graph stores the calls and imports in a codebase, and the assistant still has them next session. A vector database stores text that resembles the question, then searches again. The code graph vs vector database difference is what the assistant remembers.

How does a code graph differ from a vector database?

A code graph stores typed entities and the relationships between them. A Knowledge graph is that structure. The entities are the things in the repo. The edges are how they connect, and an assistant can traverse them. A vector database stores embeddings and metadata filters. A filter limits which vectors return. The relationship lives on the graph as an edge, and that edge is still there when the assistant starts again.

How similarity and structure compare as ways to fetch an answer is in Code knowledge graph vs RAG.

What does a query return?

A graph query is a typed, multi-hop traversal. The assistant follows edges of a given type, one hop after another. A vector query is approximate nearest-neighbour search, a top-k of the chunks whose embeddings sit nearest the question.

Graphify vs vector databases sets the two side by side. Pinecone, Weaviate, and pgvector return the most similar vectors. The graph returns the entities and the relationships between them. For an assistant, that result is the memory.

What happens on the second hop?

The gap shows up when a question has two steps. A top-k lookup is one round of nearest-neighbour search, so a second hop needs the first answer before it can even be phrased. The model is left stitching disconnected chunks together.

On a graph the second hop is one more edge. A later session follows that same edge, because the edge was stored with the graph.

What stays when a file changes?

Changing a file means re-embedding and upserting every chunk it touched before any of it can be retrieved again. Graphify re-parses that one file and updates its nodes. The edges that did not change stay. The cost of keeping current is the size of the change, not the size of the repository.

Inside the assistant, the command is /graphify . --update.

How can you check an answer?

A vector result comes with a similarity score. The score measures how near two vectors were. A graph result is the path the answer took. Every edge on that path carries a confidence tag: EXTRACTED, INFERRED, or AMBIGUOUS.

The tag is stored on the edge, so the next session can read that path.

Where does the text go?

Vector data is often shipped to an embedding API. Graphify is on-device, and it sends no telemetry.

Where does a vector database still win?

Graphify vs vector databases has nine rows. Eight of them are a real difference. The ninth is the one they win. A vector index answers what looks like this, and for fuzzy similarity over large volumes of prose it is still the better tool.

Can you run both?

You can run both. Some teams keep a vector index for semantic recall and use Graphify for structure. Graphify can store embeddings as node attributes, so similarity stays one signal inside a traversal.

Hybrid search blends keyword and vector scores. What comes back is still a ranked list of disconnected chunks. A graph returns connected entities, and the structure survives retrieval. Graphify vs RAG is that choice for a retrieval pipeline. After the session ends, those connections are on the graph.

Does Graphify replace Pinecone, Weaviate, or pgvector?

As coding-assistant memory, retrieval becomes a traversal over typed edges. The answer arrives as connected entities, and the path is there to read. Graphify does not replace Pinecone, Weaviate, or pgvector for every workload. Those products keep their place for pure similarity, and Graphify runs alongside them.

Is Graphify a graph database like Neo4j?

Graphify is a memory layer. It builds the graph from your codebase and serves it over MCP and the CLI. There is no schema to model and no queries to write. If you already run Neo4j or FalkorDB, it exports into them.

Proof

Steve Scargall, at MemVerge, reported 79× fewer tokens on a 496K-token codebase, with no vector database in the stack. That is his measurement, not a Graphify benchmark.

Install

The package on PyPI is graphifyy. Install the CLI, then register it with your assistant.

uv tool install graphifyy
graphify install

In the project, build the graph.

/graphify .

How to give GitHub Copilot codebase context that persists

Syed Fahad — Wed, 28 Oct 2026 12:26:29 +0000

GitHub Copilot codebase context vanishes when the chat ends, because each session starts from zero and Copilot searches the repo again. A graph built once on your machine is a map Copilot can query the next time. Graphify builds that graph and registers it with Copilot.

How do you give GitHub Copilot codebase context?

The GitHub Copilot integration page wires this in two commands, then a graph of the repo. The package on PyPI is graphifyy (two y's).

uv tool install graphifyy

pipx install graphifyy also works.

graphify install

graphify install registers the /graphify skill and an MCP server, so Copilot can query the graph. Graphify speaks the Model Context Protocol. Any MCP client talks to the same server and the same ten graph tools. The integration page points at the docs for how to point Copilot at that server.

Build the graph on the project you have open. In Copilot, run:

/graphify .

Tree-sitter parses the code locally, so call and import edges come from the syntax tree. Docs and other non-code files are read by the model you already use. The map lands in graphify-out/ as graph.html, GRAPH_REPORT.md, and graph.json. The next session queries those files. The architecture is already on disk.

A knowledge graph here means entities and the typed relationships between them. The same shape of setup for Cursor is How to give Cursor a code knowledge graph.

What can Copilot ask once the graph exists?

The questions on the integration page are the ones that used to mean reading a large slice of the repo. What calls chargeCustomer, and what breaks if the signature changes. The path from a checkout endpoint to the table it writes. Which modules read a config value such as STRIPE_KEY. How the auth subsystem hangs together before you touch it.

You can run the same questions from the shell. The page names these commands:

graphify query "what calls chargeCustomer"
graphify path "checkout" "database"
graphify explain "AuthService"
graphify prs

graphify query returns a scoped piece of the graph. graphify path walks the hops between two nodes. graphify explain lists the edges on one symbol. graphify prs is the pull-request command listed beside them. The docs cover its flags.

Every edge Copilot gets back carries a confidence tag. EXTRACTED was parsed from the AST with tree-sitter. INFERRED means a model connected non-code material, such as a doc to the service it describes, and the tag marks that judgment. AMBIGUOUS means there was evidence and it could not be fully resolved, as with dynamic dispatch or an import built from a string. The edge is kept and flagged.

When Copilot returns a path, open the file and line on the hop you are about to trust, and read the tag on that edge. An EXTRACTED edge is the parser. An INFERRED edge is the model joining a doc or a schema to code. It can be wrong and still sound plausible. An AMBIGUOUS edge is unresolved evidence, kept so the gap stays visible. The integration page describes the return value as connected structure, a path, which still holds past one or two hops. A pile of matching files, with the links guessed in the chat, is the loop this replaces.

What does the graph leave to you?

The graph does not update itself. After the code changes, run /graphify . again, or /graphify . --update to re-scan only what changed. From the shell, graphify update . does that pass. graphify hook install adds post-commit and post-checkout git hooks that refresh the changed files. Until you refresh, Copilot is reading the last map you built.

Grep still wins when the question is "find this string." The graph is for relationships. A literal string in a comment is still a search.

The open-source engine runs on your machine. Code parsing is local. There is no telemetry. Graphify Cloud is the hosted graph. This guide is the on-device setup. Cloud is a different product.

How do you confirm it is wired?

uv tool install graphifyy
graphify install

Then, in Copilot:

/graphify .

The command reference is in the docs. Copilot-specific notes stay on the GitHub Copilot integration page.

Best codebase-context tools for AI coding assistants (2026)

Syed Fahad — Wed, 28 Oct 2026 12:26:19 +0000

The best codebase context tools depend on the question you are asking. Grep finds a string. Embeddings, RAG, and a vector database find prose that resembles the question. A code knowledge graph follows a relationship you can open. Hosted search and review tools serve a person, or a pull request.

Question	A tool that fits
Find this string	grep
Prose that resembles the question	Embeddings, RAG, or a vector database
What calls what, hop by hop	A code knowledge graph
Search across the organisation	Sourcegraph
Comments on an open pull request	Greptile or CodeRabbit
Code that looks like this, inside Cursor	Cursor's own index

What is grep best at?

Grep is best when the question is "find this string." It returns the lines that contain the text. One hop is usually in reach too: the direct callers of a function, when the name in the call matches the name you searched.

Past that hop, text search gets worse. A question such as what breaks if this schema changes runs through the table, the queries, the services, and the endpoints. Each hop adds name collisions, re-exports, and files that mention the symbol without touching it.

What are embeddings, RAG, and a vector database best at?

They are best at fuzzy recall over prose. Graphify vs RAG describes retrieval-augmented generation the way Lewis et al. (2020) introduced it: split documents into chunks, embed them, and pull back the top-k most similar. That works for lookup, when the answer sits in one passage.

A relationship is a different shape. Chunking drops the link between a function and its caller. A two-hop question needs the first answer before the second can be asked, which is why benchmarks such as HotpotQA exist. Graphify vs vector databases names Pinecone, Weaviate, and pgvector: nearest-neighbour search returns similar vectors. A metadata filter narrows that search. Hybrid search still comes back as a ranked list of disconnected chunks.

A changed file is re-embedded before those chunks can be retrieved again. A similarity score measures resemblance, and you judge the answer yourself. Chunks in a typical embedding pipeline go to an embedding API.

Keep the vector index when the corpus is prose. Some teams run both: vectors for semantic recall, a graph for relationships. Graphify can store an embedding as one signal on a node, and retrieval is still a walk. If you already run Neo4j or FalkorDB, the graph exports into them. The essay form of this argument is Code knowledge graph vs RAG.

What is a code knowledge graph best at?

A code knowledge graph is best when the assistant needs a relationship: what calls this, what a change reaches, the path from one symbol to another. Graphify builds that graph from the repo. Code is parsed on the machine with tree-sitter, and each edge carries a confidence tag: EXTRACTED from the syntax tree, INFERRED by a model, or AMBIGUOUS when the evidence did not resolve. An answer is a path you can open.

There is no telemetry on the open-source engine. Graphify Cloud is the hosted graph. It is a different product.

Graphify is the wrong tool for two of the jobs in the table. Fuzzy prose still belongs to embeddings. "Find this string" still belongs to grep.

What are hosted search and review tools best at?

Graphify vs Sourcegraph is a code search platform people use. The index covers the organisation, every repository, cloud or self-hosted, under a commercial licence. Search across thousands of repositories is the job that page says Sourcegraph is built for. Graphify maps the repositories you point it at, on the machine where you work, and the assistant walks that map. The two can run together.

Greptile is hosted review and codebase chat. It indexes your code, and you see pull-request comments plus its own chat. Managed review on every pull request is its core product. graphify prs is on demand. A managed bot that fits your policies is Greptile's job. A graph on the machine fits when the code cannot leave, or when you want each claim auditable.

Graphify vs Cursor indexing is the page whose answer is to use both. Cursor's index is embedding similarity inside the editor, automatic, with indexing through Cursor's servers. It surfaces code that looks like what you half remember, and there is nothing to set up. Connected questions are where it runs out. "What breaks if I change this" is a caller of a caller, and the model stitches similar snippets. You also cannot inspect why a snippet was pulled in. Graphify registers as an MCP server, the built-in index stays on, and the agent uses the graph when the question is structural.

Graphify vs CodeRabbit acts after the pull request opens: comments in GitHub or GitLab, through a hosted service, once the change is already written. Graphify is for the assistant writing the code, so it can ask what calls this before the edit. Graph-aware review in Graphify is Enterprise, early access, running in your own infrastructure. For a managed bot on every pull request today, that page says a service is the right shape. A common setup is the graph on the machine while code is written, and a hosted reviewer on the pull requests that follow.

How to give Cursor a code knowledge graph (2026 guide)

Syed Fahad — Wed, 28 Oct 2026 12:26:10 +0000

Out of the box, Cursor answers codebase questions by searching. It greps for a symbol, opens the files that match, reads them into context, and assembles an answer. That works, and it is expensive in a specific way. The exploration repeats every session, the same files get re-read, and the architectural picture the agent builds is gone the moment you close the window.

A code knowledge graph changes the move available to the agent. Instead of re-deriving structure from text, Cursor queries a persistent map of your repo: functions, classes, tables, and config as nodes; calls, imports, and references as typed edges. The graph is built once and stored on your machine. Graphify is the open-source (Apache 2.0) tool that builds that graph and hands it to Cursor. The whole setup is four commands.

How it works

Install the CLI. The package on PyPI is graphifyy (two y's). That puts the graphify command on your path.

uv tool install graphifyy

Wire Cursor. graphify install detects Cursor and registers Graphify over the Model Context Protocol, the open standard Cursor already speaks for external tools. Cursor's agent can then call the graph mid-conversation: query the structure, trace a path between two nodes, explain why a node matters. No config files to hand-edit. The Cursor integration page has the specifics.

graphify install

Map the repo. In your next agent session, or from the shell, run /graphify . in the project. Graphify parses your code locally across about 40 languages, including SQL, Postgres schemas, and Terraform, so the call and import edges come from real AST extraction. No model is involved in reading your source. Docs and PDFs are folded in by whichever model you choose.

A few minutes later, three files sit in graphify-out/:

graph.html: an interactive map you can open in a browser
GRAPH_REPORT.md: a written brief covering god nodes, subsystem communities, and suggested questions
graph.json: the raw structure

Ask structural questions. Try the ones that used to trigger long search-and-read loops: what calls this function, what is the blast radius of renaming this column, how does the webhook handler reach the database. Cursor answers by traversing the graph (a handful of nodes and edges rather than the full text of every matching file). Every edge carries a provenance tag: EXTRACTED from the AST, INFERRED by the model, or AMBIGUOUS when the evidence could not be resolved. Why that tagging matters is in concepts.

You can run the same queries yourself:

graphify query "what calls this handler"
graphify path "webhook" "database"
graphify explain "APIRouter"

The command reference lives in the docs.

The limit

The open-source engine runs on your machine. Code parsing is local. There is no telemetry. The only optional network call is the model used to fold non-code sources into the graph, and that can stay local with Ollama.

Re-run /graphify . when the code changes meaningfully, or graphify . --update to re-scan only what changed. Between refreshes the graph is plain files in graphify-out/. It does not update itself.

Graphify Cloud is the hosted, always-on graph: the same map, kept current across repos, queryable from any assistant. This guide is the on-device setup. Cloud is a different product.

This does not replace Cursor's grep. It gives the agent a map to consult first. For a question that is really "find this string," grep is still the right tool.

Proof

Graph answers are small, and the graph persists, so context stops being spent on re-discovery. Actual savings depend on your repo and your questions. One community user reported 71.5× fewer tokens on their workload. That is their measurement, not a Graphify benchmark. The claim underneath it is that a traversal sends less text than a file dump.

The other change is qualitative. Because every answer traces to a path through real files, you can audit what Cursor tells you instead of taking a plausible-sounding reconstruction on faith. Open GRAPH_REPORT.md once. The god nodes and subsystem communities it names are usually worth knowing about even before the agent starts using them.

Install

uv tool install graphifyy
graphify install

Then, in Cursor:

/graphify .

First-graph walkthrough: docs.graphify.com/guides/first-graph. Cursor-specific notes: graphify.com/integrations/cursor.

How to give Claude Code a code knowledge graph (2026 guide)

Syed Fahad — Wed, 28 Oct 2026 12:26:00 +0000

Claude Code starts each session by searching the repo. It greps for a name, opens the files that match, and reads them into the conversation. A code knowledge graph for Claude Code gives it a map it can query instead, so the session starts from structure that already exists on your machine.

What does graphify install write for Claude Code?

The package on PyPI is graphifyy, with two y's. Install the CLI first.

uv tool install graphifyy

pipx install graphifyy also works. If the shell then says graphify is not found, run uv tool update-shell and open a new terminal. ~/.local/bin is not on PATH until you do.

The bare graphify install targets Claude Code. It writes the /graphify skill to ~/.claude/skills/graphify/SKILL.md, adds a graphify section to ~/.claude/CLAUDE.md, and writes PreToolUse hooks to .claude/settings.json. When you type /graphify, that section tells Claude Code to follow the skill before it does anything else.

graphify install --project writes those pieces inside the repo, so a team can commit them. The skill path there is .claude/skills/graphify/SKILL.md, and the hook settings go in .claude/settings.json. The command prints a git add hint. Teammates need the graphifyy CLI installed.

If you see ModuleNotFoundError: No module named 'graphify', the usual cause on Mac or Windows is a plain pip install. The skill resolves Python from graphify-out/.graphify_python, which can point at a different environment than pip used. Use the uv or pipx install above. Both isolate the package.

The registration block is on Graphify + Claude Code: a code knowledge graph.

How do you build the graph?

In a Claude Code session, type /graphify .. The skill maps the project into graphify-out/. graph.html is the interactive view, GRAPH_REPORT.md has the highlights and suggested questions, and graph.json is the queryable graph.

On PowerShell, type graphify .. The leading slash in /graphify . is parsed as a path separator there.

If /graphify does nothing, check that ~/.claude/skills/graphify/SKILL.md exists and that the graphify section is in CLAUDE.md. Start a new Claude Code session so both are picked up.

The background is in What is a code knowledge graph?. The glossary page is Knowledge graph.

How does Claude Code query the graph?

Before Claude Code greps or opens files one by one, the hook-guard reminds it to try the graph. graphify query returns a scoped subgraph for a question. graphify path returns the dependency path between two symbols. graphify explain returns everything connected to a node. Ask what calls chargeCustomer, and what breaks if you change its signature.

graphify query "what calls chargeCustomer, and what breaks if I change its signature?"
graphify path "A" "B"
graphify explain "chargeCustomer"

Results include file:line citations. Every edge is tagged EXTRACTED, INFERRED, or AMBIGUOUS. The tags separate what was found from what was guessed.

What does strict mode change?

A normal install nudges Claude Code toward the graph. graphify install --project --strict blocks the first raw source read of a session and redirects that read to the graph. After that one block, the hook goes back to the soft nudge.

GRAPHIFY_HOOK_STRICT=1 or 0 toggles strict mode at runtime. No reinstall.

How does the graph stay current?

graphify update . re-extracts changed files. That pass is AST-only. graphify hook install adds post-commit and post-checkout git hooks that run the update on commit and checkout. The graph does not update itself.

Hook commands store an absolute path to the interpreter at install time. After you upgrade, run graphify hook install again so the embedded interpreter path stays fresh. If the PreToolUse hooks stop firing after an upgrade, run graphify install again.

Do you need the MCP server?

The skill plus the CLI is the complete default. The MCP server is optional. Add .mcp.json at the project root when you want the graph as native tools, or when several assistants should share one graph.

{
  "mcpServers": {
    "graphify": {
      "command": "python",
      "args": ["-m", "graphify.serve", "graphify-out/graph.json"]
    }
  }
}

You can call query_graph, shortest_path, god_nodes, graph_stats, and a PR-triage set. The rest are in the MCP tools reference.

When should you use grep?

Grep wins when the question is "find this string."

Code is parsed locally across about 40 languages, 34 of them with tree-sitter grammars. The model you already use in Claude Code reads docs and PDFs. There is no telemetry.

The installer replaces or appends only its own graphify section and leaves the rest of CLAUDE.md alone. graphify claude uninstall removes the Claude Code pieces. graphify uninstall removes every platform at once. It also removes the graphify section from CLAUDE.md, and deletes that file only if graphify created it. graphify uninstall --purge also deletes graphify-out/.

How do you install it?

uv tool install graphifyy
graphify install

Then open the repo in Claude Code and run /graphify ..

100,000 GitHub stars

Syed Fahad — Wed, 28 Oct 2026 12:25:48 +0000

We hit 100,000 GitHub stars. github.com/Graphify-Labs/graphify

That is 117 days after the first commit. Graphify has now been downloaded more than 4 million times, forked more than 10,000 times, and runs inside more than 20 AI coding assistants.

That still feels surreal.

I am a knowledge graph researcher. When Andrej Karpathy posted about using LLMs to build personal knowledge bases, something clicked: a coding assistant should not have to grep its way through a codebase every time you ask it a question. It should have a map. I built the first version that weekend and pushed it to GitHub on 5 April. One person and a tree-sitter parser.

We had 4,000 stars on day one and 10,000 by day two, almost entirely because people we had never met posted about it on X. We never optimised for stars. We optimised for one thing: type /graphify in your assistant and get something useful back in thirty seconds. Stars are a side effect of that. But a milestone is a good moment to stop and look back, and this one is really about a community that showed up, stuck around, and built things we never planned for.

What hasn't changed

The principles are the same ones I wrote down that first weekend.

Your code stays on your machine. Code is parsed locally and deterministically. No LLM call, nothing sent anywhere.
Every edge is explained. Each relationship is tagged EXTRACTED or INFERRED, so you always know what was read straight from the source and what Graphify resolved.
A graph, not a vector index. No embeddings, no vector store. Something you can traverse, query, and trace from one concept to the next.
Simple enough to onboard yourself. Two commands to install, one to run.

Standing on open source

Graphify is built on top of other people's work, and we would not be here without it.

tree-sitter. Every code relationship in Graphify starts life as a tree-sitter AST, across dozens of languages.
Leiden community detection. This is how a codebase splits into the subsystems you see in every graph.
faster-whisper and yt-dlp. They let Graphify pull videos, talks, and recordings into the same graph as your code, transcribed locally.
Model Context Protocol. MCP turned Graphify from a report you read into a set of tools any assistant can call.
uv. The reason install takes thirty seconds instead of thirty minutes.

And thank you to the teams behind Claude Code, Cursor, Codex, Gemini CLI, Copilot, and every other assistant we plug into. You built the place where developers now work. We just try to give it a better map.

The community

The numbers that matter most to me are not the stars. More than 130 people have contributed code, and we have shipped more than 150 releases. Nearly every fix that went out this month came from an issue or a pull request someone in the community opened. People have written tutorials, recorded videos, and posted reels about Graphify that we only found out about afterwards. This month we hit #3 on GitHub's global trending list.

To everyone who starred the repo, opened an issue, sent a pull request, answered a question in Discord, or wrote about Graphify somewhere: thank you. And thank you to Andrej for the post that started all of this.

We are not done

Graphify the open-source project stays open source. That is not changing.

The thing you have asked for most is the always-on version: your code, docs, and meetings mapped continuously in the background, updated as you work, and queryable from anywhere instead of only on demand. That is what we have been building at graphify.com, and as of today early access is open at app.graphify.com, ahead of the public v1 launch.

We think every AI assistant should work from a real map of your world, not a guess. We are going to keep building until that is the default.

Thanks for all the stars.

Safi and the Graphify team