Greptile Indexes the Codebase, Which Is Necessary and Not Sufficient
Of every commercial tool in the automated review category, Greptile is the one whose architecture sits closest to ours, and it seems worth saying that at the top rather than burying it somewhere near the end where nobody reads.
Greptile was founded in 2023, went through Y Combinator, and raised a 30M at a $180M valuation. The more interesting fact about the company is that it made the correct architectural call very early. Rather than reading only the diff, Greptile indexes the whole repository first and then reviews the change with that index available to it. That single decision is why its reported bug catch rate sits at roughly 82% against CodeRabbit’s 44%, and it produces a genuinely better product.
The number that follows is the one worth thinking about carefully. That 82% arrives alongside roughly 11 false positives per run, against CodeRabbit’s 2.
What 11 false positives per run is actually telling you
A false positive is not a random failure that more engineering effort would sand away. It is a specific kind of mistake, and its shape tells you what the system knows for certain and what it is quietly inferring.
An index built from symbols and call edges can see that function A calls function B, that a type is shared between two modules, and that changing a signature here will ripple outward from there. What it cannot see is whether the ripple matters. It has no way of knowing that the flag guarding this path has been switched off in every environment since March, that this helper has a deprecated twin sitting three directories over, or that the team already decided in a review thread eighteen months ago not to enforce the row limit on this particular endpoint.
Faced with that gap, the system flags everything structurally connected to the change, because structural connection is the strongest signal available to it. Some of those flags describe real problems and some describe coincidences, and the system has no principled way to separate the two. Eleven flags per run is what guessing at intent from structure costs, and it is a reasonable price for a tool that has nothing better to guess from.
This is also where review fatigue comes from, and review fatigue is a more serious failure than any individual missed bug. A reviewer working through 11 flags to find the 2 that matter is performing triage rather than review, and after a few weeks of that, people begin approving past the flags without reading them. The tool then has a good catch rate on paper and very little influence on what actually merges.
The gap is intent, and intent is not in the repository
This is the finding that changed how we think about the entire category, and it comes from outside our company.
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.
That second third is invisible to any system that reads the repository as a data structure, for the straightforward reason that the information is not in the repository. It lives in what the code is for. A symbol graph stores relationships between things. It does not store purpose, and purpose is the thing that decides whether a given structural connection represents a problem or a coincidence. No amount of additional parsing precision reaches information that was never parsed in the first place.
What we do differently, and where we do it
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files. The difference from Greptile is less about what gets computed than about when.
Greptile builds its index with parsers and embeddings, which is cheap, and then performs the expensive reasoning at review time using a frontier model. We invert that order completely. Cheap open source models do real reasoning at indexing time, once, across every file. For each file, an agent works out what the code does, what it promises, what its preconditions are, which contracts it provides, what breaks if it changes, and which files across every other repository depend on it. All of that is written into a graph with a specification layer on top, in plain English, with the file and the line attached to every claim.
We know the alternative configuration from the inside rather than from reading a competitor’s marketing page, because we built it first. In October 2025 we shipped an AST and vector database pipeline served over MCP, watched it fail on accuracy, and threw it away. Vector embeddings measure textual similarity rather than semantic similarity, and those two things get conflated constantly. Ask where the seven day return policy is enforced and you receive files that happen to contain those words, rather than the code implementing the rule, which is usually a comparison of two timestamps inside a validator that names none of it.
Review, in this architecture, becomes a comparison of a change against what each touched file promised at the indexed base, rather than an analysis of what the diff says it changed. That is why the flags come back short and specific instead of long and structural.
The numbers
Indexing costs about 0.89, against roughly 0.11.
Accuracy of code sits above 93%, and token spend drops by roughly 80%. Those two figures move together rather than against each other, which surprises people who assume accuracy is something you buy with tokens. The relationship holds only when the model has to establish what the code means at the moment you ask the question, because then accuracy really is purchased by reading more files. Once meaning is already stored, the model skips that entire chain of dependent inference, and the chain is where both the cost and the errors accumulate.
Two practical constraints worth knowing about
Greptile supports GitHub and GitLab, with no Bitbucket and no Azure DevOps, and its indexing time on very large repositories is a known limit. Neither of those is a design flaw so much as a reflection of company stage, but together they rule the product out for a meaningful slice of large enterprises.
The larger constraint for regulated buyers is deployment. Banking, healthcare, defence and public sector organisations are frequently barred by law rather than by preference from sending source code to a vendor cloud. We run hosted, on dedicated hardware, or fully inside your own network, and on the second two your source never leaves your infrastructure. Access is read only in all three. You also bring your own model keys, whether that means Anthropic, Gemini, OpenAI Codex, DeepSeek, Qwen, Z.ai or anything reachable through OpenRouter.
The honest limitation
Our indexing pass is considerably more expensive than a parser based one, because we are paying a model to reason about every file rather than parse it. On a large estate the first run is a real cost and a real wait, and any vendor who tells you otherwise is describing a product they have not run at that scale. What you get in exchange is that the reasoning never has to be repeated, and only changed files get re-derived on each subsequent commit.
We also do not cover every language. Mojo is not indexed today, and the remaining gaps are the genuinely new and the genuinely rare ones.
This is what ByteBell builds
The comparison worth running takes an afternoon rather than a procurement cycle. Take one incident from the last six months where the breaking change looked clean in review, index the repositories it touched, ask what the blast radius of that change actually was, and see whether the answer names the file that broke.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, which is 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. From then on every engineer, on any copilot, queries the same representation through a single MCP url, and every agent edit gets checked against it before it lands, using per file SHA-256 diffing so only what actually changed is 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.
The first 1,000 files index free, which is enough to answer the blast radius question on a single service.