AI
Simple grep-style code search outperforms complex AI retrieval for repository completion
Researchers show that lightweight lexical search can match or beat sophisticated graph-based systems for helping LLMs complete code across large repositories.
When large language models try to complete code across multiple files in a repository, they face a fundamental problem: their context windows are limited, and they lack easy access to dependencies scattered throughout the codebase. The standard solution has been Retrieval-Augmented Generation (RAG)—systems that use semantic indexing or graph analysis to pull in relevant code before the LLM generates completions. But these approaches carry a price: they're computationally expensive to build and maintain.
A new arXiv paper from researchers including Baoyi Wang asks a simpler question: what if you just let the LLM search the codebase the way developers do—using lightweight tools like ripgrep?
The Case for Simple Search#
The team started with Naive GrepRAG, a basic framework where LLMs autonomously generate ripgrep commands (a fast command-line search utility) to retrieve relevant code. The results were striking: this no-frills approach performed as well as much more sophisticated baselines relying on graph-based analysis.
The win came from a key insight: lexical retrieval captures code fragments that are both precise in keyword matching and physically close to the completion site—often exactly what's needed. The approach bypasses the overhead of building and maintaining semantic indices entirely.
Where Simple Search Breaks Down#
Yet the researchers also documented real limitations. Lexical retrieval struggles when codebases use common, ambiguous keywords that appear everywhere—these high-frequency terms flood results with noise. Additionally, truncating long contexts at rigid boundaries fragments important code structure, losing semantic coherence.
A Lightweight Fix#
To address these gaps, the team introduced GrepRAG, which wraps the basic grep search in a lightweight post-processing layer:
- Identifier-weighted re-ranking: Deprioritizes matches containing overly common keywords, focusing the LLM's attention on more distinctive code references
- Structure-aware deduplication: Removes duplicate or fragmented matches while preserving the overall shape of relevant code blocks

