The AI coding world is splitting into two camps with fundamentally different philosophies on how to find code, and both strategies are shipping winning products. Three major platforms, including Anthropic's Claude Code and Sourcegraph's Cody Enterprise, publicly abandoned retrieval-augmented generation (RAG), a technique that uses vector databases to search code. Meanwhile, Cursor, GitHub Copilot, and Windsurf doubled down on RAG with increasingly sophisticated implementations. The disagreement reveals something important: code is uniquely difficult to search using traditional AI methods, and there may be no single right answer.

Why Did Three Major Teams Quit RAG at the Same Time?

In late January, Boris Cherny, who leads Claude Code at Anthropic, posted a striking claim on social media: agentic search outperformed RAG "by a lot." He explained that early versions of Claude Code used RAG with a local vector database, but the team found that letting the AI model itself decide where to search worked better. On the Latent Space podcast, Cherny was even more direct, calling the performance gap "surprising" and noting that alternatives like local vector databases and recursive model-based indexing all lost in internal testing.

That same week, Nick Pash at Cline published a blog post titled "Why Cline Doesn't Index Your Codebase," introducing a phrase that became a rallying cry in the coding-agent community: "RAG is a mind virus". His argument centered on a fundamental problem with how RAG handles code. When you break code into chunks for embedding, you tear apart its own logic. A function call might end up in one chunk while its definition sits in another, and the AI model never sees both at once.

Then Sourcegraph, a company with fifteen years of code-intelligence infrastructure, made a public announcement: they were abandoning embeddings entirely at the general availability launch of Cody Enterprise. Their engineering team listed concrete reasons: they didn't want to send customer code to third-party embedding APIs, maintaining vector databases became punishing at scale (over 100,000 repositories per customer), and multi-repository context retrieval never worked reliably. They switched back to BM25, a simpler keyword-based search method, combined with structural search over their existing code graph.

What Made the Other Half Double Down on RAG?

Rather than pivot away from RAG, the other camp accelerated their investments. Cursor shipped a deeply engineered RAG pipeline featuring Merkle-tree-synced chunks, custom code-trained embeddings, and simhash-based index sharing between teammates. GitHub's Copilot Chat relies on Blackbird, a Rust-based code search engine that indexes 115 terabytes of code across 53 billion source files at GitHub scale. Windsurf's entire product positioning centered on the idea that "Cascade reads from the M-Query index before it writes a line". JetBrains' Junie taps into twenty years of compiler-grade static analysis tooling, wiring existing code intelligence directly into the AI loop.

Both architectures are shipping. Both are winning, depending on the user and the use case. The split is real, and the reasons reveal something deeper about how code differs from other types of text.

Why Is Code the Worst Possible Target for Traditional AI Search?

Code breaks traditional AI retrieval methods in three fundamental ways. Understanding these helps explain why the two camps diverged so sharply.

• Structural fragmentation: A function and the code that calls it can live in completely different files. When you chunk those files separately and embed them, the embeddings end up nowhere near each other in vector space. A retriever might confidently return the function definition while missing the caller fifty files away that actually uses it incorrectly.
• Semantic blindness: Words like "throttle" and "Semaphore" mean the same thing in concurrent programming, but embedding models trained on natural language have no idea. When a user asks "where do we throttle requests," the system returns matches for the word "throttle" in comments while completely missing the actual Semaphore-based implementation.
• Staleness at scale: Code changes with every git push. To keep a vector index current, you must detect changes, re-chunk code, re-embed it, reconcile with the existing index, and do all of this fast enough that the index isn't lying by the time the user asks a question. This is the hard problem Cursor solved with Merkle-tree-based incremental indexing, but it's a problem that vanishes if you skip the index entirely.

There's a fourth reason that rarely gets mentioned: security. Code is your most sensitive intellectual property. Sending it to a third-party embedding API, even if the API deletes it after processing, leaves a vector that can sometimes be inverted back to the original code through academic-grade attacks. Cursor acknowledges this risk in their own security documentation. The risk is small, and Cursor mitigates it with privacy mode and path obfuscation, but for enterprise security teams, even a small risk can be disqualifying.

How Do These Two Approaches Actually Work in Practice?

The mechanical difference between the two strategies becomes clear when you trace how each handles a real query. Consider asking an AI to "add rate limiting to the API endpoints" in a 50-file Flask application.

The agentic search approach (used by Claude Code and Cline) is a loop with the model at the center. The AI might make nine tool calls over roughly thirty seconds of wall time. Each step uses the model to decide the next step, so token consumption scales with task complexity, not codebase size. A five-file repository and a fifty-thousand-file repository cost roughly the same if the answer lives in five files.

The RAG approach (used by Cursor, GitHub, and Windsurf) is a pipeline. One retrieval round-trip takes two hundred to five hundred milliseconds, then one language model call. The model never has to decide where to look; the index made that decision. Token cost stays constant per query regardless of repository size.

The catch is critical: if the top search results don't contain the answer, the RAG approach has no fallback except to ask the user for more context or to issue a grep tool call anyway. At that point, you've paid for both architectures.

How to Evaluate AI Coding Tools for Your Workflow

• Task complexity: If you're working on complex refactoring that requires understanding relationships across many files, agentic search may handle the exploration better. If you need fast answers to specific questions about your codebase, RAG's speed advantage matters.
• Codebase size: Agentic search costs scale with task complexity, not repository size, making it potentially cheaper for very large codebases. RAG costs stay constant but require maintaining an index that becomes harder to keep current as code changes.
• Security requirements: If your code is extremely sensitive intellectual property, agentic search avoids sending code to external embedding services. RAG requires either accepting that risk or running embeddings locally, which adds infrastructure overhead.
• Latency tolerance: RAG typically responds faster (under 500 milliseconds) because it skips the model's decision-making loop. Agentic search takes longer but may find better answers by exploring multiple paths.

The split between these two approaches isn't a temporary disagreement that will resolve when one side "wins." Instead, it reflects genuine trade-offs in how to solve a uniquely difficult problem. Code is structural, semantic, and constantly changing in ways that natural language text is not. The fact that three independent teams reached the same conclusion about RAG's limitations, while three other teams shipped increasingly sophisticated RAG implementations, suggests the field has matured enough to support multiple valid architectures.

"Agentic search outperformed RAG by a lot, and the alternatives they tried all lost," said Boris Cherny, who leads Claude Code at Anthropic.

Boris Cherny, Claude Code Lead at Anthropic

The real story isn't that one side is right and the other wrong. It's that the problem of searching code is hard enough that different solutions optimize for different constraints. For developers choosing tools, that means understanding your own priorities: speed versus accuracy, cost versus latency, security versus convenience. The coding-agent market has matured enough to offer genuine choices, each with real trade-offs.