El 23 de febrero, el equipo Frontier Evals de OpenAI publicó un post explicando por qué dejó de reportar puntajes de SWE-bench Verified. La auditoría encontró que el 59.4% de los casos de prueba más difíciles del benchmark tienen defectos fundamentales — pruebas que exigen nombres de función exactos no mencionados en los enunciados del problema, o verifican comportamiento no relacionado. Más condenatorio: cada modelo frontera mayor probado — GPT-5.2, Claude Opus 4.5, Gemini 3 Flash — podía reproducir las soluciones gold-patch verbatim de memoria usando solo el task ID. La conclusión de OpenAI fue directa: "Las mejoras en SWE-bench Verified ya no reflejan mejoras significativas en las capacidades de desarrollo de software de los modelos en el mundo real". Recomiendan SWE-bench Pro en su lugar. Tres meses después, el resto de la industria de agentes de coding sigue clasificándose en el bench contaminado.

Los números actuales en la parte alta de la tabla que se publican son: Claude Code en Opus 4.7 al 87.6%, OpenAI Codex en GPT-5.5 a aproximadamente 88.7% (rastreador de terceros; OpenAI mismo no se auto-reporta), Gemini CLI al 80.6%, OpenHands al 72%, Augment Code al 70.6% auto-reportado en su propio harness, Cursor alrededor del 51.7% en defaults, GitHub Copilot alrededor del 56%. En SWE-bench Pro — la alternativa que OpenAI ahora recomienda — los mismos modelos se sientan mucho más bajo: Claude Opus 4.7 al 64.3%, GPT-5.5 al 58.6%. Terminal-Bench 2.0 es el otro benchmark que se ha mantenido creíble: Codex al 82.7%, Claude Code al 69.4%, Gemini CLI al 68.5%. La brecha entre las dos familias de benchmarks es en sí misma la señal: cuando los puntajes de un eval comprimen los modelos contra el techo y los puntajes de otro eval los separan, el segundo está haciendo el trabajo de discriminación.

El problema más profundo es la brecha entre maximizar-benchmark y maximizar-productividad. El scaffolding de agente solo produce aproximadamente ±17 problemas de varianza en los mismos modelos, lo que significa que las elecciones de harness pueden dominar la elección de modelo en cualquier corrida dada. Ninguna de las clasificaciones públicas viene con una especificación de harness publicada, así que las comparaciones apples-to-apples entre vendors no se están corriendo realmente — solo apples-vs-los-números-propios-de-cada-vendor. La implicación práctica para builders es que la comparación correcta no es "qué agente lidera SWE-bench Verified" sino "qué agente resuelve mis tareas en mi codebase con mi CI y mis convenciones de estilo". El método empírico que funciona es correr 50 a 100 tareas de tu backlog real contra dos o tres candidatos y medir resultados en lugar de puntajes.

El patrón de recomendación que realmente se ajusta a los datos es un stack en capas en lugar de una apuesta a una sola herramienta. Los agentes de terminal — Claude Code o Codex — ganan su costo en refactors multi-archivo, cambios arquitectónicos, y el tipo de debugging que de otra manera quemaría la tarde de un ingeniero senior. Las extensiones IDE — Cursor o GitHub Copilot — ganan los suyos en completaciones inline, ediciones rápidas, y asistencia ambiental durante trabajo de rutina. Los agentes open-source — Aider, Cline, OpenHands — ganan los suyos cuando quieres intercambiar modelos, evitar el markup de plataforma, o auditar el comportamiento del agente de extremo a extremo. Usar más de uno no es indecisión; es la respuesta honesta a la especialización. Lado benchmark: SWE-bench Verified ya no es tu amigo. SWE-bench Pro, Terminal-Bench 2.0, y tu propia codebase, sí lo son.