Por qué muchos agentes de código usan búsqueda agéntica y no una base vectorial

Abres un agente de código en un repositorio de medio millón de líneas y le pides que arregle el fallo de autenticación. No pasa nada durante unos segundos y luego empieza a lanzar búsquedas de texto. Ni un índice, ni una espera de tres minutos, ni un contenedor de base de datos vectorial en tu portátil. Este artículo explica por qué esa forma de trabajar funciona sobre código, qué documenta de verdad cada herramienta y en qué casos los embeddings siguen siendo la respuesta correcta.

Puntos clave

• La búsqueda agéntica consiste en que el modelo planifique consultas sucesivas contra el repositorio en vez de consultar una vez un índice de vectores.
• Anthropic documenta la comparación sin adornos y recomienda empezar por la búsqueda agéntica.
• Cline no indexa por decisión de diseño y lo publicó en mayo de 2025; Sourcegraph retiró los embeddings de Cody en la versión 5.3.
• Cursor y Devin Desktop sí indexan y sí generan embeddings, y su propia documentación lo dice, así que la afirmación de que ninguna herramienta indexa ya es falsa.
• Sobre prosa heterogénea la conclusión se invierte: ahí el índice vectorial sigue ganando, y hay cifras que lo respaldan.

Qué es la búsqueda agéntica y en qué se diferencia de un índice

La búsqueda agéntica es un patrón de recuperación en el que el modelo emite consultas contra el repositorio real, lee los resultados y decide la siguiente consulta a partir de lo que ha visto. Las herramientas son las de siempre: buscar texto con expresiones regulares, listar ficheros por patrón, pedirle al servidor de lenguaje dónde está definido un símbolo y leer un fragmento concreto de un fichero.

El índice vectorial funciona al revés. Alguien parte el código en fragmentos antes de que llegue ninguna pregunta, convierte cada fragmento en un vector y lo guarda. Cuando llega la consulta, la convierte también en un vector y devuelve los fragmentos más próximos. Una sola pasada, sin oportunidad de corregir el rumbo.

Anthropic describe la diferencia sin suavizarla en su artículo sobre el SDK de agentes, publicado el 29 de septiembre de 2025: "Semantic search is usually faster than agentic search, but less accurate, more difficult to maintain, and less transparent". Y remata con una recomendación explícita: "we suggest starting with agentic search, and only adding semantic search if you need faster results or more variations".

Qué documenta realmente cada herramienta

Aquí es donde el relato que circula se rompe. Revisamos la documentación oficial de las seis herramientas que se citan siempre, el 30 de agosto de 2026, y el resultado no es uniforme.

Dos precisiones honestas sobre esa tabla. La primera: docs.windsurf.com responde hoy con un 308 hacia docs.devin.ai, porque Windsurf pasó a documentarse como Devin Desktop, así que Windsurf y Devin son el mismo caso y ese caso contradice la versión popular. La segunda: que la documentación de Amp no mencione un índice no demuestra que no lo tenga. Es una herramienta cerrada y lo único que podemos afirmar es lo que está escrito.

Por qué el grep gana dentro de un repositorio

Cuatro razones, y ninguna es ideológica.

El modelo planifica en lugar de adivinar. Una consulta vectorial se resuelve de una vez: conviertes la pregunta en un vector y aceptas lo que salga.

Un agente encadena intentos. Busca PaymentFailedError, ve que aparece en cuatro ficheros, descarta dos por la ruta, abre el tercero, encuentra el nombre real de la excepción y vuelve a buscar. Cada paso usa información que el primer vector no tenía.

El código está lleno de identificadores exactos. Un repositorio no es prosa: es texto estructurado donde el nombre de una función es único y literal. La búsqueda léxica encuentra TS-999 y el embedding encuentra "documentación sobre códigos de error". El propio equipo de Anthropic usa ese ejemplo al explicar por qué mezclan embeddings con BM25 en su trabajo sobre Contextual Retrieval.

Un índice envejece a la velocidad de tus commits. Cline lo formuló bien en mayo de 2025: "An index, by definition, is a snapshot frozen in time. The code inevitably drifts out of sync". En un repositorio que cambia cada hora, el índice desactualizado no es neutro: hace que el agente proponga llamadas a funciones que ya no existen. Y añade un argumento de seguridad que rara vez se menciona, porque los embeddings son una segunda representación de tu propiedad intelectual que hay que guardar en alguna parte.

La ventana de contexto ya sostiene lo que devuelve una búsqueda dirigida. Cuando el contexto útil eran unos pocos miles de tokens, había que comprimir el repositorio en vectores por pura necesidad. Con ventanas de cientos de miles de tokens, veinte resultados de grep con tres líneas de contexto cada uno caben de sobra, y caben en su forma original en vez de como fragmentos troceados.

Dónde siguen ganando los embeddings

Conviene decirlo claro, porque la moda actual empuja al exceso contrario. Cursor publicó el 6 de noviembre de 2025 sus mediciones tras añadir búsqueda semántica a un agente que ya tenía grep, y son favorables.

El acierto al responder preguntas sobre el código sube un 12,5 %, con un rango del 6,5 % al 23,5 % según el modelo. La retención del código generado sube un 2,6 % en repositorios de más de mil ficheros. Su conclusión es que "Semantic search is currently necessary to achieve the best results, especially in large codebases".

Los embeddings ganan cuando la consulta es conceptual y el vocabulario no coincide. "Dónde manejamos la autenticación" no contiene ninguna cadena que buscar. Ganan también cuando el corpus es enorme y heterogéneo, cuando hay que cruzar lenguajes o cuando el material no es código sino prosa: incidencias, transcripciones, documentación interna, contratos.

Esa distinción importa y no se debe generalizar. Para documentos y bases de conocimiento el planteamiento sigue siendo el de siempre. Lo tratamos aparte en los patrones de RAG híbrido que siguen funcionando, en pgvector sobre PostgreSQL en producción y en GraphRAG dentro de una empresa. Lo que se explica aquí vale para código en un repositorio y no se traslada a esos casos.

Qué significa recuperación híbrida en la práctica

Recuperación híbrida significa mantener dos caminos hacia el mismo contenido y decidir por consulta cuál se usa, o usarlos a la vez y reordenar el resultado. En código, el camino léxico es grep sobre el árbol de trabajo y el camino semántico es un índice de fragmentos. Cursor mantiene exactamente esas dos vías, con Instant Grep para el identificador exacto y el índice para la pregunta en lenguaje natural.

Las cifras del lado documental ayudan a entender por qué la mezcla se impone. Anthropic midió que combinar embeddings contextuales con BM25 contextual reduce la tasa de fallo de recuperación entre los veinte mejores fragmentos un 49 %, del 5,7 % al 2,9 %. Añadir un reordenador la lleva a una reducción del 67 %, hasta el 1,9 %. Ninguna de las dos vías por separado alcanza eso.

La cifra que circula, y de dónde sale

Se repite mucho que la intención de adoptar recuperación híbrida se ha triplicado. La cifra existe y es de VentureBeat: del 10,3 % al 33,3 % durante el primer trimestre de 2026, según su propio panel VB Pulse.

Merece la pena leer la letra pequeña que el mismo artículo publica: tres oleadas mensuales consecutivas en organizaciones de cien empleados o más, con entre 45 y 58 respuestas cualificadas por mes. La redacción advierte además de que los datos deben tomarse como direccionales. Mide intención de compra, no despliegues.

Ese artículo añade que Weaviate, Milvus, Pinecone y Qdrant perdieron cuota de adopción durante el trimestre. Lo que no contiene, y conviene saberlo, es una sola mención a Claude Code, Cursor, Windsurf, Devin, Cline o Amp. La lista de herramientas que se cita junto a esa cifra no procede de ahí.

Qué elegir hoy

Si estás montando un asistente sobre tu propio código, empieza sin índice. Dale al modelo un buscador de texto rápido, un listado de ficheros por patrón, acceso al servidor de lenguaje y la capacidad de leer trozos concretos. Es menos infraestructura, no hay nada que refrescar y puedes leer en la traza exactamente qué buscó y por qué.

Añade un índice semántico cuando aparezca un síntoma concreto: el repositorio es tan grande que el agente da demasiadas vueltas antes de encontrar el sitio. También si las preguntas son conceptuales más que literales, o si necesitas responder sin el árbol de trabajo delante. Y si tu corpus no es código, esta discusión no te afecta: ve directamente a un planteamiento híbrido, como el que describimos en RAG 2.0 y grafos de conocimiento.

Preguntas frecuentes

¿La búsqueda agéntica es lo mismo que RAG?

No exactamente. RAG describe cualquier sistema que recupera contexto antes de generar, incluida la búsqueda agéntica. Lo que se ha quedado atrás es una implementación concreta: partir el corpus en fragmentos, convertirlos en vectores por adelantado y hacer una única consulta de similitud.

¿Necesito una base de datos vectorial para trabajar con un agente de código?

Para código dentro de un repositorio, casi nunca al principio. Claude Code no documenta ninguna herramienta vectorial y Cline lo evita a propósito. Si más adelante ves que el agente tarda demasiado en localizar el sitio correcto, entonces sí tiene sentido añadir un índice.

¿Cursor dejó de indexar el código?

No. Su documentación describe Instant Grep para coincidencias exactas y su blog de ingeniería defiende la búsqueda semántica con cifras propias. Cursor combina las dos vías, que es justamente el modelo híbrido.

Conclusión

La versión corta que circula, que los agentes de código han abandonado las bases vectoriales, es cierta en dos casos, falsa en dos y no verificable en uno. Lo que sí sostiene la documentación de todos ellos es algo más matizado. Sobre código, la primera herramienta que merece la pena darle a un modelo es un buscador de texto rápido y la libertad de encadenar consultas. El índice de vectores es un refuerzo posterior, con un coste de mantenimiento real.

Sobre prosa, el orden se invierte. La versión en inglés de este artículo está en Why many code agents use agentic search.

Fuentes

1. Anthropic, construir agentes con el SDK de agentes de Claude
2. Claude Code, referencia de herramientas
3. Cursor, mejorar el agente con búsqueda semántica
4. Cline, por qué Cline no indexa tu repositorio
5. Devin Desktop, indexado remoto
6. Sourcegraph, preguntas frecuentes de Cody sobre embeddings
7. VentureBeat, la reconstrucción de la recuperación
8. Anthropic, Contextual Retrieval
9. Cursor, documentación de las herramientas de búsqueda