Retrieval Integration

## Two search primitives, two guarantees Lexical search — grep, ripgrep, glob, a directory listing — matches characters. Ask it for `import requests` and it returns every line in the tree containing that string, with path and line number, read from the bytes on disk at this moment. It knows nothing about meaning: `import httpx` will not match however similar the intent is. Its recall on the literal pattern is total; its precision is whatever the pattern deserves. Dense retrieval maps text into vectors and returns the k nearest neighbours of the query vector. It finds passages that mean something similar even when they share no words — but it can never promise completeness. Approximate nearest-neighbour search is approximate by construction, k is a cutoff you chose, and the vectors were built from a snapshot of the corpus taken at index time. Those two guarantees — completeness on a literal string versus tolerance of unknown wording — are the whole decision. ## Why coding agents drifted toward grep As of mid-2026, filesystem and grep-based search has largely displaced embedding indexes as the default retrieval path inside coding agents. Four properties of a code repository drive that. **The queries are literal.** Symbol names, imports, error strings, environment-variable names, config keys. The agent usually knows the exact token it is hunting, or can guess a small family of spellings. **The task demands completeness.** An agent moving a 12,000-file repository off one HTTP client cannot accept "here are the twenty most relevant files". A missed call site is a broken build, not a slightly worse answer. Grep is also auditable: you can count matches, count edits, and compare. **The corpus mutates constantly.** Every commit, every branch switch, every edit the agent itself makes invalidates part of an index. Keeping vectors current means a rebuild pipeline whose failure mode is silent — stale hits that look entirely plausible. **The tree is already an index.** Directory layout, naming conventions, tests sitting beside sources: a glob narrows the search space cheaply, with no build step and no drift. ## Where embedding search still wins The moment the query is conceptual and the vocabulary is unknown, lexical search collapses. "Where do we decide whether a refund is allowed" finds nothing when the code names it `eligibility_gate`. Prose corpora — policy documents, incident write-ups, support tickets, meeting notes — express one idea in many phrasings, which is exactly the case dense retrieval was built for. Paraphrase, synonymy, typo tolerance and cross-language matching all belong to it. Serious systems over prose keep both lexical and dense scoring rather than choosing. ## Choose per query, not per system The context-engineering framing is that retrieval is one tool among several the model may call: glob to narrow, grep for exact matches, a directory listing to orient, semantic search when the wording is unknown, a file read to pull the span it actually needs. Each tool's description has to say *when it wins*, because the model's selection accuracy is only as good as the descriptions it is given. A practical ladder looks like: glob the likely subtree, grep the exact identifier, widen the pattern, fall back to semantic search, then read only the lines that matter. ## The token-budget argument Grep output is a list of pointers — path, line number, the matched line — not content. That fits the just-in-time principle: carry a lightweight identifier and load the material when it is needed. Dense retrieval returns whole chunks, and you pay for every one of them whether the model uses it or not. Across a long session that is the difference between a few hundred tokens spent to locate work and tens of thousands spent to maybe locate it. ## Failure modes on both sides Grep fails loudly and quietly. Loudly when a broad pattern floods the window with thousands of hits — count first, list filenames only, then narrow. Quietly when a narrow pattern returns nothing and the agent concludes the code does not exist, having missed aliased imports, dynamic dispatch, generated files or a different spelling. Dense retrieval fails by staleness, by chunk boundaries slicing a function in half, and by returning confident near-matches with no signal that the true answer was never in the index. ## What the interviewer is listening for Not a slogan. The rule: exactness and completeness point to lexical search; unknown wording and paraphrase point to dense retrieval; a volatile corpus penalizes any index; the choice is made per query with an explicit fallback ladder; and on a prose corpus the default flips. A candidate who says "we embed everything" for a repository, or "grep is enough" for a policy corpus, has answered a query-level question at system level.