Cognition lanza FrontierCode 2.0: el mejor resultado es solo un 45,5%

Cognition, la compañía detrás del agente Devin, ha publicado FrontierCode 2.0, la segunda generación de un benchmark que no mide si el código pasa los tests, sino su «mergeabilidad»: si el mantenedor de un proyecto real aceptaría ese pull request. El mejor resultado es el de Claude Opus 5.5, con 45,5%. En la versión anterior, FrontierCode 1.1, tenía 54,6%. La distancia entre modelos es ahora más visible y el techo queda lejos: el benchmark no está saturado.

Por qué Cognition ha endurecido el listón

Según la experiencia de Devin, el desarrollo agéntico está lejos de ser un problema resuelto. Los modelos adivinan mal la intención del usuario, incumplen restricciones poco evidentes y no prevén las consecuencias a largo plazo de sus cambios, así que una persona tiene que intervenir. La mayoría de los benchmarks de código no capta este problema: ofrecen una especificación detallada y se saturan rápido. Un ejemplo es la tarea vf2-speedup-networkx de Terminal-Bench 4.0, que describe por completo el enfoque, el formato y las condiciones de verificación, incluida una aceleración de al menos 5000 veces.

FrontierCode funciona de otra manera. Más de 20 mantenedores de proyectos abiertos dedicaron más de 40 horas a cada tarea, que construyeron a partir de sus propios repositorios. En la versión 2.

0, las tareas proceden de un 55% más de repositorios e incluyen parches de seguridad y optimizaciones de rendimiento. Hay un 43% más de criterios bloqueantes. Las soluciones de referencia modifican, de media, un 67% más de archivos y un 89% más de líneas, y las bases de código son un 25% mayores.

Cognition ha reforzado además la auditoría: en el 80% de las tareas la solución de referencia difiere del PR upstream (en la 1.0 era el 60%). Una de las auditorías automáticas llegó a encontrar una vulnerabilidad en la implementación upstream, y se comunicó a los mantenedores.

Tabla: quién perdió cuánto

A continuación, las puntuaciones en formato «FrontierCode 1.1 → FrontierCode 2.0»:

• Claude Opus 5.5 — 54,6% → 45,5%. Líder; está en la frontera de Pareto, en el extremo caro.
• GPT-6 Astra — 53,3% → 42,8%.
• Grok 4.7 — 47,6% → 28,6%.
• Gemini 4 Argon — 47,5% → 26,3%.
• Muse Wonder 1.0 — 47,0% → 24,3%.
• SWE-2 — 50,0% → 23,9%.
• DeepSeek V4.1 Flash — 43,9% → 19,3%.
• Kimi K3 — 44,2% → 17,7%.

En la frontera de Pareto «precio — calidad» están, junto con Opus 5.5, Luna, Haiku y Sol en el extremo barato. Cognition destaca aparte a GPT-6.1 Sol por su buen resultado en relación con el coste. La conclusión sobre los modelos abiertos es dura: hay mucho margen de mejora, y más aún en los modelos OSS occidentales.

Minuciosidad en lugar de obediencia

El cambio principal es el aumento del peso de los criterios de «thoroughness»: el número de bloqueantes de este tipo ha subido de 168 a 501, es decir, se ha triplicado. Estos criterios comprueban lo que el agente debe deducir de la instrucción y del código aunque no se diga de forma explícita. Por ejemplo, corregir un bug en todos los lugares donde aparece y no solo en el que se menciona, o admitir tipos de entrada vecinos si código similar ya los maneja.

La proporción de comprobaciones fallidas en esta categoría ha subido de 11,7% a 19,2%, la mayor tasa de fallos entre todas las categorías. En core behavior es 14,9% frente a 9,5%, y en compatibilidad hacia atrás, 5,9% frente a 2,9%.

Las demás categorías de bloqueantes han cambiado así: core behavior 399 → 353, evitar regresiones 174 → 259, calidad de los tests 202 → 213, lint/format/typecheck 112 → 183, scope 56 → 123, compatibilidad hacia atrás 85 → 76, compilación 86 → 69, integridad de los tests 48 → 48.

Más esfuerzo no siempre es mejor

FrontierCode no premia la cantidad de código escrito, por lo que la puntuación puede bajar al subir el nivel de razonamiento. La causa son los criterios de scope. En Claude Opus 5, la proporción de criterios de scope superados cae de 69,2% en low a 51,1% en max; en Opus 4.

8, de 81,9% a 70,9%; en Claude Fable 5, de 79,1% a 63,4%; y en GPT-5.6 Sol, de 79,7% a 68,3%. Al mismo tiempo, los criterios de implementación suben: en Opus 5, de 79,3% a 83,0%.

Con más «esfuerzo», los modelos tocan más archivos, a veces innecesarios. Entre las causas menos importantes, Cognition cita un mayor número de trampas (la carga accidental del commit con la solución) y el «replanteamiento excesivo», cuando el modelo se convence de una lectura errónea de la tarea.

En la versión 2.0 se han suavizado los requisitos de scope para no penalizar comportamientos inesperados pero aceptables: la proporción media de fallos bajó de 9,0% a 3,8%. En el conjunto formado por Claude Opus 5.5, Claude Fable 5.1, GPT-6.1 Sol y GPT-6 Astra, la minuciosidad falla en el 26,0% de las comprobaciones en low y en el 15,3% en max.

El ejemplo de Mock Service Worker es revelador: la tarea consistía en corregir un bug por el que resetHandlers() no reinicia los resolvers generadores. Opus 5.5 no superó ninguna de las cinco ejecuciones en ningún nivel de esfuerzo, de low a max: la corrección funcionaba como se pedía, pero el evaluador señaló el propio enfoque del cambio.

Qué deben tener en cuenta los equipos

Si eliges un modelo para programación autónoma, no te fijes en el pass@1 de tareas bien descritas, sino en su comportamiento ante un prompt incompleto. En la práctica: prevé revisiones de código que busquen cambios colaterales y casos «vecinos» omitidos, no fijes por defecto el máximo reasoning effort sin medirlo en tus propios repositorios y compara los modelos por el coste de cada ejecución, no solo por la puntuación. Para el stack open source, los resultados de 2.0 son un motivo para reservar margen para el ajuste manual.