Qué ha pasado
El benchmark parte de 327 fallos reales comunicados por usuarios en 33 productos de código abierto. De esos casos, 235 ya estaban en el código el 1 de julio de 2026 y son los que se puntuaron; los otros 92 llegaron después. Los fallos incluidos habían sido comunicados por un usuario real en el tracker público del producto, corregidos por una pull request fusionada entre el 1 de julio y el 19 de octubre de 2026, y estaban presentes en el código cuando el usuario los encontró.
Cómo se diseñó la prueba
La ejecución usó el código y la documentación de cada producto tal como estaban el 1 de julio de 2026, sin contenido posterior. El documento dice que esa fecha fue elegida por ser el primer día posterior al límite de entrenamiento de todos los modelos probados. La puntuación mide los fallos escapados detectados como proporción de los 235 y añade un resultado ponderado: una detección suma un punto y una falsa alarma resta uno.
Qué afirma Breken que consiguió
Según el benchmark de Breken, su sistema detectó 76 de los 235 fallos puntuados, equivalentes al 32%, y 61 de esas detecciones fueron probadas mediante ejecución. El mismo documento sitúa a los tres modelos frontera leyendo código entre 28 y 37 fallos detectados, mientras que las reglas estáticas detectaron 9.
| Sistema | Puntuación ponderada |
|---|---|
| breken | +23,8% |
| Claude Fable 5.1 con Claude Code | −9,4% |
| Claude Opus 5.5 con Claude Code | −15,3% |
| GPT-6 Astra con Codex CLI | −24,7% |
| Semgrep | −43,8% |
Para quién importa
Si tu equipo ya usa revisión de código y pruebas, este benchmark se dirige a un hueco posterior a esos controles: todos los fallos analizados habían pasado la revisión y la suite de pruebas, y el documento afirma que el 71% solo aparece al ejecutar el producto con datos, usuarios, fallos externos o paso del tiempo. Además, según el documento, esos fallos permanecieron una mediana de 152 días en el código antes de que un usuario los comunicara.
Qué elegir o qué hacer ahora
Si vas a usar estos datos para valorar una prueba propia, compara tanto detecciones como falsas alarmas: el propio benchmark incluye un resultado ponderado en el que una detección suma un punto y una falsa alarma resta uno. También conviene fijarse en si cada hallazgo viene con reproducción, porque Breken afirma en su documento que 61 de sus 76 detecciones fueron probadas mediante ejecución.
Qué todavía no sabemos
Aunque la página afirma que Breken encuentra fallos en una base de código, prueba cada uno antes de comunicarlo y abre una pull request en borrador con la corrección, las fuentes consultadas no establecen precio, condiciones por plan, calendario de disponibilidad ni una comparativa independiente.