Lo esencial antes de invertir más tiempo.
CodeGrep es un agente de retrieval de 14B que coordina grep, glob y lectura multi-turn para devolver candidatos a un agente de código congelado.
CodeGrep resuelve 27,0% de SWE-Bench Verified frente a 25,8% sin retrieval, con 15% menos rondas y 19% menos tokens en los issues resueltos.
Resultado reportado con fuente enlazada · 3 localizadores disponibles.La ganancia depende de la precisión del retriever y del entorno de worktree; un retrieval mediocre puede empeorar el agente, y la eficiencia observada no garantiza el mismo resultado en repositorios fuera de la distribución.
Resolución total, precisión del contexto recuperado, rondas, tokens, tests y regresiones introducidas.
CodeGrep es un agente de retrieval de 14B que coordina grep, glob y lectura multi-turn para devolver candidatos a un agente de código congelado.
Qué está reportado y qué conviene comprobar.
CodeGrep resuelve 27,0% de SWE-Bench Verified frente a 25,8% sin retrieval, con 15% menos rondas y 19% menos tokens en los issues resueltos.
27,0% vs 25,8%; -15% rondas; -19% tokens · baseline: sin retrieval · contexto: 500 issues de SWE-Bench Verified; umbral de precisión 0,677
Qué estudiaron y qué cambia.
La síntesis está separada de los resultados reportados y de las inferencias.CodeGrep observa que los coding agents modernos gastan una parte desproporcionada de su presupuesto en localizar el archivo que deben cambiar. La exploración con grep, glob y view_file puede ser correcta pero repetitiva, y deja menos presupuesto para comprender, editar y verificar el parche.
El paper separa esa fase y entrena un retriever de 14B con GRPO para emitir llamadas multi-turn y paralelas. El agente downstream permanece congelado y recibe una lista de archivos candidatos. La contribución no es otro contexto más grande, sino una política aprendida para reducir el espacio de búsqueda del repositorio.
En las 500 instancias de SWE-Bench Verified, CodeGrep alcanza 27,0% de resolución frente a 25,8% del baseline sin retrieval; en las issues resueltas usa 15% menos rondas y 19% menos tokens. La comparación entre retrievers encuentra una condición relevante: BM25 con precisión 0,375 degrada, Jina con 0,445 es neutral y CodeGrep con 0,677 cruza el umbral de utilidad.
La lectura útil para un harness es que retrieval debe ganarse su sitio con una métrica de precisión y coste, no asumirse como mejora automática. El trabajo anuncia release de modelo, pipeline y entorno, pero la disponibilidad anunciada no equivale todavía a una dependencia reproducible para cualquier repositorio.
La ganancia depende de la precisión del retriever y del entorno de worktree; un retrieval mediocre puede empeorar el agente, y la eficiencia observada no garantiza el mismo resultado en repositorios fuera de la distribución.
- PROBLEMA
- En SWE-Bench Verified, una parte importante de las rondas y tokens se va en explorar el repositorio antes de escribir el parche.
- MÉTODO
- Entrena con GRPO un retriever de 14B que hace grep, glob y lecturas paralelas multi-turn y entrega archivos candidatos a un agente de código posterior que permanece congelado.
- TIPO DE EVIDENCIA
- 500 issues de SWE-Bench Verified: 27,0% de resolución frente a 25,8% sin retrieval, con 15% menos rondas y 19% menos tokens en issues resueltas; el umbral de precisión de CodeGrep es 0,677.
- LÍMITE
- La ganancia depende de la precisión del retriever y del entorno de worktree; un retrieval mediocre puede empeorar el agente, y la eficiencia observada no garantiza el mismo resultado en repositorios fuera de la distribución.
La exploración del repositorio se convierte en una política medible.
Retrieval solo mejora un coding agent cuando devuelve evidencia suficientemente precisa.
No se incrusta el recorte original hasta confirmar licencia o permiso; la fuente queda enlazada para comprobar la evidencia.
Abrir fuente primaria ↗La lectura también deja rastro.
Guarda una observación junto a la evidencia. Tú escribes aquí; los agentes pueden añadir notas por MCP y aparecerán identificados.
LECTURA AMPLIADAMetodología, implicaciones y preguntas para volver al paper.+
Entrena con GRPO un retriever de 14B que hace grep, glob y lecturas paralelas multi-turn y entrega archivos candidatos a un agente de código posterior que permanece congelado.
Un retriever no ayuda por existir: debe superar un umbral de precisión. Cuando lo hace, puede mantener o mejorar la resolución reduciendo rondas y tokens.
La ganancia depende de la precisión del retriever y del entorno de worktree; un retrieval mediocre puede empeorar el agente, y la eficiencia observada no garantiza el mismo resultado en repositorios fuera de la distribución.
Cómo lo llevaría a un proyecto
Medir por separado tiempo de exploración, precisión de archivos candidatos y éxito del parche antes de dar a un coding agent una herramienta de retrieval especializada.
Preguntas que conviene probar
- ¿Cuál es el umbral de precisión de retrieval en nuestro repositorio?
- ¿Qué evidencia debe devolver el retriever para que el agente pueda corregir sin reexplorar?
Si tuviera que convertirlo en una prueba mañana.
Mi lectura
Antes de ampliar el contexto de un agente, conviene medir si el retriever realmente encuentra el contexto decisivo.
Esta última frase es una inferencia editorial a partir del paper y de sus posibles implicaciones; no es una afirmación de los autores.