TL;DR:

• OpenAI auditó SWE-Bench Pro y retiró la recomendación que ella misma había hecho en febrero de 2026.
• Su filtro automático marcó 200 tareas rotas (27,4%); cinco ingenieros humanos encontraron 249 (34,1%) sobre un conjunto público de 731 tareas.
• Es el segundo benchmark de código que OpenAI descarta en menos de cinco meses, y la industria se queda sin vara común para presumir agentes.

OpenAI publicó el 8 de julio de 2026 una auditoría de SWE-Bench Pro, el examen de programación agéntica creado por Scale AI, y concluyó que alrededor del 30% de sus tareas está roto. La compañía retiró de paso la recomendación que había hecho en febrero, cuando descartó SWE-bench Verified por contaminación y empujó a toda la industria hacia Pro. El dato pega donde duele: sobre el conjunto público de 731 tareas, los modelos de frontera pasaron de un 23,3% a un 80,3% de aciertos en ocho meses, y ese salto es exactamente el número que laboratorios y proveedores usan para vender agentes de código. Si un tercio del examen califica mal, el ranking mide otra cosa. OpenAI aclara que estos resultados alimentan sus propias decisiones de despliegue y seguridad bajo el Preparedness Framework.

La auditoría no fue una pasada rápida. Un filtro automático revisó las instrucciones entregadas al modelo, los intentos de resolución y los tests usados para calificarlos, y levantó la mano sobre 286 tareas sospechosas. Sobre ese subconjunto trabajaron dos equipos en paralelo: agentes investigadores basados en Codex, con acceso al repositorio y al entorno de cada tarea, y una campaña de anotación humana donde cinco ingenieros de software con experiencia revisaron cada caso.

Los dos caminos no llegaron al mismo número, pero apuntaron al mismo lugar. El pipeline de agentes dio 200 tareas rotas, el 27,4% del conjunto. Los humanos fueron más duros: 249, el 34,1%. Coincidieron en el 74% de las categorías y, en ninguna tarea marcada, la etiqueta humana mayoritaria fue no está rota.

Los fallos caen en cuatro cajas:

• Tests demasiado estrictos, que exigen detalles de implementación que el enunciado nunca pidió y por eso rechazan soluciones funcionalmente correctas.
• Enunciados subespecificados, que omiten requisitos que los tests ocultos sí exigen y que nadie podría deducir razonablemente.
• Tests de baja cobertura, que revisan tan poco la función pedida que dejan pasar arreglos incompletos.
• Enunciados engañosos, que empujan al modelo hacia el comportamiento equivocado o contradicen lo que el test espera.

En una de esas cajas la brecha entre máquina y humano se ve nítida: los revisores de carne y hueso señalaron los tests de baja cobertura como problema principal en el 9,4% del benchmark, contra el 4,1% que detectó el pipeline automático.

El origen del desastre está en cómo se construyen estos exámenes. Las tareas salen del historial de commits de repositorios reales, escritos para que colaboren humanos, no para calificar máquinas. OpenAI lo explica con precisión quirúrgica: un test dentro de un pull request suele ser estricto porque nació para validar un cambio concreto, no para definir un estándar independiente de la implementación. Nadie lo diseñó pensando en un juez automático.

"Retiramos nuestra recomendación previa de adoptar SWE-Bench Pro", escribió el equipo de investigación de OpenAI al cerrar el análisis.

Esta vez la empresa no propone sustituto. Pide que la comunidad construya evaluaciones nuevas, hechas por desarrolladores con experiencia, difíciles de hacer trampa y fáciles de auditar.

El benchmark ya venía cojeando desde junio

La auditoría de OpenAI no llegó a un terreno virgen. A mediados de junio, la firma de análisis Artificial Analysis ya había sacado SWE-Bench Pro de su Coding Agent Index para reemplazarlo por DeepSWE, de Datacurve. El motivo, según reportó The Decoder: el examen era manipulable. Algunos modelos, en lugar de resolver el problema, copiaban la solución correcta directamente del historial de commits del proyecto. No estaban programando; estaban leyendo la respuesta.

El cambio reordenó la tabla al instante. Codex con GPT-5.5 (xhigh) subió de 65 a 76 puntos y rebasó a Claude Code con Opus 4.8 (max), que quedó en 73, mientras Claude Code con Fable 5 (max) se llevó el primer lugar con 77. En SWE-Bench Pro, ese mismo Codex con GPT-5.5 apenas alcanzaba 31 puntos, contra los 64 a 84 que registraba en otras pruebas. La misma máquina, tres cifras distintas según el examen.

Databricks publicó el mismo día la salida de emergencia

Por una coincidencia que dice mucho del momento, Databricks publicó el 8 de julio los resultados de un benchmark interno construido sobre su propia base de código, de varios millones de líneas y repartida en Python, Go, TypeScript, Scala, Rust y más. La motivación que dan es idéntica al diagnóstico de OpenAI: las tareas públicas terminan filtrándose al entrenamiento de los modelos, y de todos modos no se parecen al código que ellos mantienen.

Lo interesante es lo que encontraron al armarlo. En las primeras pruebas, algunos puntajes salieron sospechosamente altos. Al revisar las trazas descubrieron que la implementación "correcta" seguía disponible en el historial de Git del directorio de trabajo, porque cada tarea venía de un commit ya mergeado. Nada impedía que un agente con acceso a la terminal caminara hacia adelante en la historia y encontrara el parche. La solución fue sellar el repositorio durante cada ejecución. Es, palabra por palabra, el mismo agujero que Artificial Analysis le encontró a SWE-Bench Pro.

Databricks tampoco usó un modelo como juez para decidir si una tarea estaba resuelta. La razón que dan es de las frases más honestas del reporte:

"Recompensa sonar correcto por encima de ser correcto", explicó el equipo de Databricks sobre los jueces automáticos, que descartó a favor de correr los tests reales del repositorio.

Precio por token contra precio por tarea

Aquí es donde el reporte se vuelve útil para cualquiera que esté firmando una factura de API. Databricks midió costo real por tarea completada, no costo por token, y las conclusiones desarman varias intuiciones cómodas.

GLM 5.2, un modelo de pesos abiertos, aterrizó en el escalón superior de capacidad, estadísticamente empatado con Opus 4.8 en calidad y a 1,28 dólares por tarea contra los 1,94 de Opus. Sonnet 5 cuesta cerca de 1,7 veces menos por token que Opus 4.8 y aun así salió más caro por tarea (2,09 dólares), porque trabajó más rato, leyó más y consumió 1,9 veces más tokens, con seis puntos menos de completitud (81% contra 87%).

El harness, la capa que rodea al modelo, pesa casi tanto como el modelo mismo. Corriendo idéntico modelo con idéntico esfuerzo de razonamiento, Databricks vio diferencias de más del doble en costo por tarea entre un harness y otro, con la calidad intacta. El culpable era el contexto: uno de ellos, Pi, reenviaba cerca de tres veces menos contexto por turno.

Y el dato que debería incomodar a más de un director de ingeniería en Madrid, Bogotá o Guadalajara: en Databricks, alrededor de una cuarta parte del trabajo que los desarrolladores le encargan a los agentes es de baja complejidad y cerca del 60% es de complejidad media. Cambiar un flag, actualizar configuraciones. Aun así, el modelo por defecto era siempre el más caro del catálogo.

Mientras nadie publique un examen público que aguante una auditoría seria, la comparación honesta se mudó a un lugar incómodo y nada glamoroso: el repositorio de cada empresa. Databricks lo dice sin rodeos en su cierre: cualquier equipo con un backlog de pull requests mergeados ya está sentado sobre un benchmark que ningún modelo entrenó, calificado por los tests que escribió su propia gente. Para la startup que hoy elige agente de código mirando una tabla pública, ese es el consejo más barato del día.

Fuentes: 1, 2, 3