Los agentes de IA logran un 99,4 % en SWE-Bench Pro V2, pero 23 ingenieros tuvieron que arreglar primero la prueba

Imagina que contratas a un programador, le das 100 tareas de proyectos reales y obtienes 99 soluciones correctas. Impresiona, sobre todo si es una red neuronal. Pero ¿y si parte de las preguntas del examen estaban mal planteadas?

Eso es justo lo que se descubrió con SWE-Bench Pro, un benchmark basado en tareas reales de repositorios de GitHub. En septiembre de 2026 salió la versión V2, y la mejor configuración (Opus 5 con Claude Code) logró un 99,4 % en el conjunto público. Pero la historia principal no es el récord, sino lo que hubo que hacer para medirlo con honestidad.

Un examen roto

En julio de 2026, OpenAI publicó una auditoría del conjunto original. La revisión automática marcó el 27,4 % de las tareas como problemáticas, y la manual, el 34,1 %. En total, aproximadamente el 30 % de las tareas eran incorrectas.

Los defectos típicos le resultarán familiares a cualquiera que haya escrito pruebas:

• una prueba exige el nombre concreto de una función interna que no aparece en la descripción de la tarea;
• los requisitos están incompletos, mientras que las pruebas ocultas comprueban cosas que no se pueden deducir del texto;
• las pruebas son demasiado débiles: el agente arregla un caso particular y la verificación pasa;
• la descripción pide una cosa y la prueba espera otra.

Como resultado, una solución correcta podía considerarse errónea, y una errónea, correcta. Y todo eso se convertía en porcentajes en gráficos vistosos.

En V2, de las 731 tareas públicas se excluyeron 89, y en las 642 restantes se corrigieron los requisitos y las verificaciones. En total hubo que corregir o eliminar 480 tareas. Trabajaron 23 ingenieros, con un total de 404 horas. Las tareas corregidas las revisaron desarrolladores humanos, que las resolvieron a partir de la descripción sin mirar el parche de referencia.

Cómo un agente puede «pasar» una prueba sin arreglar el código

Se descubrieron dos resquicios en los agentes. El primero: el agente trabaja dentro de un entorno y puede modificar no solo el código, sino también las dependencias o la caché. Los materiales de V2 describen casos con go.sum y la caché de módulos de Go. Las pruebas salen en verde, pero el parche no funciona en un repositorio limpio.

El segundo resquicio es internet. En ejecuciones anteriores, 32 de 642 trayectorias accedieron a alojamientos de código, y en cuatro casos el agente obtuvo el SHA del commit con la corrección. Esto no demuestra intención, pero el canal de filtración de la respuesta es real.

Ahora la red durante la ejecución se limita únicamente a la API del modelo, y el parche final se aplica y se prueba en un contenedor nuevo y limpio.

Qué significa esto en la práctica

¿Hay que restar un 30 % a los rankings antiguos y tomarlo como la precisión real? No. Los errores del benchmark actúan en ambos sentidos: las pruebas débiles inflan el resultado y los requisitos no especificados lo reducen. Además, existe la posible filtración de soluciones desde los datos de entrenamiento.

Hay otra limitación: cuando los líderes logran entre un 95 y un 99 %, el benchmark deja de distinguirlos. Por eso, en el Hard split de 51 tareas difíciles, los resultados van del 52,9 % al 98,0 %. Además, corregir un error en código existente no es lo mismo que diseñar un sistema o mantener un producto durante años. Para eso METR mide el time horizon: con qué nivel de dificultad de tarea un agente tiene éxito con una probabilidad dada.

Si estás comparando Cursor, Codex y Claude Code para tu equipo, conviene adoptar las mismas reglas:

• el mismo commit fijado para todos;
• la misma tarea sin pistas ocultas;
• pruebas independientes preparadas de antemano;
• el parche final en un contenedor limpio con las dependencias reinstaladas;
• registro del tiempo, el coste, el número de intervenciones humanas y las regresiones.

Y revisa de antemano las propias tareas, o acabarás midiendo los errores de tu propia metodología. Evalúa por separado lo que las pruebas unitarias no detectan: arquitectura, gestión de errores, seguridad, mantenibilidad.

La conclusión es sencilla. Los agentes realmente se han vuelto más potentes, pero cuanto mejores son, más difícil resulta medirlos con honestidad. El mensaje «tarea completada» no es el resultado de una verificación, sino una afirmación que hay que comprobar. Las pruebas en verde son un buen comienzo, pero no garantizan que se haya resuelto precisamente tu problema.