Graphify: Code Knowledge Graphs Without Vectors Boost Agent Accuracy 11%

Graphify is an open-source tool that constructs knowledge graphs from source code repositories using Tree-sitter and abstract syntax tree (AST) parsing, without relying on vector databases or large language models for the initial graph construction. It supports approximately 40 programming languages with varying depth of parsing capability.

Problem: Coding Agents Struggle with Cross-File Dependencies

Current coding agents like Claude Code, Codex, and Cursor have strong code search abilities (grep, file reading, definition/reference queries). However, in large projects, call relationships often span multiple files. Each additional dependency layer may require another round of tool calls and context reading. Vector retrieval helps with semantic similarity but does not guarantee actual call relationships; semantically similar functions may not call each other, and truly related downstream modules may have low text similarity.

Code already contains abundant structural information: function calls, module imports, class inheritance. Graphify extracts this structure upfront to form a continuously queryable code relationship graph, allowing agents to start from a target function and traverse the graph to find related modules before deciding which files to read deeply.

Graph Construction Pipeline

Graphify's architecture organizes graph building as a pipeline:

detect → extract → build → cluster → analyze → report → export

. The system scans files, identifies types, extracts nodes and edges, builds the graph structure with NetworkX, performs community detection and relationship analysis, and finally generates reports and queryable data files. No separate Neo4j or graph database deployment is required.

In the data model, code objects are represented as Nodes (with name, identifier, source file path, code location) and relationships as Edges (source, target, relationship type, confidence). For example, OrderService.cancel_order() calling PaymentService.refund() becomes a calls edge. Cross-file call targets cannot always be determined directly from AST, so Graphify uses symbol resolution and association handling.

Three Relationship Confidence Labels

EXTRACTED : Source code explicitly contains the relationship (direct imports, identifiable calls).

INFERRED : Derived through further parsing, e.g., cross-file call resolution. Note: INFERRED does not necessarily come from an LLM; it may come from a second pass of static analysis.

AMBIGUOUS : Relationship remains uncertain and requires manual verification.

This distinction matters: when an agent analyzes the impact of modifying a public interface, EXTRACTED calls become priority leads, while INFERRED relationships need further source-code cross-checking. Graphify also identifies highly connected nodes and uses Leiden community detection to find tightly coupled modules, helping developers locate relevant subsystems first in large repositories.

Output Files and Query Interface

After graph construction, Graphify provides three main files: graph.json (graph structure), graph.html (interactive browsing), and GRAPH_REPORT.md (summary of key nodes, communities, and relationships to inspect). Code parsing runs entirely locally; unstructured content like design docs or PDFs may use a configured model for semantic extraction but are integrated into the same graph.

Graphify offers three query commands for developers and agents: graphify explain "APIRouter": Shows node location (routing.py:2210), community ID (2), degree (47 connections), and connected objects (e.g., RequestValidationError, Dependant, .get() method, import files). Connections are labeled EXTRACTED or INFERRED, indicating which need verification. graphify path "FastAPI" "ModelField": Returns a three-hop path:

FastAPI → DefaultPlaceholder ← get_request_handler() → ModelField

with uses and references edges. The shortest path reflects identified static relationships, not necessarily runtime call order. graphify query: Retrieves relevant subgraphs via BFS/DFS with budget control (prioritize nearby nodes or deepen along a dependency chain). Current CLI matching relies mainly on node name term matching with IDF, not arbitrary natural language semantic understanding; official Skills attempt to expand queries using actual graph vocabulary before traversal.

Graphify also provides Skill and MCP interfaces to integrate with Claude Code, Cursor, Codex, etc. Agents receive relevant subgraphs, then continue reading files, checking logic, and running tests. Graph queries handle relationship location and context provision; code judgment and modification still require downstream tools.

Comparison with Traditional Vector RAG

Graphify's "no vector database" claim is not just about saving embedding costs; it reflects a different organization of code relationships. Vector RAG relies on semantic similarity (useful for vague queries like "where is rate limiting implemented"). Graphify excels where explicit structural relationships exist: which modules call a function, what a class inherits, how two modules connect via imports/references. For "what might break if I change this function", graph traversal offers a more direct expression because calls, imports, and inheritance are inherent code relationships.

Compared to LLM-based GraphRAG approaches, Graphify uses Tree-sitter to directly obtain syntactic structure from code (which has clear grammar rules), then supplements cross-file relationships via static analysis. This reduces LLM dependency during graph construction and ties relationships to concrete source locations. However, static graphs have gaps: dynamic calls, reflection, dependency injection, runtime configuration, and cross-service messaging may be missed. For vague requirements, non-intuitive naming, or heavy business documentation, text and semantic search remain valuable. Graphify's own long-term memory benchmarks also use local embeddings with hybrid retrieval, so not all gains can be attributed to pure graph traversal.

The recommended practice is letting coding agents choose retrieval tools per task: grep/LSP for known symbols, semantic search for vague needs, graph queries for cross-file dependencies, then verify candidates via source code and tests. Graphify adds a class of relationship information that previously required agents to piece together over multiple search rounds.

Empirical Evaluation on ERPNext (1M Lines)

Graphify's team published internal evaluation on ERPNext, a production-grade ERP of roughly one million lines. A fixed coding agent was given basic tools (grep, read_file, list_dir) plus different code retrieval tools, tasked with answering cross-file technical questions within 14 rounds. Results:

Baseline (grep/read only): 70.8% key fact coverage

Graphify added: 82.0% coverage (+11.2 percentage points)

codebase_memory: 80.5%

CodeGraphContext: 79.2%

claude_context (semantic search): 79.1%

Graphify achieved the highest coverage, though its advantage over other structured retrieval methods is not dramatic.

Cost data: Graphify consumed ~1.3× the tokens of the grep/read baseline, but per-task model cost was nearly identical (~$0.320 vs $0.322). Compared to Repomix (which packs the entire repo into context), Graphify used significantly fewer tokens.

A manual check of 12 cross-file INFERRED relationships in the FastAPI example (AST-only extraction dated 2025-10-05) found all 12 correct. However, this is a limited scope check and does not guarantee equal accuracy across all languages and repositories.

Limitations and Future Outlook

The main test comprised only 6 questions, measuring coverage of preset key facts, not real pull-request modification success rates. Enterprise teams need to verify other metrics: reduction in missed call sites, faster issue localization, graph update timeliness, and test pass rate improvements. Graphify supports incremental updates and file monitoring, but high-commit large repos still require managing consistency between graph versions and code versions.

Graphify represents a technical direction worth watching. Coding agents can already read and modify large codebases, but in complex repositories they still need reliable methods to determine code connections. Graphify chooses to first extract verifiable structural relationships from source code and make them a retrieval entry point for agents. This does not give agents automatic full-system understanding, nor cover all runtime behavior. It provides a more targeted context acquisition method: faced with a large codebase, agents can first follow established relationships to find relevant code, then decide what to read, modify, and verify for impact. Future coding agent code comprehension capability may depend increasingly on how they organize and use structural information from repositories, and Graphify demonstrates one concrete engineering path.

References: Graphify official GitHub repository, Graphify official technical architecture (ARCHITECTURE.md), Graphify official benchmark report, ERPNext cross-tool test and cost details, Graphify Query/Path/Explain official implementation notes.