Escribir código con un agente de IA ya es común, pero corregir agujeros de seguridad con uno es una tarea más difícil y arriesgada, porque un parche que parece correcto puede romper el programa sin avisar o pasar por alto el fallo real. CWE-bench v2, publicado por Collinear AI y Hugging Face, está hecho para medir justo eso: si un agente puede parchear una debilidad de seguridad real en una base de código real sin romper lo que ya funciona.
El banco de pruebas son 100 tareas que abarcan 91 CWE distintos, el catálogo estándar de tipos de debilidad de software. Cada tarea es un entorno autónomo con una instrucción realista y una comprobación determinista, y sus autores dicen haber revisado cada una a mano. Su listón de calidad merece mención: el código inicial debe fallar y la corrección de referencia debe pasar, la función original debe seguir funcionando tras el parche, y el evaluador está preparado para rechazar a un modelo que se limita a recitar de memoria el parche conocido en lugar de razonar una reparación. En total, 95 de las 100 tareas fueron resueltas por al menos un modelo, así que el conjunto es difícil pero no imposible.
La clasificación está muy ajustada en lo alto. De 11 modelos evaluados, Gemini 4 Argon encabeza con un 67.8% pass@1 y un 81.0% en cuatro intentos, justo por delante de Claude Opus 5.5 con un 67.3% pass@1. Ambos son modelos que reseñamos. Pero la columna del coste es donde está la decisión real. DeepSeek V4.1 Flash, que también reseñamos, alcanza un 57.0% a cuatro centavos por ejecución, mientras que Opus cuesta 1,83 $ y Argon 3,92 $ por sus diez puntos extra. Para un equipo que ejecuta agentes de parcheo en una base de código grande, un modelo a cerca de una centésima parte del precio que llega casi hasta el final es una opción seria, no una concesión.
La advertencia práctica está en esos mismos números. Incluso el líder falla el 19% del conjunto en cada intento, así que la cola larga de debilidades más difíciles está lejos de resolverse, y una persona todavía tiene que revisar las correcciones de seguridad antes de publicarlas. El banco de pruebas informa de tasas de acierto, no de si un parche aprobado es el más limpio o mantenible.
Dos cosas lo mantienen honesto. El conjunto de tareas, el evaluador y el arnés son todos abiertos, así que cualquiera puede ejecutar su propio modelo y comprobar los números en lugar de fiarse de la palabra de un proveedor. Y los mismos entornos están etiquetados como escenarios de aprendizaje por refuerzo, lo que significa que pueden entrenar agentes defensivos además de puntuarlos. Esa es la aportación más duradera: una vara de medir compartida e inspeccionable para una tarea en la que un fallo silencioso es una vulnerabilidad activa.