Why many code agents use agentic search instead of a vector database

You open a code agent on a repository with half a million lines and ask it to fix the authentication bug. Nothing happens for a few seconds, then it starts firing text searches. No index, no three-minute wait, no vector database container on your laptop. This article explains why that works over code, what each tool actually documents, and where embeddings are still the right answer.

Key takeaways

• Agentic search means the model plans successive queries against the repository instead of querying a vector index once.
• Anthropic documents the trade-off plainly and recommends starting with agentic search.
• Cline does not index by design and said so in May 2025; Sourcegraph removed embeddings from Cody in version 5.3.
• Cursor and Devin Desktop do index and do generate embeddings, and their own documentation says so, which makes the blanket claim false.
• Over heterogeneous prose the conclusion flips: there the vector index still wins, and there are numbers behind that.

What agentic search is, and how it differs from an index

Agentic search is a retrieval pattern where the model issues queries against the real repository, reads the results, and decides the next query from what it has seen. The tools are ordinary ones: search text with regular expressions, list files by pattern, ask the language server where a symbol is defined, read a specific slice of a file.

A vector index works the other way round. Someone splits the code into chunks before any question arrives, turns each chunk into a vector and stores it. When the query comes in, they turn that into a vector too and return the nearest chunks. One pass, with no chance to correct course.

Anthropic describes the difference without softening it, in its article on the agent SDK published on 29 September 2025: "Semantic search is usually faster than agentic search, but less accurate, more difficult to maintain, and less transparent". It follows with an explicit recommendation: "we suggest starting with agentic search, and only adding semantic search if you need faster results or more variations".

What each tool actually documents

This is where the popular story falls apart. We went through the official documentation of the six tools that always get cited, on 30 August 2026, and the result is not uniform.

Two honest caveats about that table. First: docs.windsurf.com today answers with a 308 towards docs.devin.ai, because Windsurf is now documented as Devin Desktop, so Windsurf and Devin are the same case and that case contradicts the popular version. Second: Amp’s documentation not mentioning an index does not prove it has none. It is a closed tool and all we can state is what is written down.

Why grep wins inside a repository

Four reasons, none of them ideological.

The model plans instead of guessing. A vector query resolves in one shot: you turn the question into a vector and take what comes back.

An agent chains attempts. It searches for PaymentFailedError, sees four files, rules out two by their path, opens the third, finds the real exception name and searches again. Every step uses information the first vector never had.

Code is full of exact identifiers. A repository is not prose. It is structured text where a function name is unique and literal.

Lexical search finds TS-999; the embedding finds "documentation about error codes". Anthropic’s own team uses that example when explaining why they mix embeddings with BM25 in their Contextual Retrieval work.

An index ages at the speed of your commits. Cline put it well in May 2025: "An index, by definition, is a snapshot frozen in time. The code inevitably drifts out of sync". In a repository that changes hourly a stale index is not neutral, because it makes the agent propose calls to functions that no longer exist. Cline adds a security argument that rarely gets mentioned, since embeddings are a second representation of your intellectual property that has to live somewhere.

The context window now holds what a targeted search returns. When usable context was a few thousand tokens, compressing the repository into vectors was a necessity. With windows of hundreds of thousands of tokens, twenty grep hits with three lines of context each fit comfortably, and they fit in their original form rather than as sliced chunks.

Where embeddings still win

Worth saying plainly, because the current fashion pushes towards the opposite excess. Cursor published its measurements on 6 November 2025 after adding semantic search to an agent that already had grep, and they are favourable.

Accuracy answering questions about the code rose 12.5%, ranging from 6.5% to 23.5% depending on the model. Retention of generated code rose 2.6% on repositories with more than a thousand files. Their conclusion is that "Semantic search is currently necessary to achieve the best results, especially in large codebases".

Embeddings win when the query is conceptual and the vocabulary does not match. "Where do we handle authentication" contains no string to search for. They also win when the corpus is large and heterogeneous, when you have to bridge languages, or when the material is prose rather than code: tickets, transcripts, internal documentation, contracts.

That distinction matters and should not be generalised. For documents and knowledge bases the approach is the familiar one, and we cover it separately in the hybrid RAG patterns that keep winning, in pgvector on PostgreSQL in production and in enterprise GraphRAG. What this article argues applies to code in a repository and does not carry over to those cases.

What hybrid retrieval means in practice

Hybrid retrieval means keeping two routes to the same content and deciding per query which one to use, or using both and reranking the result. In code, the lexical route is grep over the working tree and the semantic route is an index of chunks. Cursor keeps exactly those two, with Instant Grep for the exact identifier and the index for the natural-language question.

The numbers from the document side help explain why the mix is winning. Anthropic measured that combining contextual embeddings with contextual BM25 cuts the top-20-chunk retrieval failure rate by 49%, from 5.7% to 2.9%. Adding a reranker takes that to a 67% reduction, down to 1.9%. Neither route on its own gets there.

The figure going round, and where it comes from

The claim is that intent to adopt hybrid retrieval has tripled. The figure is real and it belongs to VentureBeat: from 10.3% to 33.3% during the first quarter of 2026, from its own VB Pulse panel.

The small print the same article publishes is worth reading: three consecutive monthly waves at organisations of a hundred employees or more, with between 45 and 58 qualified respondents per month. The editors also warn that the data should be treated as directional. It measures buying intent, not deployments.

That article also reports that Weaviate, Milvus, Pinecone and Qdrant each lost adoption share over the quarter. What it does not contain, and this is worth knowing, is a single mention of Claude Code, Cursor, Windsurf, Devin, Cline or Amp. The list of tools quoted alongside that figure did not come from there.

What to choose today

If you are building an assistant over your own code, start with no index. Give the model a fast text searcher, file listing by pattern, access to the language server and the ability to read specific slices. That is less infrastructure, there is nothing to refresh, and you can read in the trace exactly what it searched for and why.

Add a semantic index when a concrete symptom shows up: the repository is so large that the agent wanders before finding the right place. Add one too when the questions are conceptual rather than literal, or when you need to answer without the working tree in front of you. And if your corpus is not code, this discussion does not apply to you, so go straight to a hybrid approach like the one we describe for deploying an AI agent to production.

Frequently asked questions

Is agentic search the same as RAG?

Not quite. RAG describes any system that retrieves context before generating, agentic search included. What has fallen behind is one specific implementation: splitting the corpus into chunks, turning them into vectors ahead of time and running a single similarity query.

Do I need a vector database to work with a code agent?

For code inside a repository, hardly ever at the start. Claude Code documents no vector tool and Cline avoids one on purpose. If you later find the agent taking too long to locate the right place, that is when adding an index earns its keep.

Did Cursor stop indexing code?

No. Its documentation describes Instant Grep for exact matches and its engineering blog defends semantic search with its own numbers. Cursor combines both routes, which is precisely the hybrid model.

Conclusion

The short version going round, that code agents have abandoned vector databases, is true in two cases, false in two and unverifiable in one. What the documentation of all of them does support is something more measured. Over code, the first tool worth handing a model is a fast text searcher and the freedom to chain queries. The vector index is a later reinforcement, with a real maintenance cost.

Over prose, the order reverses. The Spanish version of this article is at Por qué muchos agentes de código usan búsqueda agéntica.

Sources

1. Anthropic, building agents with the Claude Agent SDK
2. Claude Code, tools reference
3. Cursor, improving agent with semantic search
4. Cline, why Cline does not index your codebase
5. Devin Desktop, remote indexing
6. Sourcegraph, Cody FAQ on embeddings
7. VentureBeat, the retrieval rebuild
8. Anthropic, Contextual Retrieval
9. Cursor, search tools documentation