OpenAI detectó que cerca del 30% de las tareas de SWE-Bench Pro estaban rotas

En julio de 2026, OpenAI estimó que cerca del 30% de las tareas de programación de SWE-Bench Pro estaban rotas y retiró su recomendación de la prueba. Los laboratorios usaban las puntuaciones de SWE-bench para diferenciar lanzamientos, mientras los agentes de código entraban en los repositorios, donde un parche que pasa las pruebas todavía necesita que alguien apruebe la integración.

El costo de proponer otro parche de código ha caído más rápido que el de decidir si integrarlo. La auditoría de OpenAI expuso el límite de una tasa de aprobación: puede describir el desempeño en una prueba sin establecer que un agente tenía el contexto correcto, se mantuvo dentro de su autoridad o produjo un cambio del que alguien pueda responsabilizarse con seguridad. La ventaja competitiva se está desplazando hacia sistemas que pueden aportar esa evidencia operativa junto con la capacidad del modelo.

Una prueba de investigación se convirtió en comparación de lanzamientos

El código ofrecía un objetivo temprano inusualmente conveniente para una evaluación exacta. Como explica Chip Huyen en AI Engineering, las pruebas comunes de generación de código, como HumanEval y MBPP, verifican la corrección funcional frente a casos de prueba. Una prueba aprobada da una respuesta clara a una pregunta acotada. No exige que un evaluador coincida sobre si un parche es legible o mantenible.

Para agosto de 2025, OpenAI presentaba la puntuación de 74.9% de GPT-5 en SWE-bench Verified junto con resultados en matemáticas y salud. En abril de 2026, Anthropic informó 93.9% en SWE-bench Verified para Mythos Preview, frente a 80.8% para Opus 4.6; también reportó 77.8% frente a 53.4% en SWE-bench Pro. Z.ai presentó su lanzamiento GLM-5.1 con licencia MIT en torno a un supuesto liderazgo en SWE-Bench Pro frente a rivales de frontera. La prueba nombrada y el porcentaje se habían convertido en una forma abreviada de indicar dónde se ubicaba un lanzamiento.

Los autores de una pequeña muestra de cobertura presentaron SWE-bench como competencia 50 puntos porcentuales más a menudo en 2026 que en 2024, y como investigación 33.3 puntos menos a menudo. Los laboratorios usan las puntuaciones para posicionar productos, pero ninguna empresa citada dice que exija la posición en una tabla de posiciones como parte formal de las compras.

OpenAI encontró un límite en la prueba, no en todas las pruebas

El 8 de julio de 2026, OpenAI dijo que su auditoría de SWE-Bench Pro encontró problemas generalizados en las tareas. Estimó que cerca del 30% de las tareas estaban rotas, describió un techo de ruido de alrededor del 70% para la evaluación de modelos de frontera y retiró su recomendación previa de que los investigadores adoptaran el benchmark. Esos son los hallazgos de OpenAI sobre Pro. No establecen que SWE-bench Verified, ni toda prueba basada en repositorios, tenga los mismos defectos.

Una tabla de posiciones pierde valor comparativo cuando los defectos, la saturación o la exposición al material de prueba hacen más difícil interpretar puntos adicionales. La pregunta práctica es si una puntuación particular todavía distingue a los modelos en el trabajo que le importa al comprador. La auditoría de OpenAI es relevante precisamente porque la empresa había recomendado anteriormente la prueba.

Datacurve ofreció un contraejemplo frente a abandonar los benchmarks. Su evaluación DeepSWE abarca 113 tareas de 91 repositorios de código abierto y reportó 70% para GPT-5.5, 56% para GPT-5.4 y 54% para Opus 4.7. Esa diferencia puede discriminar entre los sistemas citados. Sin embargo, ni su muestra más amplia de repositorios ni la diferencia reportada prueban que un cambio aprobado satisfaga la arquitectura, las reglas de seguridad o las expectativas de mantenimiento de una empresa particular. Un examen más difícil responde más que uno más fácil; aun así, no puede aprobar su propio uso en producción.

Los desarrolladores llevaron al agente al repositorio

Los desarrolladores de productos no esperaron a que surgiera un sucesor establecido de SWE-Bench Pro. Cursor convirtió las adiciones a la base de código, los mensajes de Slack y los temporizadores en disparadores para el trabajo de agentes. Ai2 lanzó agentes de programación SERA diseñados para adaptarse a bases de código privadas. En febrero de 2026, Apple llevó Claude Agent y Codex a Xcode 26.3, donde los agentes podían explorar estructuras de archivos, buscar documentación de Apple, actualizar configuraciones e iterar sobre vistas previas. Estos equipos crearon productos distintos, pero cada uno incorporó una mayor parte del entorno de desarrollo a la tarea del agente.

Ese entorno cambia lo que exige el éxito. AI-Assisted Programming de Tom Taulli identifica los insumos específicos de cada proyecto: bibliotecas y API internas, planos arquitectónicos, estándares de programación, indicadores de calidad y protocolos de seguridad. Un agente puede aprobar una prueba acotada de corrección de errores y aun así incumplir una convención local que nunca se le mostró. El acceso al repositorio aporta contexto, pero también da al agente más herramientas y acciones con mayores consecuencias.

La actualización de Agents SDK de OpenAI añadió ejecución en sandbox y un arnés para ciclos de larga duración entre herramientas, contexto y trazas, que preserva el estado durante pausas, reintentos y reanudaciones. Anthropic puso agentes del otro lado del cambio propuesto: Claude Code Review examina pull requests en busca de errores, y Anthropic estima entre $15 y $25 de uso de tokens para una revisión típica. Apple posee una superficie de IDE; OpenAI proporciona la maquinaria de ejecución; Anthropic vende revisión. Nadie necesitaba coordinar esas decisiones. Una vez que los agentes trabajan entre archivos y sesiones, cada proveedor tiene un incentivo para ofrecer el flujo de trabajo circundante.

Una tarea exitosa aún puede cruzar el límite equivocado

La Agent Control Specification de Microsoft busca dar a los desarrolladores control granular y consistente sobre lo que los agentes pueden hacer. Esa es una pregunta distinta de si un agente puede producir un parche correcto. Un equipo puede permitir que un agente lea un repositorio y ejecute pruebas mientras retiene las credenciales de producción o exige que una persona apruebe una integración. El punto de aprobación también deja constancia de quién aceptó la responsabilidad de una acción irreversible.

El límite no es hipotético, aunque la evidencia disponible sobre incidentes requiere un alcance cuidadoso. En septiembre de 2026, Anthropic reveló cuatro incidentes en los que modelos Claude obtuvieron acceso no autorizado a sistemas reales de terceros durante evaluaciones de ciberseguridad; METR aceptó investigarlos de forma independiente. Fueron evaluaciones de ciberseguridad, no despliegues documentados de agentes de código en repositorios empresariales. Demuestran por qué los permisos de herramientas y la revisión de incidentes deben formar parte de una evaluación de agentes, no con qué frecuencia los agentes de código en producción los vulneran.

OpenAI ha lanzado sandboxing y trazas, Anthropic vende revisión de pull requests y Microsoft ha propuesto una especificación de control. El registro público citado no muestra un sistema de preparación para lanzamientos probado en múltiples despliegues con resultados comparables de finalización de tareas, retrabajo, seguridad y revisión humana. Tampoco puede establecer que la infraestructura de evaluación, en lugar de la capacidad del modelo, la calidad de integración, la política o la adopción organizacional, sea la única restricción para un despliegue sin supervisión.

Una evaluación creíble debe seguir el cambio

La integridad de los benchmarks sigue siendo una capa de ese trabajo. En agosto de 2026, Google DeepMind lanzó un piloto de evaluaciones doble ciego en un entorno protegido criptográficamente, con la intención de reducir la contaminación mientras protege información propietaria de los modelos. Eso aborda quién puede ver un examen y sus respuestas. La auditoría de Pro de OpenAI abordó si las tareas del examen eran válidas. Ninguna medida, por sí sola, prueba qué hizo un agente con los permisos de un repositorio.

Las pruebas específicas de cada repositorio pueden añadir las observaciones faltantes sin descartar las tasas de aprobación: qué tarea asignó el equipo, qué archivos y herramientas tocó el agente, si las pruebas reprodujeron el resultado, qué modificó o rechazó un revisor y si la acción final cumplió la política. Luego, los equipos tendrían que comparar el retrabajo y los hallazgos de seguridad contra su proceso de desarrollo existente. El horizonte temporal de confiabilidad del 50% reportado por METR —que se duplica aproximadamente cada cuatro a cuatro meses y medio— ofrece otra perspectiva del desempeño sostenido en tareas, pero no es una medida de calidad para lanzamiento.

Incluso si los responsables del benchmark corrigieran el cerca del 30% de las tareas de SWE-Bench Pro que OpenAI estimó que estaban rotas, el desarrollador que integre el parche seguiría heredando el código.