OpenAI acaba de señalar un problema incómodo para la industria de inteligencia artificial: los modelos avanzan tan rápido que algunos de los benchmarks usados para medirlos ya no distinguen con claridad entre una limitación real del sistema y una falla del examen.
En una auditoría, la compañía revisó SWE-Bench Pro, una evaluación diseñada para medir capacidades de programación en tareas más largas y realistas. El resultado fue contundente: OpenAI estima que alrededor de 30% de las tareas del benchmark están rotas. No porque sean difíciles, sino porque presentan errores que pueden marcar como incorrectas soluciones funcionalmente válidas o permitir que soluciones incompletas pasen como correctas.
SWE-Bench Pro había sido presentado como una alternativa más robusta a SWE-Bench Verified, otro benchmark ampliamente usado para medir tareas de ingeniería de software autónoma. Su objetivo era evaluar si un modelo podía implementar cambios de código en repositorios reales y pasar pruebas asociadas a esos cambios, sin romper funcionalidad existente. En el conjunto público de 731 tareas, los modelos frontera pasaron de una tasa de éxito de 23.3% a 80.3% en ocho meses, una mejora que parecía indicar un salto importante en capacidades de programación agente.
Pero la auditoría de OpenAI sugiere que parte de esa medición está contaminada por ruido. La compañía creó un pipeline de análisis de calidad que revisó intentos de los modelos, metadatos de las tareas y trazas de error para identificar fallas probables en la evaluación. Ese sistema marcó 200 tareas rotas, equivalentes a 27.4% del benchmark. En paralelo, una campaña de anotación con ingenieros humanos identificó 249 tareas rotas, es decir, 34.1% del conjunto. A partir de ambos procesos, OpenAI calcula que cerca de un tercio de SWE-Bench Pro tiene problemas sustantivos.
Las fallas se agrupan en cuatro categorías. Algunas pruebas son demasiado estrictas y exigen detalles de implementación que no aparecen en el prompt. Otros prompts están subespecificados y omiten requisitos que los tests ocultos sí evalúan. También hay pruebas de baja cobertura, donde una solución incompleta puede pasar, y prompts engañosos que empujan al modelo hacia una conducta distinta de la que los tests esperan.
El ejemplo más claro es una tarea de OpenLibrary. El prompt indicaba un formato específico de espacios para renderizar entradas de tabla de contenido en Markdown, pero los tests ocultos exigían otro número de espacios. Si el modelo seguía correctamente la instrucción visible, fallaba la prueba. El error no estaba necesariamente en el modelo, sino en la evaluación.
La conclusión de fondo es más amplia que un benchmark defectuoso. OpenAI está mostrando que muchas evaluaciones de programación fueron construidas a partir de issues, pull requests y tests pensados para colaboración humana, no para medir de forma limpia a agentes autónomos de IA. En un repositorio real, los requisitos suelen estar repartidos entre conversaciones, convenciones internas, código existente, pruebas parciales y decisiones de mantenimiento. Convertir todo eso en una tarea cerrada para evaluar modelos no siempre produce un examen justo.
Este problema ya venía acumulándose. En febrero de 2026, OpenAI había dicho que SWE-Bench Verified ya no medía bien las capacidades de los modelos frontera por dos razones: pruebas defectuosas que rechazaban soluciones correctas y contaminación del benchmark, es decir, modelos que pudieron haber visto partes de los problemas o soluciones durante entrenamiento. En ese momento, la compañía recomendó migrar a SWE-Bench Pro.
Ahora, OpenAI retira también esa recomendación. Después de auditar SWE-Bench Pro, la empresa advierte que los desarrolladores de modelos deben examinar con cuidado los resultados y pide construir nuevos benchmarks diseñados específicamente por desarrolladores experimentados para medir capacidades reales de programación.
La parte más interesante es que OpenAI no solo usó humanos para auditar el benchmark. También utilizó agentes basados en Codex para revisar repositorios, tareas, intentos fallidos, pruebas y posibles ambigüedades. Es decir, la IA ya no solo está resolviendo los exámenes: también empieza a detectar cuándo el examen está mal construido.
Esto cambia la lectura del progreso en programación. Si una tarea falla, ya no basta con decir que el modelo “no pudo”. Puede haber al menos tres posibilidades: que el modelo no tenga la capacidad, que el prompt esté incompleto o que la prueba esté mal alineada. Y si un modelo pasa, tampoco siempre significa que resolvió la tarea de forma completa; una prueba de baja cobertura puede permitir soluciones parciales.
El asunto importa porque los benchmarks no son solo una herramienta de marketing. OpenAI señala que sus evaluaciones informan decisiones de despliegue y seguridad, incluidas decisiones bajo su Preparedness Framework. Si una evaluación defectuosa da una imagen falsa de las capacidades de un modelo, también puede distorsionar casos de seguridad, prioridades de investigación y decisiones sobre cuándo liberar sistemas más avanzados.
La señal es clara: la industria de IA necesita medir mejor. Los modelos de programación ya no pueden evaluarse únicamente con pruebas heredadas de repositorios reales convertidas de forma automática en benchmarks. Conforme los agentes se vuelven más capaces, las evaluaciones también deben volverse más rigurosas, menos contaminadas y más difíciles de manipular.
La paradoja es que el avance de la IA está rompiendo los instrumentos usados para medirla. Durante años, los benchmarks funcionaron como una especie de marcador del progreso técnico. Ahora, ese marcador también debe ser auditado. La pregunta ya no es solo qué tan buenos son los modelos programando, sino si todavía tenemos exámenes confiables para saberlo.
