Coding Agents That Do Not Index Your Code
Almost every AI coding tool builds an index. Chunk the repository, embed the chunks, store the vectors, keep them fresh as files change, retrieve by similarity at query time. It is the reference architecture, it is what the tutorials teach, and Atlarix does none of it. This is the case for the other approach — including where it genuinely loses, because a category argument that admits no cost is marketing.
What an index actually commits you to
An index is not one decision. It is a build step before the tool is useful, an invalidation problem every time a file changes, a storage location that has to live somewhere and be trusted, and a staleness window where the index and the tree disagree.
It also has a shape: retrieval by similarity returns chunks that resemble the query, which is a different thing from the lines that satisfy it. That distinction is invisible when it works and very hard to debug when it does not.
What lexical search gives up
The cost is real and worth stating first. Grep cannot find a concept you did not name. Search for authentication in a codebase that calls it verifyCredentials and you get nothing, while an embedding index has a genuine chance of connecting them.
That is the trade. Anyone telling you lexical search is strictly better is selling something — the question is only whether the trade is worth making on code specifically.
Why it is worth making on code
Code is not prose. Identifiers are shared vocabulary that appears verbatim at the definition and at every call site, which is precisely the case exact matching handles well and similarity handles redundantly.
And the agent is not a search engine. It reads a result, forms a hypothesis and searches again — three sharp greps beat one fuzzy retrieval because the model is doing the semantic work that embeddings were introduced to approximate. The model got good enough that the index became the weaker half of the pair.
What this looks like in practice
Atlarix ships ripgrep and shells out to it per call. There is no state between calls, no daemon, no warm-up and nothing to rebuild when you switch branches. Cloning a repository and asking a question about it is the same operation on the first minute as on the thousandth.
The file that implements it states the constraint in its own header: no symbol index, no relevance rerank, matches in ripgrep's own order. That is a smaller promise than most tools make, and it is one we can keep.
We shipped the index first and removed it
This is not a position we started from. Atlarix carried FTS5, BM25, a ctags symbol tagger, a reranker and a file-watcher, and we published research on the design. On 2026-07-10 we deleted all of it in a single release of 5,246 net lines removed.
The trigger was operational rather than philosophical: the watcher held one file descriptor per watched file on macOS and reached roughly 12,365 on a large repository, at which point the app could no longer spawn subprocesses. We tell that story in full in how we deleted our retrieval index.
The question worth asking a vendor
Not "do you use embeddings" — that is an implementation detail and the answers change quarterly. Ask instead: does a copy of my code exist anywhere after the request finishes, and if so where, for how long, and what invalidates it.
Some tools index locally, some index on their own servers, and some have changed which they do without changing the page describing it. All three are defensible; only one of them is what you assumed if you did not ask.
No index means no build step, no staleness, no storage to secure and nothing to upload — bought with a real loss of conceptual recall that the model itself now largely covers. We ran both architectures in production and chose this one after measuring, which is a stronger reason than having never tried the alternative.