Repo Wikis vs a Live Code Graph

Hand an agent a repository it has never seen and the cheapest useful thing you can give it is a map. Generated repo wikis are good at making one. DeepWiki turns any public GitHub repository into a browsable wiki by swapping the domain in the URL, and the homepage promises "AI documentation you can talk to, for every repo" (deepwiki.com). No login for public code, three MCP tools so an agent can read the wiki without a human in the loop, and a price of zero. For orientation that is a good deal.

The split shows up later, when the agent stops reading and starts editing.

What a generated wiki gets right

A wiki is a compression of a codebase into topics a person can hold in their head. Someone new to a project wants to know what the major pieces are called, which one owns bookings, where the API surface lives. Prose answers that well because the question is about meaning, and meaning is what prose carries.

DeepWiki's MCP tool set describes its own shape precisely. It exposes read_wiki_structure ("Get a list of documentation topics for a GitHub repository"), read_wiki_contents ("View documentation about a GitHub repository"), and ask_question ("Ask any question about a GitHub repository and get an AI-powered, context-grounded response") at https://mcp.deepwiki.com/mcp, with no authentication for public repositories (Devin docs, DeepWiki MCP). Three documentation verbs: list the topics, read the docs, ask about them. An agent that calls those arrives at a task knowing roughly where things live, which beats arriving blind.

The question that falls through

Then the agent picks up a ticket, opens a file, and the question changes from "what is this" to "if I change this line, what else has to change with it."

That second question has an exact answer, and the answer is a set of relationships: the call sites that reach this symbol, the symbols downstream of those call sites, the tests standing over them. A wiki can describe a module accurately and still leave that set entirely unstated, because the set was never what the document was written to hold. Ask a wiki who calls a function and you get an answer synthesized from prose about the area the function lives in. Sometimes that is right. You cannot tell from the answer whether it is.

Two answers to the same question in cal.com

Here is the shape of it in a repository anyone can open. Cal.com keeps its server-side translation loading in packages/i18n/server.ts, and near the top of that file sits an eight-line helper:

export function mergeWithEnglishFallback(localeTranslations: Record<string, string>): Record<string, string> {
  return {
    // IMPORTANT: Spread English translations first to provide fallback for missing keys
    ...englishTranslations,
    // Then spread locale translations to override English when keys exist in both
    ...localeTranslations,
  };
}

Suppose you want to change how that merge behaves, so an empty string in a locale file stops shadowing the English default. Small function, clear intent, two dozen characters of edit.

The wiki page for that directory will tell you it loads locale bundles, caches them, and merges them over the English defaults. That is correct, and it is the same paragraph before and after you ask your question.

Now the graph answer, measured against cal.com at commit 8418db7. mergeWithEnglishFallback has 2 callers: its own test file, and loadTranslations one function below it. If callers were the whole story you would ship the edit in a minute. Its blast radius, walked outward from those two, is 30 symbols across 30 files, and the names in that set are the ones you would want on the review: the app's RootLayout, four booking ServerPage entries under apps/web/app, confirmHandler, the seated-booking reschedule path, the CRM calendar-event builder. The public entry point in the same file, getTranslation, carries 46 callers and a blast radius of 49, and that one crosses into the API layer.

The gap between 2 and 30 is the whole argument. Two callers reads as a safe local edit. Thirty downstream symbols, several of them user-facing booking pages, reads as a change that wants a second pair of eyes. Both numbers describe the same eight lines. Only one of them changes what you do next.

Generation time and question time

There is a second difference underneath the first, and it matters more over a long project.

A wiki is written at generation time. Your question arrives later. Everything in between, every merge, every rename, every new caller someone added on Tuesday, sits in that gap. Wikis handle this with refresh: repositories that add a DeepWiki badge get regenerated when the code changes (CognitionAI/deepwiki). Refresh shortens the gap and cannot close it, because a document is a thing produced once and read many times.

A graph query runs at question time. relate walks edges that were parsed from the code as it stands on the revision you are pointed at, which is why the same call against a feature branch returns that branch's callers. The answer is computed for the question rather than retrieved from a document that anticipated it. This is the same distinction we drew for retrieval in code embeddings vs code graph: similarity finds text that reads like your query, traversal finds code that is connected to your symbol.

Reading work and editing work

The practical way to hold this: sort the work by whether the agent is about to write.

Reading work is orientation, dependency triage, understanding a library you did not author, writing a design doc, answering "how does this project do auth." Prose is the right output shape, a public wiki costs nothing, and DeepWiki is very good at it. Point an agent there for open-source dependencies and it will save you real time.

Editing work is renames, signature changes, deletions, migrations, anything where being wrong means a broken build or a silent behavior change in production. Here the useful output is a list of edges with file paths and line bounds the agent can act on: what breaks when you change a function is the shape of that question, and a graph is the thing built to answer it.

Most agent sessions contain both, and the division that holds up is simple: the wiki for the dependency you did not write, the graph for the code you own.

Known limits

A parsed graph sees what the parser can resolve. Dynamic dispatch through a string-keyed registry, a handler wired up by configuration, a call made through reflection: those edges are weak or absent, and blast radius understates the true reach in codebases that lean on them heavily. Fan-in is also not proof of breakage. Thirty downstream symbols means thirty symbols sit on a path through the thing you are changing, and many of them will pass through your edit untouched. The number sizes the review; it does not do the review.

The wiki has the opposite blind spot and the opposite strength. It can tell you a module exists because of a migration that is half finished, which no edge in any graph encodes. It also indexes public repositories that you have not connected to anything, which is exactly why it is the fast answer for a dependency.

Symvanta indexes your own code and hands your agent the graph over MCP: callers, dependencies, blast radius, cross-repo edges, branch-aware. If you want the tool-by-tool version against DeepWiki specifically, that is on the DeepWiki alternative page. If you want to see the numbers above computed against a repository you actually maintain, that takes about fifteen minutes. Book a 15-minute demo