CuraLoc localiza bugs en repositorios con un solo plan y gasta un 90% menos de tokens

Investigadores del equipo de Sangeeta Warrier han propuesto CuraLoc, un método de localización de errores a nivel de repositorio completo. Sustituye la larga cadena de llamadas al modelo por un único plan de inspección del código. En SWE-bench Verified con GPT-5.2, el sistema logró un Func@1 de 59,3% frente al 53,8% de LocAgent y consumió un 90,3% menos de tokens escritos. El preprint apareció en arXiv el 22 de octubre de 2026 y la segunda versión salió el 26 de octubre.

Por qué un reporte de bug dice tan poco sobre dónde corregir

Un reporte de bug describe el síntoma: qué se rompió y en qué condiciones. Casi nunca indica dónde exactamente hay que cambiar el código. Por eso los agentes que corrigen errores tienen una fase aparte de localización, en la que deben encontrar, entre miles de archivos y funciones, aquellos que conviene modificar.

La mayoría de los métodos existentes abordan esta tarea de forma iterativa. El modelo examina la estructura del repositorio, elige un archivo, lo lee, decide adónde ir después, y así sucesivamente. Cada paso supone una nueva llamada al LLM y una nueva ración de tokens en el contexto. La factura crece rápido, y la calidad depende de que el agente no tome un rastro falso en el tercer o el quinto paso.

Los autores de CuraLoc ponen a prueba otra hipótesis: las decisiones sobre qué inspeccionar pueden planificarse de antemano, antes de cargar el código fuente.

Un solo plan en lugar de una cadena de pasos

El pipeline de CuraLoc consta de varias etapas. Primero, el sistema selecciona archivos candidatos y describe sus símbolos (funciones, clases, métodos) con descripciones compactas de comportamiento y estructura. En esta etapa, el código fuente no llega al modelo.

Luego viene una única decisión de planificación. En una sola llamada, el modelo hace tres cosas:

• elige los símbolos de partida;
• determina qué relaciones de cada uno conviene comprobar (llamadas, dependencias y otras relaciones estructurales del código);
• formula hipótesis sobre qué cambios son más probables.

Después entra en juego una búsqueda determinista. Reúne el código fuente solicitado sin intervención del modelo. A continuación, el modelo realiza el ranking final apoyándose en las hipótesis ya formuladas. Su razonamiento se dedica a elegir y comparar código, no a dirigir cada paso de la extracción.

Qué mostraron los benchmarks

Los autores probaron el método en SWE-bench Lite y SWE-bench Verified. La métrica principal en Verified es Func@1, es decir, la proporción de casos en que la función correcta aparece en primer lugar. Para Lite se indica Func@5, cuando la función entra entre las cinco primeras.

Comparación en SWE-bench Verified con GPT-5.2 por Func@1:

• CuraLoc: 59,3%;
• RepoSearcher: 56,2%;
• LocAgent: 53,8%;
• Agentless: 39,6%.

En consumo de tokens, CuraLoc gasta un 90,3% menos de tokens escritos que LocAgent. No es una optimización menor: en lugar de decenas de consultas al modelo, toda la navegación se reduce a un número mínimo de ellas.

En SWE-bench Lite, CuraLoc obtuvo un 83,8% de Func@5. Frente a Agentless, supone una mejora de más del 15%.

Además, los autores demostraron que el método no depende de un único modelo. CuraLoc muestra una alta precisión de localización tanto con GPT-5.2 como con GPT-6 Astra.

Qué se puede aprovechar en la práctica

La principal conclusión para quienes desarrollan agentes es que la navegación autónoma del modelo por la base de código no siempre justifica su coste. Si parte de las decisiones se traslada a una capa determinista y al modelo se le dejan las tareas en las que es fuerte (hipótesis sobre cambios y comparación de candidatos), en la localización de errores se puede ganar a la vez en precisión y en coste.

Para los equipos que construyen sus propios agentes de programación, es un motivo para revisar el presupuesto de tokens en la fase de búsqueda. La localización suele ir antes de la generación del parche y determina si el parche tendrá siquiera sentido. Una primera etapa barata y estable abarata también todo el ciclo de corrección.

Hay además limitaciones que se desprenden del propio planteamiento y de las métricas. Todos los resultados se obtuvieron en SWE-bench Lite y Verified, que son repositorios de Python con tareas conocidas. Cómo se comportará el esquema en monorepositorios cerrados y en otros lenguajes habrá que comprobarlo por separado. Pero para la tarea de «encontrar la función a partir de un reporte de bug», CuraLoc aporta un argumento sólido a favor de planificar en lugar de deambular.

El trabajo está publicado en la sección Machine Learning con la categoría cruzada Software Engineering (cs.SE), DOI 10.48550/arXiv.2610.31809.