Pasar un benchmark no significa pasar una revisión real. Esa es la conclusión incómoda de un nuevo análisis de METR sobre SWE-bench Verified, uno de los tests más citados por OpenAI, Anthropic y compañía para mostrar avances en programación con IA. Según el estudio, aproximadamente la mitad de los pull requests generados por modelos que “pasaron” el benchmark igualmente habrían sido rechazados por maintainers humanos.
La diferencia importa porque SWE-bench se volvió una especie de marcador bursátil para medir quién lidera en coding agents. Si el test automático sobreestima tanto el desempeño real, entonces buena parte de la narrativa de “la IA ya programa como un senior” necesita bastante más contexto.
Qué midió exactamente METR
El trabajo de METR tomó 296 pull requests generados por IA y los puso frente a 4 maintainers activos de 3 repositorios: scikit-learn, Sphinx y pytest. En total, la muestra cubrió 95 issues de SWE-bench Verified. Los revisores no sabían si estaban viendo un parche hecho por una persona o por un modelo.
Los parches venían de cinco modelos: Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet y GPT-5. Para no comparar peras con manzanas, los investigadores también hicieron que esos maintainers revisaran 47 soluciones humanas reales que sí habían sido aceptadas en esos proyectos.
Ahí apareció un dato clave: incluso esas soluciones humanas “golden” solo fueron reaceptadas un 68% de las veces en esta revisión retrospectiva. Eso le permitió a METR ajustar el ruido normal de cualquier code review y comparar mejor benchmark automático contra juicio humano.
La brecha no es pequeña: 24 puntos porcentuales
El hallazgo principal es brutal por lo simple: en promedio, la tasa de aceptación por maintainers quedó 24,2 puntos porcentuales por debajo del score que reporta el grader automático de SWE-bench. O dicho en castellano: el benchmark estaba contando como “resuelto” mucho código que, en la práctica, no llegaría a main.
Y no hablamos solo de detalles cosméticos. Parte de los rechazos sí fueron por estilo, verbosidad o falta de adaptación a las normas del repo. Pero una fracción relevante se debió a fallos funcionales reales: el parche parecía correcto, pasaba tests, y aun así no resolvía bien el problema de fondo o rompía comportamientos cercanos.
Si esto te suena familiar, no es casualidad. En descubre.ai ya vimos algo parecido en la trampa del código que parece correcto, pero no lo es. Lo nuevo acá es que ahora ese problema aparece medido dentro del benchmark de referencia que la industria usa para vender progreso.
Qué falló en el código generado por IA
Los maintainers clasificaron los rechazos en tres grandes grupos:
- Calidad de código: soluciones demasiado verbosas, poco idiomáticas o fuera de los estándares del proyecto.
- Daño colateral: parches que resolvían una parte del issue, pero introducían problemas en otras zonas del repo.
- Fallo de funcionalidad: cambios que simplemente no resolvían bien el bug original, aunque los tests existentes dieran verde.
Ese último punto es el más incómodo. Porque una cosa es que la IA escriba código feo. Otra muy distinta es que dé una solución equivocada con suficiente plausibilidad como para pasar por buena en un pipeline automático.
De hecho, el estudio sugiere una evolución curiosa entre modelos. El salto de Claude 3.5 Sonnet a Claude 3.7 Sonnet mejoró bastante el pass rate, pero también vino con más casos donde los maintainers detectaron problemas funcionales. Después, el paso a Claude 4 Opus y Claude 4.5 Sonnet mejoró sobre todo la calidad del código. GPT-5, según este análisis, quedó por detrás de los modelos de Anthropic en esa dimensión de calidad.
El problema no es solo técnico: es de incentivos
SWE-bench Verified usa un grader automático porque eso hace posible comparar modelos a escala. El problema es que ese mismo diseño empuja a optimizar hacia “lo que pasa el test”, no hacia “lo que un proyecto realmente mergearía”. Es la misma lógica por la que un estudiante puede aprender a aprobar una prueba sin entender del todo la materia.
Por eso también crece la importancia de capas de revisión adicionales. No basta con que un agente genere un diff que compile y pase CI. Necesitas evidencia, contexto y juicio humano. Justamente hacia allá apunta la idea de la deuda de verificación: mientras más código produce la IA, más caro se vuelve entender si de verdad está bien.
También explica por qué están apareciendo herramientas específicas para revisar lo que generan los agentes. Anthropic, por ejemplo, ya está empujando ese frente con equipos de agentes que revisan cada pull request automáticamente. El giro es revelador: ya no basta con generar código; ahora hay que vigilar al generador.
El “time horizon” también se infla
METR no se quedó solo en el pass/fail. También tradujo esos resultados a un “time horizon”: cuánto tiempo de trabajo humano equivalente puede resolver un modelo con una tasa de éxito del 50%.
Ahí la diferencia fue todavía más dura. Según el resumen de The Decoder sobre el paper, Claude 4.5 Sonnet parecía alcanzar un horizonte de 50 minutos si mirabas solo el benchmark automático. Pero cuando se reemplaza ese criterio por revisión de maintainers, ese horizonte cae a apenas 8 minutos. No es una corrección marginal: es una reducción de más de seis veces.
Eso no significa que los coding agents sean inútiles. Significa algo más útil: que los benchmarks capturan una parte del valor, pero no el valor completo. Y cuando ese matiz desaparece, se distorsionan expectativas de producto, inversión y adopción dentro de equipos reales.
Por qué importa
Este estudio no destruye la idea de programar con IA. La aterriza. Los agentes ya sirven para explorar repos, proponer fixes, escribir tests, refactorizar y acelerar trabajo repetitivo. Pero si tomas un score de SWE-bench como sinónimo de “esto ya reemplaza a un maintainer”, te estás contando una historia demasiado optimista.
La lección de fondo es simple: el trabajo de software no termina cuando un parche pasa tests. Termina cuando alguien entiende el cambio, confía en él y decide meterlo en producción. Esa última milla sigue siendo bastante más humana de lo que el hype quiere admitir.
