Una prueba basada en fallos revela límites de la revisión automática de código

Si los comentarios de revisión humana pueden pasar por alto fallos reales, ¿cómo pueden los desarrolladores saber si los revisores automáticos recuperan defectos que las personas confirmaron y corrigieron?

Una prueba útil debe comprobar si encuentran el defecto en sí y darles el repositorio y el cambio que habrían revisado.

CRBugBench vincula fallos confirmados con los cambios que los introdujeron y mide si los agentes de revisión los recuperan en tareas con contexto del repositorio.

En cada tarea, un agente revisa una copia del repositorio y la solicitud de cambios que introdujo un fallo conocido, sin que se le diga que hay un fallo.

Tres evaluadores basados en modelos de lenguaje deciden si sus hallazgos coinciden con el fallo; luego, los investigadores calculan la proporción de tareas en las que aparece entre los cinco primeros.

En las tareas de GitHub, claude-opus-5 recuperó con más frecuencia los fallos detectados antes de integrar los cambios que los descubiertos después: 79,6 % frente a 64,2 % de las tareas.

Los resultados muestran una recuperación considerable, pero incompleta, y diferencias de rendimiento según el tipo de tarea.

Estos resultados miden si los agentes recuperan fallos conocidos en tareas seleccionadas de repositorios; no miden la utilidad general de una revisión ni el rendimiento en todos los proyectos de software. Las asociaciones ajustadas describen patrones en los datos; no demuestran que la visibilidad del fallo por sí sola cause diferencias en su detección.