Sourcegraph Answers Where the Code Is. Agents Need to Know Why It Exists
Sourcegraph has spent more than a decade building code intelligence for large organisations, and what came out of it is the most complete cross repository code search anyone has shipped. Precise go to definition, find references across hundreds of repositories, structural search, batch changes across an entire estate. If your question is where a symbol lives and who calls it, nothing on the market does that better.
The reason it is now insufficient has nothing to do with the quality of the engineering, which is excellent and has been for years. What changed is who is asking the question.
What code search was built for
Sourcegraph’s index is built on language servers, SCIP and LSIF data, and structural parsing. It resolves symbols to definitions with genuine precision and does so across every repository in the organisation. Cody sits on top of that index and uses it to assemble context for a language model.
The design assumption underneath the whole system is a human in the loop, and for fifteen years that assumption was correct. A person types a query because they already hold a hypothesis. They read the results and discard the irrelevant ones instantly, notice that one file is the deprecated implementation, remember that the flag guarding this path never turned on, and pull the two results that matter into working memory. The index supplies the location of things. The engineer supplies all of the meaning, so quickly and so unconsciously that it never appears as a step in anybody’s architecture diagram.
That division of labour stops working the moment the thing asking the question is an agent with no memory of your system and no way to recognise a wrong result when it sees one.
What breaks when an agent asks
An agent handed a set of search results must first establish what those results mean before it can decide anything at all. That turns one question into a long chain of dependent steps: read a file, form a hypothesis, search again to check it, read three more files, revise. Each step can go wrong, and the context accumulating behind it degrades per step accuracy at the same time, so the errors and the cost grow together.
The second problem is arithmetic rather than architecture. At a conservative 1,000 tokens per source file, 10 million files is roughly 10 billion tokens of code. A 200,000 token context window holds 0.002% of that. A 1 million token window holds 0.01%. A 10 million token window holds 0.1%. The gap is four orders of magnitude, and no announced roadmap closes it.
So the agent performs repeated retrieval into a window that will never hold the system, and pays for every retrieval it performs. The bill scales with the size of the codebase and with the number of questions asked, which is precisely the wrong direction for a company running a hundred repositories and fielding fifty questions a day.
The third problem is the one search cannot address at all. Symbol level tools read the repository the change lives in, and even a cross repository search returns files rather than consequences. Ask what breaks if you rename a field and search will hand back every occurrence of the string. It will not tell you that the mobile client decodes the payload strictly, so an unknown field fails the parse there and nowhere else in the estate.
What the layer stores instead
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files. The index is not a map of symbols. It is a compiled statement of what the code means.
Cheap open source models read every file once at indexing time. For each file, an agent produces a summary of what the module does, the business context of why it exists and what users lose if it fails, the system capabilities it provides, its edge cases, the contracts it offers, its preconditions, and the exact point where its behaviour is genuinely ambiguous. Every one of those claims carries the file and the line it came from. All of it goes into a single graph with a specification layer on top.
Here is what that produces on a real file. For a store adapter module, the layer records that it adapts a vanilla store interface to React, that it supports reactive state management, that if it fails components stop subscribing efficiently and users see stale or excessive renders, that identity is used as the default selector, and that one question remains unresolved about which equality function applies when neither a per call nor a default one is supplied. That last item is the kind of thing a search index has no field for, and it is precisely what a reviewer needs to be told.
A query against that layer touches a handful of pre-digested graph nodes rather than dumping raw files into a context window. It also answers a class of question that is not about location at all. Where do we charge the customer, end to end. Which business rules does this function implement. What is the blast radius of removing this API field across every repository. How many engineering hours will this feature take, derived from the number and complexity of the affected components rather than from somebody’s instinct in a planning meeting.
The cost difference, and why it is structural
In the search based flow, the expensive reading happens at question time, every single time. In the layer based flow it happens once, at indexing time, on cheap open source models.
Indexing runs about 0.89, against roughly $30 for the same work without the layer. Accuracy of code holds above 93% while token spend drops by roughly 80%, which is how the layer manages to decrease AI cost and raise correctness in the same pass rather than trading one against the other.
Because centralised providers charge per token, brute force retrieval becomes more expensive with every question anybody asks. Cost per question against a prebuilt layer stays close to flat, and that difference compounds over a year in a way that a per query comparison never shows.
Where Sourcegraph stays the better tool
For a human engineer navigating a large and unfamiliar estate, precise cross repository symbol search remains the right instrument, and we would not want to work without one. Batch changes across hundreds of repositories is a genuinely hard problem that Sourcegraph solved properly and that nobody else has matched. These are complementary rather than competing products, and because the layer is served over MCP, whatever tool you already use can read it.
The honest limitation
A language server is deterministic and our layer is derived by models, which means ours can be wrong in ways a parser structurally cannot. That is why every claim in the layer carries the file and the line it came from, so checking any single statement takes about 10 seconds rather than an act of trust. It also means the index has to be re-derived as code changes, which we do on every commit, though there is a window after a push where a claim can lag the branch.
We also do not cover every language yet. Mojo is not supported today.
This is what ByteBell builds
The question worth putting to your own estate is narrow enough to answer in an afternoon. Pick the last change that broke something in a repository nobody thought to test. Search will tell you every file that mentioned the symbol. Ask instead which of those files was depending on the behaviour that changed, and see which tool in your stack can answer.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, a one time pass where a model reads every file and lowers it into a verifiable code IR capturing purpose, business context and cross repository relationships, on your own infrastructure through Docker, with your source never leaving your environment. Every engineer, on any copilot, then queries the same representation through a single MCP url, and every agent edit is checked against it before it lands, using per file SHA-256 diffing so only what actually changed gets examined again. Across 46 Kubernetes ecosystem repositories and 150,000 files we measured roughly 10% higher accuracy at 70% lower cost, on about a fifth of the tokens.