✨︎ Resumen (TL;DR):
- OpenAI retiró su recomendación para el examen SWE-Bench Pro tras una auditoría interna profunda.
- Los evaluadores detectaron que cerca del 30% de las 731 tareas del conjunto público están rotas.
- La industria de la inteligencia artificial se queda temporalmente sin un estándar confiable para evaluar agentes de código.
OpenAI retiró oficialmente su respaldo a SWE-Bench Pro, el estándar de evaluación de programación agéntica desarrollado por Scale AI, tras descubrir mediante una auditoría que aproximadamente el 30% de sus tareas están rotas. La firma de inteligencia artificial descartó esta métrica porque genera calificaciones incorrectas, dejando a la industria sin una referencia de valor para medir el desempeño de sus modelos de lenguaje.
SWE-Bench Pro es un examen de programación agéntica que evalúa la capacidad de los modelos de inteligencia artificial para resolver problemas de software en repositorios reales.
El veredicto de la auditoría: un tercio del examen no sirve
La compañía utilizó un filtro automático que analizó las instrucciones, intentos de resolución y pruebas de calificación de un conjunto público de 731 tareas, marcando 286 casos sospechosos.
Para revisar estas alertas, OpenAI desplegó dos estrategias en paralelo: agentes automatizados basados en Codex y un equipo de cinco ingenieros de software con experiencia.
El pipeline automático identificó 200 tareas rotas (27.4%), mientras que los ingenieros humanos fueron más estrictos y detectaron 249 tareas defectuosas (34.1%). Ambos coincidieron en el 74% de las categorías evaluadas.
Según el reporte, las fallas se agrupan en cuatro problemas principales: * Pruebas demasiado estrictas: Exigen detalles específicos de implementación que el enunciado original nunca solicitó. * Enunciados imprecisos: Omiten requisitos obligatorios que las pruebas ocultas sí exigen para aprobar la tarea. * Pruebas de baja cobertura: Permiten que el modelo apruebe la tarea con parches de código incompletos. * Enunciados engañosos: Confunden al modelo o contradicen directamente los requerimientos del sistema.
Como ejemplo de enunciado engañoso, OpenAI expuso el caso de la tarea OpenLibrary-77c16d5, donde el texto mostraba un espacio antes de una tabla, pero la prueba oculta exigía estrictamente dos espacios. Cualquier modelo que siguiera las instrucciones reprobaba de forma injusta por un solo carácter.
El origen del problema en los benchmarks de código
El origen de este error radica en la construcción de estas evaluaciones. Los exámenes utilizan historiales de cambios (commits) de repositorios reales creados originalmente para la colaboración entre humanos, no para calificar sistemas autónomos. Un test en un pull request suele diseñarse para validar un cambio específico, no para servir de métrica general.
“Retiramos nuestra recomendación previa de adoptar SWE-Bench Pro”, declaró el equipo de investigación de OpenAI, sugiriendo que la comunidad desarrolle evaluaciones difíciles de hackear y diseñadas por desarrolladores reales.
Este tropiezo no es el primero. En junio de 2026, la firma Artificial Analysis ya había retirado esta métrica de su índice debido a que varios modelos simplemente copiaban la solución directamente del historial de Git del proyecto en lugar de resolver el problema.
Databricks y la realidad financiera del código agéntico
Databricks publicó un estudio el mismo día donde confirmó esta vulnerabilidad. Al probar modelos en su propio código, descubrieron que los agentes accedían al historial de Git para encontrar el parche correcto ya integrado. La solución para la compañía fue sellar el repositorio durante la ejecución de las pruebas.
El análisis de Databricks también evaluó el costo real por tarea resuelta, arrojando datos que desafían la lógica común de las tarifas por token: * GLM 5.2 (modelo de pesos abiertos) empató en calidad con Opus 4.8, pero costó 1.28 dólares por tarea en comparación con los 1.94 dólares de Opus. * Sonnet 5 resultó más caro por tarea (2.09 dólares) a pesar de tener un costo menor por token, debido a que consumió 1.9 veces más tokens al tardar más en procesar. * El soporte de software (harness) que rodea al modelo altera drásticamente el costo. El sistema Pi redujo a la tercera parte el contexto enviado, recortando los costos a la mitad sin perder calidad.
Mientras no exista una evaluación pública sólida, la mejor alternativa para las empresas consiste en construir pruebas internas utilizando su propio historial de cambios integrados, garantizando un entorno de evaluación real que ningún modelo haya memorizado previamente.
