¿Por qué estoy en contra de la recuperación solo con grep de Claude Code? Simplemente consume demasiados tokens
Los asistentes de codificación con IA están explotando. En apenas los últimos dos años, herramientas como Cursor, Claude Code, Gemini CLI y Qwen Code han pasado de ser curiosidades a compañeros cotidianos para millones de desarrolladores. Pero detrás de este rápido ascenso se está gestando una disputa por algo engañosamente simple: ¿cómo debería un asistente de codificación con IA buscar realmente contexto en tu base de código?
Ahora mismo, hay dos enfoques:
RAG impulsado por búsqueda vectorial (recuperación semántica).
Búsqueda por palabras clave con grep (coincidencia literal de cadenas).
Claude Code y Gemini han elegido el segundo. De hecho, un ingeniero de Claude admitió abiertamente en Hacker News que Claude Code no usa RAG en absoluto. En su lugar, simplemente hace grep en tu repositorio línea por línea (lo que llaman “búsqueda agéntica”): sin semántica, sin estructura, solo coincidencia de cadenas en bruto.
Esa revelación dividió a la comunidad:
Los partidarios defienden la simplicidad de grep. Es rápido, exacto y, lo más importante, predecible. En programación, argumentan, la precisión lo es todo, y los embeddings actuales siguen siendo demasiado imprecisos como para confiar en ellos.
Los críticos ven grep como un callejón sin salida. Te ahoga en coincidencias irrelevantes, consume tokens y frena tu flujo de trabajo. Sin comprensión semántica, es como pedirle a tu IA que depure con los ojos vendados.
Ambos lados tienen parte de razón. Y después de crear y probar mi propia solución, puedo decir esto: el enfoque RAG basado en búsqueda vectorial cambia las reglas del juego. No solo hace que la búsqueda sea drásticamente más rápida y precisa, sino que también reduce el uso de tokens en un 40% o más. (Salta a la parte de Claude Context para ver mi enfoque)
Entonces, ¿por qué grep es tan limitante? ¿Y cómo puede la búsqueda vectorial ofrecer mejores resultados en la práctica? Vamos a desglosarlo.
¿Qué hay de malo en la búsqueda de código solo con grep de Claude Code?
Me encontré con este problema mientras depuraba un asunto espinoso. Claude Code lanzó consultas grep por todo mi repositorio, devolviéndome enormes bloques de texto irrelevante. Al cabo de un minuto, aún no había encontrado el archivo relevante. Cinco minutos después, por fin tenía las 10 líneas correctas, pero habían estado enterradas entre 500 líneas de ruido.
Eso no es un caso límite. Al revisar por encima los issues de GitHub de Claude Code, se ve a muchos desarrolladores frustrados topándose con el mismo muro:
issue1: https://github.com/anthropics/claude-code/issues/1315
issue2: https://github.com/anthropics/claude-code/issues/4556
La frustración de la comunidad se reduce a tres puntos de dolor:
Inflación de tokens. Cada volcado de grep mete enormes cantidades de código irrelevante en el LLM, aumentando costos que escalan de forma terrible con el tamaño del repositorio.
Impuesto de tiempo. Te quedas esperando mientras la IA juega a las veinte preguntas con tu base de código, matando la concentración y el flujo.
Cero contexto. Grep coincide cadenas literales. No tiene ninguna noción de significado ni de relaciones, así que en la práctica estás buscando a ciegas.
Por eso el debate importa: grep no es solo “de la vieja escuela”, está frenando activamente la programación asistida por IA.
Claude Code vs Cursor: por qué este último tiene mejor contexto de código
Cuando se trata de contexto de código, Cursor ha hecho un mejor trabajo. Desde el primer día, Cursor ha apostado por la indexación de la base de código: dividir tu repositorio en fragmentos significativos, incrustar esos fragmentos en vectores y recuperarlos semánticamente cada vez que la IA necesita contexto. Esto es Retrieval-Augmented Generation (RAG) de manual aplicado al código, y los resultados hablan por sí solos: contexto más ajustado, menos tokens desperdiciados y recuperación más rápida.
Claude Code, por el contrario, ha apostado aún más por la simplicidad. Sin índices, sin embeddings—solo grep. Eso significa que cada búsqueda es una coincidencia literal de cadenas, sin comprensión de la estructura ni de la semántica. En teoría es rápido, pero en la práctica, los desarrolladores a menudo terminan rebuscando entre montones de coincidencias irrelevantes antes de encontrar la aguja que realmente necesitan.
| Claude Code | Cursor | |
|---|---|---|
| Precisión de búsqueda | Solo muestra coincidencias exactas—se pierde cualquier cosa nombrada de otra forma. | Encuentra código semánticamente relevante incluso cuando las palabras clave no coinciden exactamente. |
| Eficiencia | Grep vuelca enormes bloques de código en el modelo, aumentando los costos de tokens. | Fragmentos más pequeños y con más señal reducen la carga de tokens en un 30–40%. |
| Escalabilidad | Vuelve a hacer grep en el repositorio cada vez, lo que se ralentiza a medida que crecen los proyectos. | Indexa una vez y luego recupera a escala con un retraso mínimo. |
| Filosofía | Mantenerse minimalista—sin infraestructura adicional. | Indexarlo todo, recuperar de forma inteligente. |
Entonces, ¿por qué Claude (o Gemini, o Cline) no ha seguido el ejemplo de Cursor? Las razones son en parte técnicas y en parte culturales. La recuperación vectorial no es trivial—hay que resolver la fragmentación, las actualizaciones incrementales y la indexación a gran escala. Pero lo más importante es que Claude Code está construido en torno al minimalismo: sin servidores, sin índices, solo una CLI limpia. Los embeddings y las bases de datos vectoriales no encajan con esa filosofía de diseño.
Esa simplicidad resulta atractiva—pero también limita el techo de lo que Claude Code puede ofrecer. La disposición de Cursor a invertir en una infraestructura de indexación real es la razón por la que hoy se siente más potente.
Claude Context: un proyecto de código abierto para añadir búsqueda semántica de código a Claude Code
Claude Code es una herramienta sólida—pero tiene un contexto de código deficiente. Cursor resolvió esto con la indexación de bases de código, pero Cursor es de código cerrado, está bloqueado tras suscripciones y es caro para individuos o equipos pequeños.
Esa brecha es la razón por la que empezamos a crear nuestra propia solución de código abierto: Claude Context.
Claude Context es un plugin MCP de código abierto que lleva la búsqueda semántica de código a Claude Code (y a cualquier otro agente de programación con IA que hable MCP). En lugar de forzar tu repositorio con grep, integra bases de datos vectoriales con modelos de embeddings para dar a los LLMs contexto profundo y dirigido de toda tu base de código. El resultado: recuperación más precisa, menos desperdicio de tokens y una experiencia de desarrollo mucho mejor.
Así es como lo construimos:
Tecnologías que usamos
🔌 Capa de interfaz: MCP como conector universal
Queríamos que esto funcionara en todas partes—no solo en Claude. MCP (Model Context Protocol) actúa como el estándar USB para los LLMs, permitiendo que herramientas externas se conecten sin fricción. Al empaquetar Claude Context como un servidor MCP, funciona no solo con Claude Code, sino también con Gemini CLI, Qwen Code, Cline e incluso Cursor.
🗄️ Base de datos vectorial: Zilliz Cloud
Para la columna vertebral, elegimos Zilliz Cloud (un servicio totalmente gestionado construido sobre Milvus). Es de alto rendimiento, nativo de la nube, elástico y diseñado para cargas de trabajo de IA como la indexación de bases de código. Eso significa recuperación de baja latencia, escala casi infinita y fiabilidad sólida como una roca.
🧩 Modelos de embeddings: flexibles por diseñoDiferentes equipos tienen diferentes necesidades, por lo que Claude Context admite múltiples proveedores de embeddings de forma predeterminada:
OpenAI embeddings para estabilidad y amplia adopción.
Voyage embeddings para rendimiento especializado en código.
Ollama para despliegues locales centrados en la privacidad.
Se pueden incorporar modelos adicionales a medida que evolucionen los requisitos.
💻 Elección del lenguaje: TypeScript
Debatimos entre Python y TypeScript. TypeScript ganó, no solo por la compatibilidad a nivel de aplicación (plugins de VSCode, herramientas web), sino también porque Claude Code y Gemini CLI están basados en TypeScript. Eso hace que la integración sea fluida y mantiene el ecosistema coherente.
Arquitectura del sistema
Claude Context sigue un diseño limpio y por capas:
Los módulos principales se encargan del trabajo pesado: análisis de código, fragmentación, indexación, recuperación y sincronización.
La interfaz de usuario gestiona las integraciones: servidores MCP, plugins de VSCode u otros adaptadores.
Esta separación mantiene el motor principal reutilizable en diferentes entornos, al tiempo que permite que las integraciones evolucionen rápidamente a medida que surgen nuevos asistentes de codificación con IA.
Implementación del módulo principal
Los módulos principales forman la base de todo el sistema. Abstraen bases de datos vectoriales, modelos de embeddings y otros componentes en módulos componibles que crean un objeto Context, lo que permite usar diferentes bases de datos vectoriales y modelos de embeddings para distintos escenarios.
import { Context, MilvusVectorDatabase, OpenAIEmbedding } from '@zilliz/claude-context-core';
// Initialize embedding provider
const embedding = new OpenAIEmbedding(...);
// Initialize vector database
const vectorDatabase = new MilvusVectorDatabase(...);
// Create context instance
const context = new Context({embedding, vectorDatabase});
// Index your codebase with progress tracking
const stats = await context.indexCodebase('./your-project');
// Perform semantic search
const results = await context.semanticSearch('./your-project', 'vector database operations');
Resolución de desafíos técnicos clave
Crear Claude Context no consistió solo en conectar embeddings y una base de datos vectorial. El verdadero trabajo estuvo en resolver los problemas difíciles que determinan el éxito o el fracaso de la indexación de código a escala. Así abordamos los tres mayores desafíos:
Desafío 1: Fragmentación inteligente de código
El código no puede simplemente dividirse por líneas o caracteres. Eso crea fragmentos desordenados e incompletos y elimina la lógica que hace que el código sea comprensible.
Lo resolvimos con dos estrategias complementarias:
Fragmentación basada en AST (estrategia principal)
Este es el enfoque predeterminado, que utiliza analizadores tree-sitter para comprender la estructura sintáctica del código y dividirlo según límites semánticos: funciones, clases, métodos. Esto ofrece:
Completitud sintáctica – sin funciones cortadas ni declaraciones rotas.
Coherencia lógica – la lógica relacionada se mantiene junta para una mejor recuperación semántica.
Soporte multilenguaje – funciona en JS, Python, Java, Go y más mediante gramáticas tree-sitter.
División de texto con LangChain (estrategia de respaldo)
Para lenguajes que AST no puede analizar o cuando el análisis falla, RecursiveCharacterTextSplitter de LangChain proporciona un respaldo fiable.
// Use recursive character splitting to maintain code structure
const splitter = RecursiveCharacterTextSplitter.fromLanguage(language, {
chunkSize: 1000,
chunkOverlap: 200,
});
Es menos “inteligente” que AST, pero muy fiable, lo que garantiza que los desarrolladores nunca se queden bloqueados. Juntas, estas dos estrategias equilibran la riqueza semántica con la aplicabilidad universal.
Desafío 2: Gestionar los cambios de código de forma eficiente
Gestionar los cambios de código representa uno de los mayores desafíos en los sistemas de indexación de código. Volver a indexar proyectos completos por modificaciones menores en archivos sería completamente impracticable.
Para resolver este problema, construimos el mecanismo de sincronización basado en Merkle Tree.
Merkle Trees: la base de la detección de cambios
Los Merkle Trees crean un sistema jerárquico de "huellas digitales" en el que cada archivo tiene su propia huella hash, las carpetas tienen huellas basadas en su contenido, y todo culmina en una huella única del nodo raíz para todo el codebase.
Cuando cambia el contenido de un archivo, las huellas hash se propagan hacia arriba a través de cada capa hasta el nodo raíz. Esto permite una detección rápida de cambios comparando las huellas hash capa por capa desde la raíz hacia abajo, identificando y localizando rápidamente las modificaciones de archivos sin volver a indexar todo el proyecto.
El sistema realiza comprobaciones de sincronización mediante handshake cada 5 minutos usando un proceso simplificado de tres fases:
Fase 1: Detección ultrarrápida calcula el hash raíz de Merkle de toda la base de código y lo compara con la instantánea anterior. Hashes raíz idénticos significan que no se produjeron cambios: el sistema omite todo el procesamiento en milisegundos.
Fase 2: Comparación precisa se activa cuando los hashes raíz difieren, realizando un análisis detallado a nivel de archivo para identificar exactamente qué archivos se añadieron, eliminaron o modificaron.
Fase 3: Actualizaciones incrementales recalcula vectores solo para los archivos modificados y actualiza la base de datos vectorial en consecuencia, maximizando la eficiencia.
Gestión de instantáneas locales
Todo el estado de sincronización persiste localmente en el directorio ~/.context/merkle/ del usuario. Cada base de código mantiene su propio archivo de instantánea independiente que contiene tablas de hashes de archivos y datos serializados del árbol de Merkle, garantizando una recuperación precisa del estado incluso después de reinicios del programa.
Este diseño ofrece beneficios evidentes: la mayoría de las comprobaciones se completan en milisegundos cuando no existen cambios, solo los archivos realmente modificados activan el reprocesamiento (evitando un enorme desperdicio computacional), y la recuperación del estado funciona impecablemente entre sesiones del programa.
Desde la perspectiva de la experiencia de usuario, modificar una sola función activa la reindexación únicamente de ese archivo, no de todo el proyecto, lo que mejora drásticamente la eficiencia del desarrollo.
Desafío 3: Diseñar la interfaz MCP
Incluso el motor de indexación más inteligente es inútil sin una interfaz limpia orientada al desarrollador. MCP era la elección obvia, pero introdujo desafíos únicos:
🔹 Diseño de herramientas: Mantenerlo simple
El módulo MCP actúa como la interfaz orientada al usuario, haciendo que la experiencia de usuario sea la máxima prioridad.
El diseño de herramientas comienza con la abstracción de las operaciones estándar de indexación y búsqueda de bases de código en dos herramientas principales: index_codebase para indexar bases de código y search_code para buscar código.
Esto plantea una pregunta importante: ¿qué herramientas adicionales son necesarias?
La cantidad de herramientas requiere un equilibrio cuidadoso: demasiadas herramientas crean sobrecarga cognitiva y confunden la selección de herramientas del LLM, mientras que muy pocas podrían omitir funcionalidades esenciales.
Trabajar hacia atrás a partir de casos de uso del mundo real ayuda a responder esta pregunta.
Abordar los desafíos del procesamiento en segundo plano
Las bases de código grandes pueden tardar un tiempo considerable en indexarse. El enfoque ingenuo de esperar sincrónicamente a que termine obliga a los usuarios a esperar varios minutos, lo cual es simplemente inaceptable. El procesamiento asíncrono en segundo plano se vuelve esencial, pero MCP no admite este patrón de forma nativa.
8.png
Nuestro servidor MCP ejecuta un proceso en segundo plano dentro del servidor MCP para gestionar la indexación mientras devuelve inmediatamente mensajes de inicio a los usuarios, permitiéndoles seguir trabajando.
9.png
Esto crea un nuevo desafío: ¿cómo hacen los usuarios para seguir el progreso de la indexación?
Una herramienta dedicada para consultar el progreso o el estado de la indexación resuelve esto con elegancia. El proceso de indexación en segundo plano almacena en caché de forma asíncrona la información de progreso, lo que permite a los usuarios comprobar porcentajes de finalización, estado de éxito o condiciones de fallo en cualquier momento. Además, una herramienta manual de borrado de índice maneja situaciones en las que los usuarios necesitan restablecer índices inexactos o reiniciar el proceso de indexación.
Diseño final de herramientas:
index_codebase - Indexar base de código
search_code - Buscar código
get_indexing_status - Consultar estado de indexación
clear_index - Borrar índice
Cuatro herramientas que logran el equilibrio perfecto entre simplicidad y funcionalidad.
🔹 Gestión de variables de entorno
La gestión de variables de entorno a menudo se pasa por alto, a pesar de que impacta significativamente la experiencia del usuario. Requerir una configuración de clave API separada para cada MCP Client obligaría a los usuarios a configurar credenciales varias veces al cambiar entre Claude Code y Gemini CLI.
Un enfoque de configuración global elimina esta fricción creando un archivo ~/.context/.env en el directorio home del usuario:
# ~/.context/.env
OPENAI_API_KEY=your-api-key-here
MILVUS_TOKEN=your-milvus-token
Este enfoque ofrece beneficios claros: los usuarios configuran una vez y usan en todas partes en todos los clientes MCP, todas las configuraciones se centralizan en una sola ubicación para facilitar el mantenimiento, y las claves API sensibles no quedan dispersas entre múltiples archivos de configuración.
También implementamos una jerarquía de prioridad de tres niveles: las variables de entorno del proceso tienen la prioridad más alta, los archivos de configuración global tienen prioridad media, y los valores predeterminados sirven como alternativas.
Este diseño ofrece una flexibilidad enorme: los desarrolladores pueden usar variables de entorno para anulaciones temporales de prueba, los entornos de producción pueden inyectar configuraciones sensibles mediante variables de entorno del sistema para mejorar la seguridad, y los usuarios configuran una vez para trabajar sin problemas entre Claude Code, Gemini CLI y otras herramientas.
En este punto, la arquitectura central del servidor MCP está completa, abarcando desde el análisis de código y el almacenamiento vectorial hasta la recuperación inteligente y la gestión de configuración. Cada componente se ha diseñado y optimizado cuidadosamente para crear un sistema que sea potente y fácil de usar.
Pruebas prácticas
Entonces, ¿cómo funciona realmente Claude Context en la práctica? Lo probé contra exactamente el mismo escenario de búsqueda de bugs que inicialmente me dejó frustrado.
La instalación fue solo un comando antes de lanzar Claude Code:
claude mcp add claude-context -e OPENAI_API_KEY=your-openai-api-key -e MILVUS_TOKEN=your-zilliz-cloud-api-key -- npx @zilliz/claude-context-mcp@latest
Una vez que mi base de código estuvo indexada, le di a Claude Code la misma descripción del bug que anteriormente lo había enviado a una búsqueda inútil de cinco minutos impulsada por grep. Esta vez, mediante llamadas MCP de claude-context, identificó de inmediato el archivo y el número de línea exactos, junto con una explicación del problema.
La diferencia no fue sutil: fue como la noche y el día.
Y no fue solo la búsqueda de bugs. Con Claude Context integrado, Claude Code produjo de forma constante resultados de mayor calidad en:
Resolución de incidencias
Refactorización de código
Detección de código duplicado
Pruebas exhaustivas
La mejora de rendimiento también se refleja en los números. En pruebas comparativas lado a lado:
El uso de tokens se redujo en más de un 40%, sin ninguna pérdida de recall.
Eso se traduce directamente en menores costos de API y respuestas más rápidas.
Alternativamente, con el mismo presupuesto, Claude Context ofreció recuperaciones mucho más precisas.
Hemos publicado Claude Context como open source en GitHub, y ya ha conseguido más de 2,6K estrellas. Gracias a todos por su apoyo y sus likes.
Puedes probarlo tú mismo:
Los benchmarks detallados y la metodología de pruebas están disponibles en el repositorio; nos encantaría recibir tus comentarios.
Mirando hacia el futuro
Lo que empezó como una frustración con grep en Claude Code se ha convertido en una solución sólida: Claude Context, un plugin MCP open source que lleva la búsqueda semántica impulsada por vectores a Claude Code y otros asistentes de programación. El mensaje es simple: los desarrolladores no tienen por qué conformarse con herramientas de IA ineficientes. Con RAG y recuperación vectorial, puedes depurar más rápido, reducir los costos de tokens en un 40% y finalmente obtener asistencia de IA que realmente entiende tu base de código.
Y esto no se limita a Claude Code. Como Claude Context está construido sobre estándares abiertos, el mismo enfoque funciona sin problemas con Gemini CLI, Qwen Code, Cursor, Cline y más. Se acabó estar atrapado en concesiones de proveedores que priorizan la simplicidad sobre el rendimiento.
Nos encantaría que formaras parte de ese futuro:
Prueba Claude Context: es de código abierto y totalmente gratis
Contribuye a su desarrollo
O crea tu propia solución usando Claude Context
👉 Comparte tus comentarios, haz preguntas o recibe ayuda uniéndote a nuestra comunidad de Discord.
Sigue leyendo
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
Zilliz Cloud On-Demand Compute: Pay Only for What You Use
The customer case behind Zilliz Cloud On-Demand: how a $10K vector search bill came down to under $500, and the engineering changes that made it possible.
Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights
Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.