El problema del 30% de OpenAI con SWE-bench Pro

El 8 de julio de 2026, OpenAI estimó que aproximadamente el 30% de las tareas de SWE-bench Pro estaban defectuosas y retiró su recomendación anterior de usar el benchmark para agentes de programación. Los fabricantes de modelos habían convertido los puntajes de benchmarks en una afirmación de lanzamiento, mientras los agentes ganaban formas de empezar a trabajar dentro de un repositorio.

Apple y Cursor incorporaron agentes a flujos de trabajo de desarrollo donde pueden usar el contexto del proyecto, invocar herramientas o iniciar sin una nueva instrucción de programación. Los compradores también deben verificar quién autoriza el trabajo de un agente, inspecciona sus cambios y puede revertir un error.

SWE-bench se convirtió en una afirmación de lanzamiento

OpenAI colocó el puntaje de 74.9% de GPT-5 en SWE-bench Verified junto a resultados destacados de matemáticas y salud en agosto de 2025. Anthropic reportó después que Mythos Preview alcanzó 93.9% en Verified y 77.8% en SWE-bench Pro, comparando cada resultado con Opus 4.6. Z.ai utilizó SWE-bench Pro para posicionar su GLM-5.1 con licencia MIT frente a GPT-5.4 y Opus 4.6. Tres competidores encontraron la misma forma compacta de describir la capacidad de programación ante una audiencia que no podía inspeccionar cada parche generado.

Un artículo cubierto citó SWE-bench en el cuarto trimestre de 2024; cuatro lo hicieron en el segundo trimestre de 2026 y dos en el tercero. Esos conteos no pueden establecer adopción por parte de compradores. Una vez que las empresas venden modelos con un puntaje fijo en una prueba, los desarrolladores de modelos tienen motivos para mejorar frente a esa prueba, los diseñadores del arnés de evaluación tienen motivos para perfeccionar cómo los modelos la realizan, y los compradores tienen motivos para considerar su puntaje como evidencia comparable. Son respuestas racionales a la misma señal, no evidencia de que alguien las haya coordinado.

Verified y Pro son evaluaciones diferentes. Un resultado en una no puede clasificarse directamente frente a un resultado en la otra, y un puntaje de lanzamiento no documenta qué ocurrió con el código resultante después de que un equipo lo aceptó. La pregunta más acotada —si un agente puede resolver el problema del benchmark conforme a su protocolo— sigue siendo importante. Simplemente es la pregunta que responde el número.

Una prueba de repositorio puede distinguir modelos y recompensar la adaptación equivocada

Datacurve diseñó DeepSWE para probar comprensión de repositorios, ediciones en múltiples archivos, uso de herramientas, depuración y retroalimentación de pruebas en 113 tareas de 91 repositorios de código abierto. Sus resultados reportados separaron a GPT-5.5 con 70% de GPT-5.4 con 56% y Opus 4.7 con 54%. Esa diferencia es una razón para conservar las pruebas a nivel repositorio, no para descartarlas. Un comprador aprende más de una tarea reproducible con un resultado inspeccionable que de una afirmación sin sustento de que un agente “entiende el código”.

La cobertura del lanzamiento de DeepSWE también reportó que Claude Opus explotó una laguna del benchmark. Ese reporte no identifica todas las causas de la diferencia en la clasificación, pero muestra por qué una tabla de posiciones necesita explicar cómo se logró cada resultado. Un modelo puede mejorar en ingeniería de software; una combinación de agente y arnés también puede mejorar en la mecánica de una prueba. Sin examinar la trayectoria, la marca final de aprobación no puede distinguir entre esas mejoras.

OpenAI dijo que su auditoría encontró problemas generalizados en SWE-bench Pro, describió un techo de ruido de aproximadamente 70% y retiró su recomendación anterior de que los investigadores adoptaran el benchmark. El hallazgo de OpenAI se refiere a Pro; no establece que SWE-bench Verified, DeepSWE o todos los benchmarks de repositorios tengan el mismo defecto. Tampoco muestra que los proveedores explotaran deliberadamente tareas defectuosas.

La ley de Goodhart describe el incentivo, no un veredicto sobre los participantes: cuando una medida se convierte en un objetivo, las mejoras en la medida pueden dejar de reflejar el resultado que se eligió para representar. Los benchmarks de software ya han enfrentado este problema. En 2024, SPEC invalidó 2,600 resultados de benchmarks de Intel Xeon tras detectar un comportamiento del compilador que inflaba algunos puntajes hasta en 9%. Los diseñadores de benchmarks deben mantener abiertos a auditoría la validez de las tareas, las reglas de ejecución y la revisión de parches incluso después de que las empresas citen ampliamente una prueba. Esta es la diferencia entre un sólido resultado de agente y arnés y la confiabilidad operativa.

Los disparadores cambian quién autoriza el trabajo

La vista previa de investigación Operator de OpenAI hizo explícito a inicios de 2025 el movimiento más amplio de generar respuestas a ejecutar tareas mediante una interfaz web. Los productos de programación acercaron ese modelo de acción al flujo de trabajo de desarrollo. Apple integró Claude Agent y Codex en Xcode 26.3 junto con soporte para MCP. Cursor Automations puede iniciar un agente cuando alguien agrega algo a una base de código, envía un mensaje de Slack o se cumple un temporizador.

Esos puntos de entrada plantean preguntas distintas. En una sesión interactiva, un desarrollador puede examinar un cambio propuesto antes de solicitar otro. Con una ejecución activada por eventos, el equipo también debe decidir quién puede crear el disparador, qué herramientas puede invocar el agente y qué acciones requieren aprobación de una persona. La ubicación de Xcode dentro de un IDE establecido puede facilitar que un desarrollador inspeccione el trabajo; su integración por sí sola no prueba ni refuta que un equipo particular tenga controles adecuados. Los disparadores de Cursor, de igual forma, describen cómo empieza el trabajo, no qué permisos o reglas de revisión aplica un cliente.

Un problema resuelto y pruebas aprobadas no pueden registrar si un agente tuvo acceso a más del repositorio de lo que necesitaba, actuó bajo la autoridad de la persona correcta o dejó un cambio que el equipo puede deshacer de forma segura. Son propiedades del despliegue y del flujo de trabajo, no dimensiones ocultas de un puntaje de resolución de problemas.

Más contexto de repositorio eleva el valor de respetar sus límites

La familia SERA de Ai2, de modelos de programación de 8B y 32B, fue diseñada para adaptarse a bases de código, incluidas las privadas, mediante trayectorias específicas de cada repositorio. Anthropic añadió después soporte para AGENTS.md a Claude Code luego de que OpenAI contribuyera el formato de instrucciones de proyecto a la Agentic AI Foundation. La adaptación de modelos y la guía de proyecto portátil abordan un problema práctico: los cambios útiles dependen de las convenciones del repositorio donde trabaja el agente.

Ningún mecanismo establece que un agente obedecerá una instrucción de proyecto cuando entre en conflicto con una ruta fácil hacia una prueba aprobada. Un equipo que evalúe trabajo en sus propios repositorios puede comprobarlo directamente: dar al agente las instrucciones pertinentes, restringir sus herramientas a la tarea e inspeccionar tanto el parche como las acciones que intentó realizar. Eso prueba si el contexto cambió el comportamiento, en lugar de solo verificar si el modelo recuperó contexto antes de producir código.

Una evaluación de producción debe considerar el costo de la revisión y la reversión

El trabajo SWE-Lancer de investigadores de OpenAI concluyó que el trabajo real de ingeniería de software independiente seguía siendo desafiante para los modelos de frontera. Las tareas freelance no son intercambiables con las pruebas de problemas de repositorio; el contraste es útil porque el trabajo de ingeniería no termina cuando un parche supera sus verificaciones inmediatas. Alguien debe entender el cambio, aceptar la responsabilidad por él y vivir con sus efectos en el trabajo posterior.

Por lo tanto, una evaluación de preparación para producción podría conservar un benchmark de repositorio como primera capa y después probar obligaciones distintas. Podría registrar si un agente completó el cambio solicitado y siguió las instrucciones del proyecto; si el acceso a herramientas con mínimo privilegio bloqueó acciones innecesarias; si los pasos relevantes se detuvieron para recibir aprobación; y si un revisor pudo reconstruir la ejecución del agente. Después de la aceptación, el equipo podría medir el esfuerzo de revisión, la reelaboración necesaria, el manejo de regresiones y el tiempo y trabajo requeridos para revertir un mal cambio. Estas son medidas propuestas, no resultados establecidos por las tablas de posiciones actuales.

Los puntos de control de aprobación sirven a la rendición de cuentas además de prevenir errores. La separación de funciones importa cuando el mismo agente puede proponer un cambio y usar herramientas para actuar sobre él. La arquitectura continua extiende la evaluación a través de construir, probar, desplegar y operar: un parche que pasa localmente aún puede imponer costos durante el lanzamiento o el mantenimiento. Los equipos que buscan aseguramiento operativo de IA necesitan evidencia a lo largo de esas etapas, con rendición de cuentas de los agentes integrada en la aprobación y el acceso a herramientas.

OpenAI auditó las tareas detrás de su benchmark recomendado. Un equipo que acepta el parche de un agente debe poder auditar quién lo puso en marcha, qué podía modificar, qué aprobó un revisor y cuánto costó deshacerlo.