OpenAI está desafiando públicamente uno de los puntos de referencia de programación más seguidos de la industria de la IA, al argumentar que una parte sustancial de las tareas de SWE-Bench Pro podría estar lo suficientemente defectuosa como para distorsionar las comparaciones entre modelos. En un nuevo análisis publicado por OpenAI, la compañía afirmó que su auditoría encontró evidencia de que aproximadamente el 30 % de las tareas del benchmark están rotas.

El hallazgo importa más allá de un solo conjunto de datos. Los puntos de referencia de programación como SWE-Bench Pro se han convertido en una forma abreviada de juzgar el progreso en el desarrollo de software agéntico, moldeando prioridades de investigación, mensajes de lanzamiento y, en algunos casos, la percepción empresarial de qué modelo es el más adecuado para trabajos de programación. El punto central de OpenAI es que, si las tareas subyacentes no son fiables, las puntuaciones destacadas pueden decir menos sobre la capacidad real de ingeniería de software de lo que muchos creadores y compradores de modelos asumen.

Por qué OpenAI está cuestionando un benchmark en el que la industria se ha apoyado

Según OpenAI, la empresa comenzó a revisar SWE-Bench Pro después de concluir previamente que SWE-bench Verified tenía problemas significativos de diseño y contaminación. En ese momento, OpenAI dijo que había alentado a la comunidad en general a pasar a SWE-Bench Pro como una prueba más sólida de tareas de programación más largas y realistas.

Ese benchmark más reciente ha sido influyente en parte porque parecía mostrar un progreso rápido. OpenAI escribió que, en el split público de 731 tareas, los modelos de vanguardia mejoraron de una tasa de acierto del 23,3 % al 80,3 % en ocho meses. Ese tipo de salto normalmente sugeriría grandes avances en la capacidad práctica de programación.

OpenAI ahora sostiene que esos resultados deben interpretarse con más cautela. En su auditoría más reciente, la compañía dijo que su canal interno de análisis de puntos de datos marcó 200 tareas, o el 27,4 % del conjunto de datos, como rotas. Una campaña separada de anotación humana identificó 249 tareas, o el 34,1 %, como rotas. Basándose en esas revisiones, OpenAI dijo que estima que alrededor del 30 % de las tareas de SWE-Bench Pro son defectuosas.

La postura de la compañía no es que cada tarea sea inutilizable, ni que no quede señal alguna. Más bien, está advirtiendo que los resultados del benchmark deben interpretarse con cuidado porque una parte significativa de la prueba puede castigar el comportamiento correcto o recompensar arreglos incompletos.

Los modos de fallo concretos que OpenAI dice haber encontrado

El análisis de OpenAI desglosa los problemas en varias categorías que resultarán familiares para cualquiera que haya trabajado con evaluaciones, especialmente en tareas de software donde las pruebas ocultas sustituyen al juicio humano.

Una categoría son las pruebas demasiado estrictas. Según OpenAI, algunas tareas requieren un detalle de implementación muy específico que no se indica en el prompt. Eso significa que un modelo puede producir una solución funcionalmente correcta y aun así fallar.

Una segunda categoría son los prompts poco especificados. En esos casos, OpenAI dijo que las pruebas ocultas hacen cumplir requisitos que no pueden inferirse razonablemente de la descripción de la tarea. Esto crea una desalineación entre lo que se le pide al modelo que haga y aquello con lo que se le califica.

Un tercer problema son las pruebas con baja cobertura. OpenAI dijo que algunas pruebas no verifican adecuadamente si la función solicitada se ha implementado realmente, lo que permite que pasen arreglos parciales o incompletos. Para los compradores que evalúan sistemas de programación de IA, ese es el modo de fallo inverso al de las pruebas demasiado estrictas: el benchmark puede exagerar la capacidad, no solo subestimarla.

OpenAI también señaló prompts engañosos que dirigen a los modelos hacia un comportamiento que entra en conflicto con lo que luego esperan las pruebas. La compañía incluyó un ejemplo relacionado con el formato de la tabla de contenidos en Markdown, donde el prompt visible y los casos de prueba ocultos diferían por un espacio inicial. En ese escenario, un modelo que siguiera el prompt tal como está escrito aún podría ser marcado como incorrecto.

Ese ejemplo va al corazón de la crítica más amplia. Muchos problemas de software y pull requests surgen en repositorios reales para la colaboración humana, no como tareas de evaluación limpias. OpenAI argumenta que, cuando esos artefactos se convierten en un benchmark, el prompt, el parche de referencia y las pruebas no siempre encajan lo suficientemente bien como para permitir una puntuación fiable.

Cómo se realizó la auditoría y dónde persiste la incertidumbre

Los hechos más sólidos de esta historia provienen de la metodología publicada por la propia OpenAI, pero siguen siendo hallazgos reportados por el proveedor y no una revisión independiente de terceros del benchmark.

OpenAI dijo que construyó una canalización de aseguramiento de calidad que examinó instrucciones de las tareas, intentos de los modelos, metadatos y trazas de fallo para identificar posibles casos problemáticos. La compañía dijo que un primer filtro automatizado marcó 286 tareas potencialmente rotas para una revisión más profunda.

A partir de ahí, OpenAI utilizó dos vías paralelas de revisión. Una involucró agentes investigadores basados en Codex con acceso al repositorio y al entorno de ejecución, lo que les permitió inspeccionar archivos, ejecutar pruebas y analizar fallos del modelo. La otra fue una campaña de anotación humana con ingenieros de software experimentados. OpenAI dijo que cada tarea marcada en ese proceso de revisión fue examinada por cinco ingenieros, y que los desacuerdos se elevaron.

OpenAI informó que los revisores humanos, en general, eran más propensos que la canalización de agentes a calificar las tareas como rotas. La compañía también dijo que el solapamiento de categorías entre los juicios de los revisores y la canalización de agentes fue del 74 % para las tareas marcadas, y que en ninguna tarea marcada “no rota” fue la etiqueta humana más común.

Esos detalles refuerzan el argumento de la compañía de que los problemas no se limitan a casos extremos aislados. Pero también hay límites sobre lo que puede concluirse del material publicado. La evidencia fuente disponible no incluye una respuesta externa de los mantenedores de SWE-Bench Pro, ni proporciona una recalificación comparativa de los principales modelos bajo una versión reparada del conjunto de datos. Así que, aunque OpenAI presenta un caso sustancial de que el benchmark tiene ruido, el impacto exacto en los rankings de modelos sigue sin estar claro a partir de la evidencia proporcionada.

Por qué esto importa para los creadores de modelos y los compradores empresariales

Para los laboratorios de IA, la implicación inmediata es que las victorias en benchmarks de programación pueden ser menos duraderas de lo que parecen. Si casi un tercio de las tareas contiene defectos, las diferencias en la clasificación podrían reflejar desajustes entre prompt y prueba, supuestos de implementación o una cobertura de pruebas débil, más que diferencias reales en la habilidad del modelo.

Eso importa especialmente para los equipos que construyen agentes de IA para tareas de software. SWE-Bench Pro se ha presentado como una prueba significativa del comportamiento de programación a más largo plazo, más cercana a lo que hacen los sistemas agénticos en producción. Si sus tareas están materialmente defectuosas, entonces los creadores necesitan pilas de evaluación más amplias que incluyan pruebas específicas del repositorio, revisión humana, análisis de regresiones y métricas de despliegue real, en lugar de una sola puntuación pública.

Para los compradores de IA empresarial, la advertencia de OpenAI es un recordatorio de no equiparar las tasas de acierto en benchmarks con la preparación para producción. Un modelo que rinde bien en SWE-Bench Pro aún puede tener dificultades con la fiabilidad, la ambigüedad o la completitud de las pruebas en una base de código real. A la inversa, un modelo que parece más débil en el benchmark podría estar penalizado por defectos en las propias tareas.

Esto también es un tema de gobernanza. OpenAI vinculó explícitamente la calidad del benchmark con decisiones de seguridad y despliegue bajo su Preparedness Framework. El argumento es sencillo: si las evaluaciones sobrestiman o subestiman la capacidad, pueden distorsionar tanto las decisiones de lanzamiento de productos como las evaluaciones de riesgo. Ese punto va más allá de OpenAI y de los benchmarks de programación. A medida que los modelos se evalúan cada vez más por su comportamiento agéntico, la mala higiene de los benchmarks se convierte en un problema estratégico, no solo académico.

También es notable el énfasis de la compañía en la auditoría asistida por agentes. OpenAI está argumentando, en efecto, que la misma clase de sistemas que se están probando también puede ayudar a depurar las pruebas. Que ese enfoque se convierta en estándar dependerá de si los investigadores externos aceptan que la revisión basada en agentes puede mejorar la calidad del conjunto de datos sin introducir otra capa de sesgo dependiente del modelo.

Evidencia, afirmaciones y lo que proviene del proveedor

La afirmación central de esta historia proviene del proveedor: OpenAI dice que alrededor del 30 % de las tareas de SWE-Bench Pro están rotas, basándose en su proceso interno de auditoría y en una campaña de revisión humana que organizó.

OpenAI también informa que los modelos de vanguardia mejoraron del 23,3 % al 80,3 % en el split público de 731 tareas del benchmark en ocho meses. En este artículo, esa cifra debe leerse como una tendencia del benchmark citada por OpenAI, no como una medida de mercado verificada de forma independiente.

Los detalles metodológicos son más concretos. OpenAI dice que su filtro automatizado marcó 286 tareas, que su canal de análisis de puntos de datos juzgó rotas 200 tareas, y que su campaña de anotación humana juzgó rotas 249. También dice que cinco ingenieros con experiencia revisaron cada tarea marcada y que los juicios de los revisores se solaparon con la canalización de agentes en el 74 % de los casos marcados.

Lo que sigue sin verificarse a partir de la evidencia disponible es cómo clasificarían esas mismas tareas los mantenedores del benchmark u otros laboratorios, si las tareas reparadas reordenarían materialmente las clasificaciones de los modelos, y si tasas de error similares aparecen en benchmarks de programación adyacentes además de SWE-bench Verified y SWE-Bench Pro.

Qué observar a continuación

La primera señal a vigilar es si los mantenedores de SWE-Bench Pro publican una respuesta, un conjunto de datos revisado o una réplica formal. Si están de acuerdo con una parte significativa de los hallazgos de OpenAI, el benchmark podría actualizarse rápidamente. Si discrepan de las conclusiones, el sector puede necesitar un proceso de adjudicación independiente.

En segundo lugar, hay que observar si los grandes laboratorios cambian la forma en que informan sobre el rendimiento en programación. Si los futuros lanzamientos de modelos ponen menos énfasis en SWE-Bench Pro y más en suites de evaluación privadas, pruebas a nivel de repositorio o estudios de finalización de tareas, eso indicaría una confianza menguante en los rankings públicos de programación.

En tercer lugar, conviene estar atentos a si OpenAI publica más herramientas o metodología sobre auditoría de benchmarks usando Codex o agentes investigadores relacionados. Una canalización de auditoría reproducible podría influir en cómo la industria valida no solo los conjuntos de datos de programación, sino también las evaluaciones de agentes de IA en general.

Por último, la cuestión más amplia es si la inflación de benchmarks es ahora un patrón recurrente en categorías de modelos que avanzan rápidamente. OpenAI criticó antes SWE-bench Verified y ahora está planteando problemas con SWE-Bench Pro. Si la próxima generación de evaluaciones de programación se topa con problemas similares, el mercado podría moverse hacia pruebas mixtas: benchmarks públicos, telemetría de clientes y pruebas controladas de flujos de trabajo reales, en lugar de rankings de un solo número.

Perspectiva de Creati.ai

El análisis de OpenAI es importante menos porque ataque un benchmark y más porque expone un problema estructural en la medición de la IA. La industria quiere números limpios y comparables para los modelos de programación, pero las tareas de software son desordenadas. Cuando los prompts, las pruebas ocultas y los parches de referencia se extraen de repositorios reales, pequeñas inconsistencias pueden convertir silenciosamente la evaluación en ruido. Eso es un problema para los creadores que intentan optimizar modelos y para las empresas que quieren comprar con confianza.

La conclusión práctica no es dejar de usar SWE-Bench Pro, SWE-bench Verified u otros benchmarks públicos. Es degradarlos de veredictos finales a insumos orientativos. Para los equipos que lanzan agentes de IA, la alfabetización en benchmarks ya forma parte del trabajo de producto: entender qué mide realmente una puntuación, qué pasa por alto y cuán frágil puede ser. Los laboratorios que ganen confianza en programación serán aquellos que combinen resultados públicos sólidos con un diseño de evaluación transparente, evidencia de flujos de trabajo reales y la voluntad de auditar sus propias reglas de medición.