Navigating code dependencies inside a single repository is already hard enough. But if you’re on a microservice setup, or a split frontend and backend, tracking what depends on what across multiple repos is a special kind of misery. A backend API route changes. Which frontend components just broke? Good luck. You’re grepping three workspaces and hoping you didn’t miss one.

So when I ran across Graphify, an open-source project from Graphify Labs (YC S26), it caught my attention. It maps your code directories into queryable knowledge graphs. Not fuzzy text search. Not an expensive vector RAG lookup that burns tokens every time you ask it a question. A deterministic index of your codebase.

Let me walk through how it works, why it’s useful for AI coding agents, and the part I wanted to figure out: how to stitch multiple repos into one unified map.

What Graphify Does

Instead of guessing at relationships, Graphify parses your source and builds a real graph out of it. Three pieces make it tick:

1. Deterministic AST parsing. It uses tree-sitter grammars locally to parse roughly 40 languages, pulling out classes, functions, calls, and imports. No LLM tokens, no API rate limits. Just parsing.
2. Explicit vs. inferred edges. Every relationship gets a confidence tag. EXTRACTED means it’s right there in the syntax, like an import or a direct function call. INFERRED means it deduced the connection from context. You always know how much to trust an edge.
3. Leiden community clustering. It automatically segments your code into logical domain boundaries, which makes it easy to spot the “god nodes”, the files with way too many dependencies hanging off them. Those are usually the first thing you want to refactor.

Merging Multiple Repos Into One Graph

This is the part I cared about. Graphify supports it natively through the CLI, and here’s the flow straight from the docs (I haven’t run it on my own repos yet). Say you’ve got a frontend repo and a backend repo. Three steps.

Step 1: Scan each repo on its own. Run the scan inside each folder. Results land in a graphify-out/ directory.

# In your frontend repo
cd ~/Work/frontend
graphify .

# In your backend repo
cd ~/Work/backend
graphify .

Step 2: Merge the graphs. The merge-graphs subcommand joins the JSON outputs into one combined map of nodes and relationships.

graphify merge-graphs \
  ~/Work/frontend/graphify-out/graph.json \
  ~/Work/backend/graphify-out/graph.json \
  --out ~/Work/combined_graph.json

Step 3: Traverse it, or hand it to your agent. Now you can trace a call path straight across the service boundary, or serve the combined graph to a coding agent over MCP.

# Trace a path across the frontend/backend boundary
graphify path "login_component.ts" "auth_controller.py" --graph ~/Work/combined_graph.json

# Or expose the combined graph to your coding agent over MCP
python -m graphify.serve --graph ~/Work/combined_graph.json

That path command is the whole pitch, honestly. You point it at a frontend file and a backend file and it tells you how they’re connected. No manual grep archaeology.

Why This Matters for AI Coding Agents

If you use Claude Code, Cursor, or Antigravity, you already know the problem. Feed the agent raw files and you torch the context window in about four prompts. Point it at Graphify’s output instead, the GRAPH_REPORT.md or the graph.json over MCP, and the agent can do a few things it otherwise can’t:

• Figure out exactly which files a refactor will touch before it edits anything.
• Trace dependency lineage across code boundaries deterministically, not by vibes.
• Describe your architecture based on the actual shape of the code, not a hallucinated version of it.

That last one is underrated. Half of “the AI got confused” moments happen because the AI never saw the whole picture.

Two Gotchas Before You Install

A couple of things will trip you up, so here they are up front.

The package name has a typo built in. graphify was already taken on PyPI, so the official package is registered as graphifyy. Two y’s. You install it like this:

pip install graphifyy

Watch your Python version. The Leiden community detection library has C-extension limits, so Graphify currently runs best on Python under 3.13. Worth checking or switching to a compatible version (like 3.12) using mise.

The honest appeal here isn’t the visualization, pretty as the HTML map is. It’s that cross-repo dependency tracing has been a manual, error-prone chore for as long as I’ve worked on split codebases, and this makes it a single command.

Sources

• Graphify Labs on GitHub: setup requirements, supported parsers, and CLI options.
• Auriga IT’s Graphify introduction: explains the three-pass architecture and Leiden clustering optimization.
• Graphify on PyPI: package installation details and version compatibility.
• Aider’s Repository Map: on using tree-sitter to parse AST-based codebase maps for token-efficient coding context.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].