Serena Knows Every Symbol in Your Codebase and None of the Meaning
Serena is the tool we would recommend to anyone who wants symbol level precision for an agent and has no interest in paying for it. Roughly 25,200 stars, MIT licensed, more than 170 contributors, built by Oraios AI in Munich, covering over 40 languages. It wraps the Language Server Protocol and exposes it over MCP, so an agent can find a definition, list references, and edit at symbol granularity rather than blindly rewriting whole files.
That last capability is consistently underrated. Symbol level editing is a real accuracy improvement over an agent regenerating a file and hoping it did not clobber something on the way through, and it removes an entire category of silent damage. Serena earned its position and the design is clean throughout.
What it gives you is the thing your IDE already gives you, made available to a model. The question worth asking is whether that is the thing agents are actually missing.
What a language server knows, and what it does not
An LSP index is deterministic and precise, which is its great virtue and the reason it will always beat a model on the questions it was built for. It resolves a symbol to its definition, enumerates every reference, understands scope, and does all of that fast enough to run interactively while somebody types.
Here is the complete list of what it does not know, none of which are bugs and none of which will be fixed in a future release. It does not know why the function exists. It does not know that the flag guarding this path has been off in every environment since March. It does not know that there are three implementations of the same thing in this repository, one live, one sitting behind a flag that never turned on, and one waiting to be deleted. It does not know that a review thread two years ago decided not to enforce the row limit here. It does not know that the mobile client decodes this payload strictly, so an added field fails the parse there and nowhere else in the estate.
An abstract syntax tree tells you what calls what, and it never tells you what any of it is for. That is the boundary of the symbol level approach, and it applies to Serena exactly as it applies to every other tool in that family, including the parts of our own system that are built the same way.
Why intent is the thing that is missing
The evidence for this is not ours, which is the main reason to take it seriously. In the MSR 2026 dataset of agentic pull requests rejected by maintainers, only about 36% reflected a clear failure in the agent’s code. Another 31% were rejected because the contribution violated a workflow constraint or a decision the project had already taken, and that context does not live in the repository at all.
Roughly a third of failures are failures of intent rather than failures of syntax or structure. No amount of language server precision touches that third, because the information was never in the symbol table to begin with.
There is a related problem with the questions people actually ask. Where is the seven day return policy enforced. Which code decides whether a subscription counts as active. Why is tax calculated twice on some invoices. Which services implement the buyback flow. None of those questions names a symbol. They name a business rule, and mapping a business rule onto the functions that implement it requires that somebody or something has read the code and worked out what it was doing.
What we store instead
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files, and the index is not a symbol table.
Cheap open source models read every file once at indexing time. An agent detects the boundaries of classes, functions and every other element of the language, stores those elements separately, and then analyses each one in the context of its file, its module, its repository, and across every repository. The output for a single file includes 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 provides, its preconditions, its callers and callees, and the specific point where its behaviour is genuinely ambiguous.
On a real store adapter file, the layer records that identity is used as the default selector and the complete store state comes back, and separately flags that it is unclear which equality function applies when neither a per call nor a default one is supplied, because that is what decides the equality semantics. A language server can name every caller of that function without hesitation. It has no field in which to record that the semantics are undecided, and that ambiguity is exactly the thing a reviewer needs flagged before a change lands on top of it.
Every claim carries the file and the line it came from, so verifying any single statement takes about 10 seconds.
The economics of reading once
Serena is free, and free is a genuine advantage that we are not going to argue away. Our layer costs about $13 per 1,000 files to index, once, with only changed files re-derived on each commit.
What that buys is a different cost curve on the other side of the transaction. In a symbol level flow, the agent still has to read the actual code to work out what it means, so the expensive reading happens at question time and recurs on every question forever. In the layer flow, a query touches a handful of pre-digested graph nodes. On a traced run, tracing a change across 32 impacted files in 4 repositories took 4 minutes 9 seconds and cost 30 for the same work by brute force. A full test generation and review pass came to 87,001 tokens at $0.11.
Accuracy of code holds above 93% while token spend drops by roughly 80%. Once an organisation is running 50 questions a day across 100 repositories, the one time index cost is smaller than what a symbol level flow spends in a fortnight, and the gap widens from there.
Our own core is open as well. The MCP server and the ingestion engine are open source, and the free tier indexes 1,000 files with no card and no feature held back.
Where Serena is the right choice
If you work in one repository, want fast and deterministic symbol navigation for your agent, and have no appetite for an indexing step or a bill, Serena is the better fit and you should use it. Symbol level editing is genuinely safer than file rewriting, and 40 language coverage from an open source project with 170 contributors is an achievement that deserves more attention than it gets.
The two approaches also compose well. Precise symbol resolution and a derived specification layer answer different questions, and an agent holding both is better off than one holding either.
The honest limitation
Our layer is derived by models and a language server is not, which means ours can be wrong in ways an LSP structurally cannot. Precision on call edges is one thing Serena will do better than us, permanently, because it is reading the compiler’s own view rather than inferring anything. We handle that by attaching a file and a line to every claim so nothing has to be taken on trust, and by re-deriving 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 indexed today.
This is what ByteBell builds
The test worth running is small. Take the last pull request your team rejected for a reason that was not a bug, ask a symbol level tool why that change was wrong, then ask a layer that stored what the code was for. The gap between those two answers is the third of the problem that nobody in the symbol level family is solving.
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, 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.