Lo que el mapa de benchmarks de julio 2026 realmente le dice a la función de adquisiciones
Tres números llegaron al escritorio del comprador empresarial este mes, y cada uno se está leyendo contra el artefacto equivocado. Claude Opus 4.8 de Anthropic marca 88.6% en SWE-bench Verified — el número publicado más alto del leaderboard de agentes-de-código. Codex + GPT-5.5 de OpenAI marca 83.4% en Terminal-Bench 2.1, por delante de Claude Code + Fable 5 con 83.1%. Y según el agregado del Q2 2026 sobre sistemas de IA agéntica empresarial, la brecha puntuación-de-benchmark-de-lab a rendimiento-de-despliegue-en-producción es de 37 puntos porcentuales en promedio, con una varianza de costo por agente de 50× para el mismo nivel de precisión.
Las lecturas operativamente importantes:
- La puntuación de 88.6% en SWE-bench Verified es el titular de marketing del proveedor, y es el artefacto equivocado para la decisión de compra empresarial. SWE-bench Verified califica contra tareas de un-solo-repo, un-solo-issue con el contrato de test ya escrito. La carga de trabajo de agentes-de-código empresarial son refactorizaciones multi-archivo contra un contrato de test parcial, actualizaciones de dependencias contra un conjunto de pins de registro privado, extracción estructurada contra un esquema cuyas invariantes viven en una ruta de código legacy. El número 88.6% no pone precio contra la forma de la carga de trabajo empresarial; la repetición por clase-de-carga-de-trabajo contra el propio repositorio del equipo sí.
- El leaderboard de Terminal-Bench 2.1 se cierra a una brecha de error-de-redondeo en la cima, y el flip de orden semana-a-semana no es una señal por clase-de-carga-de-trabajo. 83.4% contra 83.1% es un delta de 0.3 puntos sobre un benchmark de 200 tareas — el ranking flipea a medida que el benchmark se refresca. El equipo que enruta su lista corta de FY27 contra el ranking de Terminal-Bench de la semana pasada persigue el leaderboard como blanco móvil, no escribe la política de enrutamiento contra la envolvente de portabilidad por clase-de-carga-de-trabajo que el contrato permanente respalda.
- La brecha lab-a-producción de 37 puntos es el artefacto que el pitch deck del proveedor no muestra, y la varianza de costo de 50× es el artefacto contra el que firma el CFO. La brecha es donde el andamiaje-optimizado-para-benchmark del proveedor deja de portar, la topología real del repo del equipo deja de coincidir con el arnés del benchmark, y el verificador por clase-de-carga-de-trabajo deja de dispararse a la tasa a la que se dispara el arnés del benchmark. La varianza de costo de 50× es lo que sucede cuando el equipo escribe la política de enrutamiento de modelos contra el número de precisión y no pone precio al costo por token, al presupuesto de turnos por agente, y al multiplicador de reintentos por tarea que vienen con el mismo nivel de precisión.
La lectura estructural no es los benchmarks están rotos. Es que el leaderboard califica contra una forma que la carga de trabajo de agentes-de-código empresarial no cumple, la repetición por clase-de-carga-de-trabajo contra el propio repositorio del equipo es la señal portante para la política de enrutamiento, y el artefacto de eval-de-dominio — no el benchmark del proveedor — es contra lo que la negociación del contrato permanente de FY27 debería calificar.
Lo que el leaderboard mide versus lo que necesita la decisión de compra
SWE-bench Verified mide el cierre de tarea de un-solo-issue, un-solo-repo contra un contrato de test escrito. El benchmark es un artefacto riguroso para la pregunta de investigación de capacidad de agente-de-código contra la forma de SWE-bench. No es el artefacto para la pregunta de adquisición de qué agente sobrevive al contacto con el monorepo privado del equipo. Las dos preguntas califican contra distribuciones diferentes de edad del código base, complejidad del grafo de dependencias, densidad de cobertura de tests, y deriva de convenciones del repositorio. El equipo que lanza la lista corta de FY27 contra la puntuación de SWE-bench Verified está calificando su decisión de compra contra una distribución que no incluye su propio código.
Terminal-Bench 2.1 mide la completitud de tarea end-to-end en un sandbox de terminal contra un conjunto curado de tareas. El benchmark califica andamiaje-más-modelo como un sistema integrado — el mismo modelo en un arnés diferente devuelve una puntuación diferente. El número 83.4% de Codex + GPT-5.5 no es portable al arnés de Claude Code; el número 83.1% de Claude Code + Fable 5 no es portable al arnés de Codex. El equipo que lee el leaderboard como un ranking por modelo está tratando una señal por modelo × por arnés como si la variable de arnés hubiera sido controlada.
SWE-bench Pro es donde la forma del leaderboard se acerca más a la forma de la carga de trabajo empresarial. El laboratorio SEAL de Scale AI construyó SWE-bench Pro con cambios multi-archivo reales sobre repositorios a escala empresarial, andamiaje estandarizado con un límite de 250 turnos, y tooling idéntico por agente — la variable de arnés se controla. La lectura portante para la lista corta de FY27 es el rango de SWE-bench Pro, no el rango de SWE-bench Verified; Pro califica contra la forma más cercana a la carga de trabajo empresarial, y la variable-controlada de arnés significa que la puntuación compara agentes en lugar de pares agente-arnés.
La repetición por clase-de-carga-de-trabajo contra el propio repositorio del equipo es el eval-de-dominio que cierra la brecha de 37 puntos. El eval-de-dominio no es un benchmark — es un artefacto por equipo: los 30 tickets más representativos de los últimos dos sprints del equipo, repetidos contra cada agente candidato, calificados contra la propia suite de tests del equipo, y puntuados contra tasa-de-éxito por clase-de-carga-de-trabajo, costo-por-token por tarea, latencia p95 por tarea, presupuesto de turnos consumido por tarea, y tasa de intervención-humana-requerida por tarea. El eval-de-dominio es donde el rango de marketing del proveedor se encuentra con el código real del equipo, y el artefacto es lo que cierra la brecha de decisión-de-compra que el leaderboard del proveedor no puede cerrar.
Por qué la varianza de costo de 50× aparece en el escritorio del CFO
Mismo nivel de precisión no significa mismo costo por tarea exitosa. Dos agentes que ambos marcan 78% en el eval-de-dominio del equipo pueden cargar un delta de costo por tarea exitosa de 50× impulsado por tres variables que la puntuación del benchmark no superficie: el nivel de precio por token (Fable 5 con precio-API versus Sonnet 5 promocional versus Gemini 3.5 Flash), el presupuesto de turnos por tarea que el andamiaje del agente consume (un agente que resuelve la tarea en 12 turnos cuesta 5× menos que uno que la resuelve en 60 turnos al mismo costo por token), y el multiplicador de reintentos por tarea que el arnés carga cuando el primer intento falla (el arnés que despliega dos workers paralelos en reintento duplica el costo por tarea exitosa contra un arnés que reintenta en un solo worker).
El costo por tarea exitosa es la métrica contra la que el presupuesto de FY27 califica, no el precio por token que el proveedor publica. El precio por token es una entrada al costo por tarea exitosa; el presupuesto de turnos por tarea, el multiplicador de reintentos por tarea, y la tasa de intervención humana por tarea son las otras tres. El equipo que califica la política de enrutamiento contra el precio por token está subestimando la cola del presupuesto de FY27 por el factor de las variables ignoradas.
La latencia p95 por tarea es la variable de SLO que impulsa la UX por característica, y el rango del leaderboard no la superficie. Un agente que completa 78% de tareas con latencia p50 de 40 segundos y p95 de 12 minutos lanza el p95 a la envolvente de la característica cara-al-cliente; un agente que completa 78% de tareas con p50 de 90 segundos y p95 de 3 minutos lanza una cola más apretada. La característica cara-al-cliente califica contra el p95, no contra el p50 ni contra la media. El artefacto SLO por característica del equipo califica contra el p95, y el p95 no aparece en el leaderboard.
Cómo se ve el flujo de trabajo de lista corta cuando califica contra el eval-de-dominio
Paso 1: cortar la lista corta de cuatro a dos sobre el rango de benchmark publicado, no sobre lealtad al proveedor. El mapa de cuatro proveedores frontera (Anthropic, OpenAI, Google, y un sustrato de pesos abiertos) es la lista corta de partida honesta. El rango de SWE-bench Pro y el rango de Terminal-Bench 2.1 cortan la lista corta a los dos agentes cuya forma de leaderboard está más cerca de la forma de la carga de trabajo empresarial — para la mayoría de los equipos, los dos primeros son Claude Code + Fable 5 (u Opus 4.8) y Codex + GPT-5.5 (o GPT-5.6 donde el equipo tenga acceso). Las otras dos entradas frontera se quedan en la envolvente de portabilidad como ruta de reemplazo de segunda fuente, no en la lista corta.
Paso 2: correr el eval-de-dominio contra los dos agentes de la lista corta sobre el código real del equipo. El eval-de-dominio toma 30 tickets representativos de los últimos dos sprints, los envuelve en el mismo arnés de prompt con el que la característica de producción se lanzará, corre cada ticket contra cada agente sobre andamiaje idéntico, y captura tasa de éxito por clase-de-carga-de-trabajo, costo por token por tarea, presupuesto de turnos por tarea, latencia p95 por tarea, y tasa de intervención humana por tarea. El eval-de-dominio es un artefacto de ingeniería de dos semanas — no un benchmark de seis meses — y es la señal portante para el artefacto de política de enrutamiento que el equipo lanza al repo.
Paso 3: escribir la política de enrutamiento por prompt contra la matriz del eval-de-dominio, no contra el rango del leaderboard. El artefacto de política codifica la decisión de ruta-por-defecto por clase-de-carga-de-trabajo, la decisión de ruta-de-escalamiento por clase-de-carga-de-trabajo, el techo de presupuesto de turnos por clase-de-carga-de-trabajo, y la regla de reintento por clase-de-carga-de-trabajo. El artefacto es versionado en el repo del equipo, referenciado desde la biblioteca cliente por característica, y re-calificado por trimestre contra el eval-de-dominio refrescado.
Paso 4: negociar el contrato permanente de FY27 contra la envolvente de portabilidad por clase-de-carga-de-trabajo que el eval-de-dominio superficie. La envolvente especifica el sustrato de fallback por clase-de-carga-de-trabajo al que el equipo puede enrutar con 30 días de aviso de un deslizamiento de capacidad del proveedor, la cadencia trimestral de re-shootout por clase-de-carga-de-trabajo que el equipo corre contra el sustrato, y el compromiso por proveedor contra el gasto agregado que el contrato permanente carga. La envolvente es lo que hace el contrato permanente portable; sin ella, el contrato es un compromiso de gasto por proveedor sin rampa de salida contra el riesgo de cambio-de-sustrato que la frontera de FY28 seguirá lanzando.
Dónde la brecha de 37 puntos es señal y dónde es ruido
Señal: la brecha no se está reduciendo, y la frontera de FY28 no la cerrará. Cada refresco de leaderboard mueve el número tope-de-leaderboard hacia arriba; la forma de la carga de trabajo empresarial no cambia a la misma tasa. El equipo que difiere el artefacto de eval-de-dominio hasta que el leaderboard rompa 95% está difiriendo contra una brecha que es una característica duradera del desajuste-de-forma benchmark-versus-carga-de-trabajo, no una consecuencia transitoria de la madurez de los modelos actuales.
Señal: la varianza de costo por agente de 50× se concentra en las variables del arnés, no en las variables del modelo. La matriz del eval-de-dominio es lo que superficie la concentración; la tabla de precios por token es lo que superficie el pitch deck del proveedor. El equipo que califica contra el pitch deck del proveedor está subestimando las variables del arnés que impulsan el costo por tarea exitosa.
Ruido: el leaderboard está roto, así que todos los benchmarks son inútiles es la sobrecorrección equivocada. El leaderboard es una señal para el corte de lista corta — SWE-bench Pro y Terminal-Bench 2.1 cortan el campo de cuatro proveedores a dos candidatos. El error es tratar el leaderboard como la señal de decisión de compra; el eval-de-dominio es la señal de decisión-de-compra, y el leaderboard es la señal de corte-de-lista-corta.
Ruido: el eval-de-dominio es demasiado caro para correr por trimestre subestima el costo de re-calificación por ciclo. El eval-de-dominio de 30 tickets corre en dos semanas-ingeniero contra el propio repositorio del equipo. La re-calificación por trimestre contra el eval-de-dominio refrescado es el artefacto que mantiene la política de enrutamiento honesta contra la cadencia de cambio-de-sustrato contra la que la frontera lanza. El equipo que se salta la re-calificación por trimestre está corriendo la política de FY27 contra el eval-de-dominio de FY26 para el Q4 y lee la regresión de KPI contra el cambio-de-sustrato que el eval-de-dominio habría superficializado.
Lo que el equipo de ingeniería debería hacer en las próximas cuatro semanas
Lanzar el arnés de eval-de-dominio de 30 tickets contra los dos agentes tope de la lista corta. Sacar los 30 tickets más representativos de los últimos dos sprints, envolverlos en el arnés de prompt de producción, y correr cada ticket contra cada agente de la lista corta sobre andamiaje idéntico. La salida es la matriz por clase-de-carga-de-trabajo contra la que la política de enrutamiento califica.
Instrumentar el presupuesto de turnos por tarea, la latencia p95 por tarea, y la tasa de intervención humana por tarea sobre la superficie de agente-de-código de producción. Las tres métricas son las que cierran la brecha lab-a-producción de 37 puntos en la propia superficie de observabilidad del equipo. Sin ellas, el equipo lee la regresión de KPI como ruido; con ellas, el equipo califica la decisión de enrutamiento por clase-de-carga-de-trabajo contra el sustrato sobre el que el agente realmente corre.
Escribir la envolvente de portabilidad por clase-de-carga-de-trabajo contra la lista corta de dos agentes y la ruta de reemplazo de segunda fuente. La envolvente codifica el sustrato de fallback por clase-de-carga-de-trabajo, la cadencia de re-shootout por trimestre, y el compromiso por proveedor contra el contrato permanente. La envolvente es el artefacto contra el que la negociación del contrato permanente de FY27 califica.
Re-calificar la matriz de eval-de-dominio por trimestre y re-escribir la política de enrutamiento contra el refresco. El eval-de-dominio es la señal portante; la política de enrutamiento es el artefacto que el equipo lanza al repo; la re-calificación por trimestre es lo que mantiene los dos en sincronía contra la cadencia de cambio-de-sustrato contra la que la frontera lanza.
En SONNET CODE corremos el engagement de Desarrollo de IA contra la matriz por clase-de-carga-de-trabajo del eval-de-dominio — arneses de eval-de-dominio de 30 tickets sobre el propio repositorio del equipo, políticas de enrutamiento por clase-de-carga-de-trabajo contra el mapa de cuatro proveedores frontera, envolventes de portabilidad por proveedor sobre el contrato permanente de FY27, y re-shootouts por trimestre contra el sustrato refrescado. Si tu equipo está comprando contra el rango de SWE-bench Verified, agenda una llamada — te llevamos por el artefacto de eval-de-dominio que lanzamos en cuatro semanas.
