Code Isn't Memory: A Structural Codebase Index Inside a Coding Agent

Resumen Técnico: El código no es memoria: Un índice estructural de la base de código dentro de un agente de programación

Planteamiento del problema
Los agentes de programación intercalan cada vez más modelos de lenguaje extensos (LLM) con mecanismos de recuperación sobre repositorios de trabajo para resolver tareas de ingeniería de software. Sin embargo, el impacto de las estrategias de recuperación específicas —particularmente los índices estructurales de la base de código (que combinan datos semánticos, léxicos y de grafos de llamadas)— sigue siendo incierto. Las evaluaciones previas suelen confundir el rendimiento de la recuperación con la ingeniería de prompts, las superficies de herramientas o los bucles de control al comparar harnesses de agentes completos. Además, el alto costo de construir y operar índices estructurales plantea una pregunta crítica de despliegue: ¿justifica el aumento de rendimiento el gasto, o es suficiente un "grep agéntico" simple? Los benchmarks existentes también enfrentan desafíos de integridad, incluyendo la filtración de soluciones en el texto de los problemas y la memorización del modelo, lo que requiere protocolos de auditoría rigurosos.

Metodología
Los autores realizaron un estudio de ablación causal dentro de un harness de agente de programación fijo (SuperCoder) utilizando un único modelo fijo (Claude Opus 4.7) a través de tres semillas aleatorias. El estudio comparó tres brazos experimentales en 91 instancias de SWE-Polybench Verified y SWE-bench Pro:

1. SC-ON: El harness SuperCoder con un índice estructural de la base de código habilitado. Este índice incluye un índice vectorial (semántico), un índice de grafos (definiciones/aristas de llamada) y un índice léxico (BM25). Se construye una vez por repositorio y se actualiza incrementalmente mediante diffs de árboles de Merkle.
2. SC-OFF: El mismo harness SuperCoder con las dos herramientas del motor de contexto (codebase_search y codebase_graph) eliminadas de la definición de herramientas (tool schema). Todos los demás componentes (prompts, modelo, sandbox, herramientas restantes) permanecieron idénticos.
3. OpenCode: Un harness de código abierto independiente que utiliza grep agéntico (ripgrep) y lecturas de archivos como su mecanismo de recuperación principal, sirviendo como comparador entre diferentes harnesses.

Controles experimentales clave y medidas de integridad:

• Aislamiento causal: Al alternar únicamente las herramientas del motor dentro del mismo harness, el estudio aísla el efecto del índice estructural de otras variables.
• Auditoría de filtraciones (Leak Auditing): Se empleó un protocolo riguroso de "falla cerrada" (fail-closed). Esto incluyó la limpieza previa de git para eliminar commits de corrección de oro (gold-fix) y sus descendientes, así como una auditoría posterior para detectar filtraciones residuales (por ejemplo, git show en commits históricos que afectaban a archivos de oro). Se excluyeron 26 celdas basándose en un libro de contabilidad de exclusión público.
• Métricas de localización: El estudio introdujo la Vista B para la puntuación de localización. A diferencia de la "Vista A" (que cuenta todos los caminos vistos, incluyendo listas de resultados del motor), la Vista B solo cuenta los caminos que el agente alcanza activamente mediante grep, read o edit. Esto evita inflar las puntuaciones de agentes que simplemente reciben una lista de candidatos sin interactuar con ellos.
• Análisis estadístico: Los resultados se analizaron mediante pruebas de rango con signo de Wilcoxon pareadas sobre los valores de pass@1 por instancia promediados a través de las semillas.

Resultos clave
El estudio reporta mejoras estadísticamente significativas en la localización y resolución cuando el índice estructural está activo, sin incurrir en una penalización de costo por celda.

• Localización (View B acc@5):

  • SC-ON: 84.5%
  • SC-OFF: 44.3%
  • Delta: +39.6 puntos porcentuales (pp) ($p < 0.0001$).
  • OpenCode: 75.3% (SC-ON supera a OpenCode por +8.1 pp, $p=0.080$).
  • Observación: El índice mejora drásticamente la capacidad del agente para presentar los archivos correctos temprano en la trayectoria, particularmente en el primer rango (el 77.4% de las celdas tenían el archivo de oro en el rango 1 para SC-ON frente al 33.3% para SC-OFF).

• Resolución (Resolve %):

  • SC-ON: 50.4%
  • SC-OFF: 41.9%
  • Delta: +7.9 pp ($p = 0.003$).
  • OpenCode: 45.3% (SC-ON vs. OpenCode: $p = 0.087$).

• Costo y Esfuerzo:

  • Costo por Celda: Diferencia estadísticamente nula entre SC-ON y SC-OFF ($p = 0.73$).
  • Esfuerzo: SC-ON requirió significativamente menos turnos (28.3 frente a 36.2, $p < 0.0001$) y menos tokens (10.1k frente a 11.1k, $p = 0.027$) para converger.
  • Costo por Solución ($/solved): SC-ON logró el costo más bajo de $2.30, comparado con $2.84 para SC-OFF y $2.92 para OpenCode.

• Heterogeneidad: Los beneficios del índice estructural fueron más pronunciados en cambios de múltiples archivos (3+ archivos), donde la brecha de localización entre SC-ON y SC-OFF alcanzó los 46.4 pp. Esto se alinea con la intuición de que la alcanzabilidad mediante grafos de llamadas es más valiosa que un simple grep cuando los cambios abarcan múltiples archivos.

Significancia y Reivindicaciones
El artículo afirma proporcionar la primera ablación causal, controlada por modelo y auditada contra filtraciones de un índice estructural de base de código dentro de un harness de agente de programación. Sus contribuciones principales son:

1. Evidencia Causal: Demuestra que un índice estructural mejora causalmente tanto la localización de archivos como la resolución de tareas, independientemente de la ingeniería de prompts o cambios en el modelo.
2. Eficiencia de Costo: Refuta la suposición de que los índices estructurales son demasiado caros de ejecutar. El estudio muestra que, si bien el índice no reduce el costo por cada celda individual, reduce significativamente el costo por tarea resuelta al mejorar la tasa de éxito y reducir el número de turnos requeridos.
3. Guía de Despliegue: Los autores concluyen que la pregunta de despliegue no es "¿es el índice demasiado caro?", sino "¿el flujo de trabajo incluye cambios de múltiples archivos donde el ranking estructural compensa el gasto?".
4. Reproducibilidad: Los autores liberan el libro de contabilidad de exclusión, los scripts de auditoría de filtraciones, los extractores de localización (que soportan tanto la Vista A como la Vista B) y la base de datos completa de resultados para asegurar que cada número reportado sea reproducible.

El artículo mantiene un tono modesto respecto a las comparaciones entre harnesses (SC-ON vs. OpenCode), señalando que, aunque SC-ON tiende a ser favorable, la significancia estadística es marginal ($p \approx 0.08$). La afirmación más fuerte y robusta sigue siendo la ablación causal dentro del mismo harness (SC-ON vs. SC-OFF).