Two philosophies dominate code intelligence right now: vector embeddings and graph traversal. Both are genuinely useful. They answer different questions, make different guarantees, and fail in different ways. Knowing which to reach for is the skill.
What vectors are good at
Vector embeddings capture semantic similarity. If you embed every function in your codebase into a high-dimensional space, functions that do similar things end up geometrically close. A vector search for "parse a JWT token" will find your JWT utility function even if neither the query nor the function uses the word "parse" or "JWT" verbatim.
This is powerful for:
- Finding unfamiliar code by intent ("where do we handle rate limiting?")
- Code completion across stylistic variations
- Identifying duplicate or near-duplicate logic
- Semantic clustering for documentation
What graphs are good at
Graph traversal follows edges, import edges, call edges, inheritance edges. It answers structural questions that have nothing to do with semantic similarity:
- What will break if I change this function? (reachability from changed node)
- What does this module depend on? (transitive import closure)
- Which functions are on the hot path for this endpoint? (call graph slice)
- What modules form a coherent team boundary? (community detection)
These answers are exact, not approximate. They do not depend on how well your code is named or how close the concepts happen to be in embedding space.
The failure modes
Vectors fail on structure: a highly-semantic query will surface code that looks like what you want, but that code might be deprecated, untested, or in a service with very different deployment constraints. The vector has no concept of graph position.
Graphs fail on intent: a graph traversal finds everything reachable from a node, but it cannot rank results by relevance or understand that two structurally separate components serve the same business purpose. You cannot ask a graph "find code similar to this."
Where they combine
The most powerful code intelligence systems use both. The canonical pattern:
- Graph first, compute the structural neighbourhood of the query node (its imports, its callers, its community)
- Vector second, rank the nodes in that neighbourhood by semantic relevance to the query
- Return, the intersection: structurally connected and semantically relevant
This is more useful than either alone. You get results that are genuinely related to your code and ranked by how closely they match your intent.
Spiderbrain follows this model: the structural graph is deterministic and pre-built; semantic weighting is applied at query time on top of the graph structure.
The right question
Before choosing your code intelligence stack, ask: what questions do your engineers actually have?
If the questions are mostly "find code that does X", vectors are sufficient, and the excellent free options (ripgrep + LLM context) are hard to beat.
If the questions are "what breaks if I change X" and "where are the team boundaries in this codebase" and "is this PR structurally safe to merge", you need a graph. Vectors cannot answer those questions.
Most mature engineering teams need both.