En un estudio nuevo, Claude Opus 4.7 bloqueó el exploit proporcionado en el 90,2% de casos, pero solo el 60,7% de sus parches superó pruebas de los desarrolladores originales. La brecha de 29,5 puntos es central: eliminar un fallo no demuestra conservar la conducta prevista.
Dang K Le, Wenxuan Shi y Xinyu Xing, de Northwestern, presentaron el 7 de octubre el estudio de fiabilidad de pruebas, con 112 errores históricos en 84 proyectos abiertos de C, C++, Go y Rust. El preprint trata configuraciones concretas de Claude y agentes, no una tasa universal de fallos de reparación autónoma o producción.
Mejores modelos mantienen una brecha
Los ensayos controlados utilizaron OpenCode con Sonnet 4.0, Sonnet 4.5 y Opus 4.7 en los mismos casos. Recibieron instrucciones de compilación y prueba, pero inicialmente no el cuerpo del PoC, entrada o procedimiento que demuestra el defecto.
Sonnet 4.0 pasó el 77,7% de PoC y 43,8% de pruebas de desarrollador; Sonnet 4.5 llegó a 84,8% y 48,2%, Opus a 90,2% y 60,7%. Opus mejoró ambas medidas, pero el 32,7% de parches aprobados por PoC falló el test de desarrollador: un éxito aparente de cada tres según el análisis público de evaluación.
Opus pasó también el 94,6% de pruebas de regresión existentes, sin cerrar la distancia. Las suites antiguas comprueban ejemplos conocidos; una prueba añadida con la reparación real puede codificar la conducta antes ausente cerca del fallo.
Los investigadores reconstruyeron pruebas unitarias o de integración de commits correctivos y las aplicaron después del parche. Miden comportamiento, no similitud textual: otra implementación puede pasar. Resolver exigía compilación, supresión repetida del PoC, regresiones y prueba nueva.
PHP muestra cómo desaparece un fallo por el motivo equivocado
Un error histórico de PHP range() clasificaba mal tipos mixtos y podía tratar un valor no textual como cadena. Rechazar inmediatamente la mezcla evitaba el fallo y podía conservar pruebas antiguas, pero rechazaba combinaciones numéricas y textuales válidas que PHP debía convertir.
La reparación original corregía la clasificación conservando conducta válida. Un test con entrada vecina válida distinguía arreglo y rodeo restrictivo. Un juez de fallos únicamente recompensaría ambos.
Una barrera puede ser mitigación urgente sin reparación completa. El sobreajuste satisface ejemplos, no requisitos. En seguridad puede ocultar síntomas, dejar otras rutas y crear confianza falsa que reduce revisión.
Las pruebas de desarrollador son mejor proxy, no aceptación completa. No agotan rendimiento, compatibilidad, legibilidad o arquitectura. Una alternativa defendible puede cambiar conducta no documentada; fallar un test histórico exige inspección, no demuestra peligro automático.
Las instrucciones cambian la capacidad medida
Con comandos detallados Sonnet 4.0 pasó 77,7% de PoC, sin ellos 74,1%. El test de desarrollador pasó de 41,1% a 43,8%. Solo en C/C++, instrucciones elevaron PoC de 72% a 92%, pero desarrollador de 28% a 36%.
Documentar es ayuda legítima también humana, pero no se comparan puntuaciones sin presupuesto informativo. Go y Rust suelen tener comandos previsibles; C/C++ muchos sistemas, opciones y envoltorios. Ayudar a preparar el entorno cambia resultados antes de valorar la reparación.
En 62 casos Go, enseñar PoC fuente elevó éxito de 69,4% a 95,2%, frente a 41,9% a 48,4% en desarrollador. El arnés legible revela API y llamadas, facilitando cumplir el test visible.
En 25 casos C/C++, enseñar entrada binaria o textual opaca no cambió ni 92% PoC ni 36% desarrollador. Ambos pueden afirmar que aportan PoC, pero uno revela intención ejecutable y el otro exige inferir significado. No son condiciones equivalentes.
Búsqueda e infraestructura distorsionan en ambas direcciones
Los casos históricos suelen tener incidencias, avisos y reparaciones públicas. El artículo documenta un agente que halló el parche en la Web y otro en historial Git sin limpiar. El éxito no mide limpiamente razonamiento independiente.
Buscar Web e historial es razonable en producción. Solo contamina respecto a una promesa de razonamiento sin ayuda. Una prueba de recuperación y herramientas puede permitirlo explícitamente. Memorizar correcciones también limita tasas absolutas.
Errores del marco pueden ocultar trabajo bueno o revelar soluciones secretas. Permisos, tiempos y colisiones de archivos impiden compilar o puntúan mal. Problemas individuales afectaron aproximadamente 5–32% de casos en ejecuciones completas, a veces más que diferencias de clasificación.
El resultado pertenece al conjunto de modelo, agente, instrucciones, herramientas, empaquetado, límites y evaluación. Los controles usaban OpenCode con Claude; casos incluían Claude Code con Sonnet 4.5. Los entornos no son intercambiables.
Estudios relacionados piden múltiples pruebas
PVBench analizó 209 casos de 20 proyectos: más del 40% de parches aceptados por controles básicos falló pruebas derivadas de arreglos del desarrollador. Datos y diseño difieren; no es una tasa Claude comparable.
PatchBench halló inflación media de 1,83 en tasas de resolución de 11 agentes con solo PoC. Reproducción de seguridad, pruebas unitarias y salidas bajaron a los mejores desde más del 97% de PoC hasta aproximadamente la mitad en validación combinada.
PatchBench eligió también vulnerabilidades reparadas fuera de la pila del fallo y las trasplantó a repositorios cambiados para reducir recuerdo histórico. No supone que todo éxito sea razonamiento nuevo.
CyberGym-E2E, de Berkeley, cubre 920 vulnerabilidades de 139 proyectos y combina descubrimiento, reproducción y reparación. Los mejores repararon cerca del 80% con objetivo conocido; el resultado integral bajó al exigir descubrirlo. Persistieron barreras superficiales.
Modelos, tareas y definiciones no forman una clasificación única. La metodología Cyber Index también amplía a auditoría, descubrimiento, reproducción y reparación sin romper conducta legítima. La cuestión común es qué incluye el éxito.
Un juez mejor no prueba producción
La muestra Northwestern exigía compilaciones reproducibles y tests originales significativos. Sus 112 fallos son variados, no representativos de todo. El material público puede haber entrado en entrenamiento. Limita tasas absolutas, no borra sensibilidad controlada a instrucciones o evaluación.
Producción puede ser más segura con pruebas propias, análisis estático, fuzzing, revisión y despliegue gradual, pero más difícil con tests incompletos, conducta no documentada y dependencias ausentes. Ni suite curada ni PoC pasado justifica despliegue desatendido.
Serían útiles resultados separados de PoC e intención, permisos de herramientas y red, historial limpio, tiempos y fallos por etapa, además de aceptación, revisión o rechazo de mantenedores reales. Rutas alternativas y fallos nuevos cuentan; similitud textual no sustituye comportamiento.
Una base técnica de conocimientos consultable conserva instrucciones, trazas, parches y validación, sin hacer correcto el código. La conclusión es progreso real de Opus y sobreestimación de 29,5 puntos con solo fallos. La reparación generada sigue siendo candidata y requiere pruebas independientes de seguridad y conducta legítima.