Code graph vs RAG: What's the difference for AI coding agents?

What is vector-based RAG?

Retrieval-augmented generation (RAG) over a codebase typically works by splitting source files into chunks, embedding those chunks as vectors, and retrieving the chunks whose vectors are closest to a query's vector. It answers the question “what text in this repository reads like this query?”

Strengths. Vector RAG is strong at semantic similarity: finding code, comments, commit messages or documentation that discuss a concept in different words than the query used. It requires no explicit schema of the codebase's structure, generalizes across languages, and works well for natural-language questions such as “where is retry logic discussed?”

Weaknesses. Because similarity is computed over text, not code semantics, RAG can only reach exact relationships, a specific caller, a specific import, a dependency chain, indirectly, by hoping the relevant chunk happens to be textually similar enough to surface. It has no native concept of “traverse from this function to everything that calls it.”

When to choose it. Use vector RAG when the question is conceptual or documentation-shaped rather than structural, for example, understanding intent, finding prior discussion, or locating code that is thematically related but not directly connected.

What is a code graph?

Strengths. A code graph is strong exactly where RAG is indirect: exact call relationships, imports, inheritance and dependency traversal are represented as explicit edges rather than inferred from text similarity. Graph traversal is native: “everything that calls this function” or “everything this module imports” is a direct query, not an approximation.

Weaknesses. A code graph, on its own, is not well suited to natural-language or documentation-style questions. It represents structure, not prose, so a graph alone is limited for a query like “where is this concept discussed?” unless it also incorporates text.

When to choose it. Use a code graph when the task depends on understanding exact relationships between code entities: who calls what, what depends on what, what a change would affect.

Capability comparison

When to combine them

The strongest context systems may combine semantic and structural retrieval.

Neither approach makes the other obsolete. A conceptual question (“where is payment retry logic discussed?”) is often better served by semantic search across text. A structural question (“what calls processPayment()?”) is often better served by an explicit graph traversal. Many real coding-agent tasks contain both kinds of sub-questions, which is why a system that can draw on both semantic similarity and explicit relationships has more to work with than one relying on either alone.

Relationship to CodeMesh

CodeMesh's retrieval is built on structural repository intelligence: it parses a repository into entities and relationships (functions, classes, imports, calls, dependencies) and answers an agent's questions from that structure, rather than from a vector index of chunked text. That makes CodeMesh a code-graph-style approach in this comparison, not a RAG replacement or a claim that vector search is unnecessary in general. Vector-based RAG remains a valid, widely-used technique for the class of questions it is good at.