FrontierCode Diamond: 13,4 % de parches integrables en 50 tareas difíciles (junio de 2026)

Encontrarás materiales adicionales sobre la configuración de herramientas en la documentación de Ailoot.

¿Qué es FrontierCode y por qué es importante?#

Cognition es la empresa detrás de Devin (el primer ingeniero de IA autónomo, marzo de 2024) y Windsurf (adquirida en julio de 2025). También está desarrollando su propia línea de modelos SWE-1.x. El benchmark se publicó en el blog público en cognition.com/blog/frontier-code.

El cambio clave no tiene que ver con nuevas cifras. Tiene que ver con la escala que se usa ahora para medir las cosas.

El benchmark tiene tres niveles de dificultad: Extended (150 tareas, el conjunto completo), Main (las 100 tareas más difíciles, incluida Diamond) y Diamond (50 tareas extremadamente difíciles). Cognition dejó deliberadamente Diamond «en gran medida sin saturar»: incluso el mejor modelo resuelve menos del 15 %. La intención es que el benchmark tenga margen para un año y evitar que se sature en un mes, como ocurrió con HumanEval.

Qué mide FrontierCode: «¿Aceptaría el mantenedor esta PR?»#

Los seis ejes de evaluación (según el blog oficial de Cognition):

1. Corrección funcional — ¿resuelve el parche la tarea?
2. Seguridad frente a regresiones — ¿evita romper el código existente?
3. Limpieza técnica — ¿supera las comprobaciones de compilación, lint y estilo?
4. Corrección de las pruebas — ¿son válidas las pruebas escritas por el agente (las pruebas que pasan con cualquier código no cuentan)?
5. Alcance — ¿evita el parche modificar archivos que no se solicitaron?
6. Calidad del código — ¿sigue el código las convenciones del proyecto y es legible?

Para que un parche cuente como integrable, debe superar los seis ejes. Si falla aunque sea en uno, no se aceptará.

Ese es el principal cambio de perspectiva. «La corrección es ahora lo mínimo exigible», como dice Cognition. Antes, los benchmarks preguntaban: «¿Pasó el código las pruebas?». Ahora preguntan: «¿Aceptaría un responsable técnico real incorporar esto al proyecto?»

Cognition introdujo tres técnicas nuevas de evaluación:

• Reverse-Classical: una prueba escrita por un agente debe fallar en una versión defectuosa del código. De lo contrario, la prueba es un engaño.
• Code Scope: un verificador automatizado comprueba que el parche se ciña a los archivos y al número de líneas acordados para la tarea.
• Adaptive Classical Grading: la herramienta LLM «mutagent» adapta pruebas estrictas a variantes válidas de una solución.

¿Por qué ya no funcionan los benchmarks antiguos?#

Los agentes de IA ya habían superado HumanEval con facilidad en 2024. SWE-bench Verified es muy parecido: en agosto de 2025, OpenAI reconoció públicamente el problema de contaminación (los modelos habían «visto» el conjunto de datos durante el entrenamiento). Los benchmarks perdieron su capacidad para distinguir entre los mejores modelos.

El estudio clave que puso en entredicho el criterio anterior se publicó en marzo de 2026.

Esto fue lo que hicieron:

• Seleccionaron a 4 mantenedores activos de 3 repositorios (scikit-learn, Sphinx, pytest).
• Les pidieron evaluar 296 PR generadas por IA de SWE-bench Verified; todas esas PR habían superado las pruebas automatizadas.
• Compararon las decisiones de los mantenedores con las del evaluador automatizado.

En otras palabras, el benchmark dice «superada», mientras que el mantenedor dice «no se integrará», y esto ocurre en una cuarta parte de los casos, en promedio. Los 3 principales motivos de rechazo, del menos al más grave:

1. Calidad del código — no coincide con el estilo del repositorio.
2. Rompe otro código — rompe el código cercano.
3. Fallo de la funcionalidad principal — no resuelve la tarea por completo, aunque la prueba esté en verde.

FrontierCode formaliza exactamente este problema. Cognition tomó esta idea y la amplió para crear un benchmark completo con más de 20 mantenedores en lugar de 4.

Otro clavo en el ataúd es un estudio de diciembre de 2025 sobre la seguridad de los parches generados por IA.

En él, el 61 % de las soluciones de SWE-Agent con Claude 4 Sonnet eran funcionalmente correctas, pero solo el 10.5 % eran seguras.

El código pasa la prueba y, sin embargo, uno de cada dos parches introduce una vulnerabilidad de seguridad. Esto no se ve en absoluto en los benchmarks SWE-bench: no miden la seguridad. FrontierCode al menos intenta detectarlo mediante los ejes de «limpieza técnica» y calidad del código.

Clasificación de los modelos: Opus 4.8 con 13.4 %, GPT-5.5 con 6.3 %#

Esto es lo que destaca en la tabla:

• Un líder claro. Opus 4.8 de Anthropic está aproximadamente el doble de lejos por delante que su competidor más cercano. La diferencia que costaba ver en SWE-bench se aprecia claramente en FrontierCode.
• Los modelos abiertos aún no han alcanzado a los demás. Kimi K2.6 —el mejor modelo de código abierto— obtiene un 3.8 % en Diamond. Eso es 3–4 veces menos que Opus 4.8. Cognition no publicó una tabla completa de Kimi K2.6 para Main y Extended, por lo que aún no hay comparación en el conjunto completo.
• Cognition colocó con honestidad su propio modelo en la parte baja de la tabla.

El subconjunto Diamond se dejó deliberadamente «sin saturar». Cognition incorporó un margen de seguridad para los próximos años. Si los benchmarks anteriores se saturaban en 12–18 meses, FrontierCode está diseñado para tener un techo más alto.

¿Qué significa «13 % integrable» para alguien que hace vibe coding con Claude Code?#

Primero, una aclaración importante: el conjunto Diamond de FrontierCode es deliberadamente muy difícil. En tareas corrientes de un proyecto nuevo de una startup sin cuarenta módulos dependientes, un agente de IA obtiene resultados claramente mejores. El mismo Opus 4.8 logra un 51.8 % de soluciones integrables en Extended (150 tareas, el conjunto completo). La situación es muy distinta.

El 51,8 % corresponde a las 150 tareas de Extended. Es mayor que el resultado de Diamond, pero ninguna cifra estima la integración de los parches de cualquier modelo en tus tareas. La falta de puntuaciones Main o Extended de otros modelos no permite inventar su rendimiento.

Qué significa esto para quienes hacen vibe coding y llevan código a producción:

• Una prueba en verde ya no significa «listo para integrar». Las pruebas escritas por la propia IA pueden ser inútiles: pasan con cualquier código. FrontierCode lo mide directamente con Reverse-Classical: si una prueba no falla con una versión defectuosa, no cuenta.
• Importan el estilo y las convenciones del repositorio. Si un proyecto tiene un patrón establecido y la IA no lo sigue, un colaborador real no aceptará el cambio. En proyectos personales sin reglas, no es gran cosa. En un equipo, es el problema número uno.
• Las pruebas no resuelven la seguridad. Recuerda la cifra anterior: solo el 10.5 % de los parches es seguro, aunque el 61 % sea correcto. Esto hay que comprobarlo por separado con herramientas que detecten tokens, archivos .env y contraseñas predeterminadas.
• Exceder el alcance de la tarea es un error típico de la IA. Le pides que corrija una función de autorización y recibes un parche que también reescribió la capa interna y el registro. Este es uno de los 6 ejes de FrontierCode.

¿Qué 6 categorías de errores comete la IA en tareas difíciles?#

Repasemos cada eje en términos sencillos:

1. Corrección funcional — ¿resuelve el parche la tarea?

El eje más básico. La IA suele escribir código que parece una solución, pero resuelve el problema equivocado. Le pido que «añada una confirmación de lectura al mensaje» y obtengo una función markAsRead, pero no la ha conectado al componente de chat. La prueba de la función pasa. La tarea de negocio no está resuelta.

2. Seguridad frente a regresiones — ¿evita romper el código cercano?

La IA cambia un módulo y ahora otro no funciona. El caso más común: un agente de IA cambia la firma de una función y olvida que se llama desde otros 17 lugares. Esto no se ve en SWE-bench: allí solo ejecutan pruebas para un archivo. En FrontierCode ejecutan toda la suite de pruebas del repositorio.

3. Limpieza técnica — ¿supera las comprobaciones de compilación, lint y estilo?

La IA puede producir código que compila localmente, pero falla en CI: falta una importación, hay tabulaciones en vez de espacios, dos espacios al final de una línea o un error en eslint.config.js. En un proyecto en producción, el estilo no es un capricho; es una regla del equipo.

4. Corrección de las pruebas — ¿son válidas las pruebas escritas por la IA?

El eje más complicado. La IA escribe una prueba que pasa. Pero pasa con cualquier código, incluso con código defectuoso. Lo he visto muchas veces: la prueba comprueba «¿se bloqueó el script?», pero no «¿devolvió el resultado correcto?». Reverse-Classical de FrontierCode detecta precisamente este caso.

5. Alcance — ¿evita el parche tocar archivos que no tienen relación?

Le pido que corrija una función y obtengo un parche para 12 archivos, incluidos archivos que no tienen nada que ver con la tarea. Esa misma «iniciativa» de la IA puede romper un proyecto de producción al cambiar cosas que no le pedí que cambiara. Este eje es un impedimento absoluto en FrontierCode.

6. Calidad del código — ¿sigue el código las convenciones del repositorio?

La IA escribe su propia función «desde cero» en vez de usar las funciones auxiliares existentes en lib/. O pone nombres a las variables que no coinciden con el estilo del proyecto. O coloca la lógica en la capa arquitectónica equivocada. Desde el punto de vista de la prueba, todo funciona. Desde el del responsable técnico, no se integrará.

Cómo comprobar el código de IA antes de hacer push: 5 pasos#

1. Ejecuta toda la suite de pruebas, no solo las relacionadas con el cambio

   La IA suele modificar código que va más allá de la tarea. El problema aparecerá en las pruebas de las partes cercanas. Ejecuto la suite de pruebas completa (con el único comando npm test, sin una ruta), no solo las pruebas de un archivo concreto. En proyectos grandes, resulta práctico hacerlo en paralelo mediante un git worktree (consulta Git worktree en Claude Code).

2. Ejecuta las comprobaciones de lint, estilo y tipos

   Tres comandos en este orden: eslint ., prettier --check ., tsc --noEmit. Un agente de IA puede pasar por alto tanto las tabulaciones como un espacio de más al final de una línea. Si el proyecto tiene comprobaciones estrictas, ejecútalas localmente antes de publicarlo.

3. Comprueba la propia prueba

   La más importante de las 5 comprobaciones. Introduzco un pequeño «fallo» en el código (cambio return true por return false). La prueba debería fallar. Si la prueba no falla, la IA la escribió solo para aparentar y no sirve. La borro y le pido a la IA que la vuelva a escribir con una condición obligatoria: debe fallar con la versión defectuosa.

4. Comprueba qué archivos ha tocado la IA

   El comando git diff --stat muestra qué archivos han cambiado y cuántas líneas. Si la IA tocó 12 archivos en respuesta a «arregla el formulario de contacto», se salió del alcance de la tarea. Revierto los cambios adicionales con un único comando para el archivo.

5. Ejecuta una comprobación de seguridad con una skill lista para usar

   Las pruebas no detectan inyecciones SQL ni contraseñas codificadas en el código. Uso una skill de seguridad lista para usar para Claude Code (consulta 754 skills de seguridad listas para usar). Como mínimo, busca manualmente en el proyecto las palabras «password», «secret» y «key» y comprueba que .env.example esté completo.

Los 5 pasos cubren 5 de los 6 ejes de FrontierCode (1–5). El sexto eje —la calidad del código— se comprueba automáticamente mediante linting y con una revisión humana.

¿Qué mejora de verdad las probabilidades de obtener código integrable?#

Un agente de IA en un proyecto sin preparar solo ve el archivo que has abierto para él. No conoce tu historial de decisiones ni tus convenciones, y no tiene un mapa de tus módulos. Para cambios sencillos no importa demasiado. Para cambios difíciles, la falta de contexto es un riesgo que conviene abordar. El 13,4 % del benchmark no aísla la calidad del contexto como causa.

Qué tienes que hacer para convertir ese 13 % en algo que realmente puedas llevar a producción:

1. Reglas del proyecto — para que la IA reproduzca tu razonamiento en vez del promedio de Internet.

Es un conjunto de tus soluciones preparadas, hábitos y reglas aprendidas en un formato que el agente de IA lee con cada solicitud. Cuando hay 30+ reglas, la IA deja de inventar el «promedio del sector» y empieza a sugerir cosas a tu estilo. Puedes abordar las desviaciones del alcance de la tarea con una sola línea en las reglas: «no toques archivos que no se mencionen expresamente en la solicitud».

2. Un mapa del proyecto — una carpeta que describe el proyecto.

Ahí guardas productos, público, economía, métricas y configuraciones. Antes de cada solicitud, el agente de IA lee el índice y entiende en qué parte del negocio está trabajando. Así se abordan automáticamente dos de los motivos de rechazo mencionados antes: el estilo y romper otro código.

3. Context Engineering — controlar lo que ve la IA antes de la solicitud.

No se trata de «cómo redactar un prompt», sino de «qué poner en la ventana de contexto ANTES del prompt». CLAUDE.md, requisitos previos y enlaces dirigidos a archivos. Esto aborda los fallos de corrección funcional y calidad del código.

Usa la combinación como preparación para las comprobaciones, no como prueba de que cinco ejes ya se superan. Verifica comportamiento, regresiones, pruebas, alcance y calidad del código en el parche real antes de aceptarlo.

Una capa adicional son los agentes de revisión:

• Cursor Bugbot — revisa cada PR. Según Cursor, la herramienta procesa alrededor de 2 millones de PR al mes.
• Subagentes anidados en Claude Code v2.1.172 — un agente escribe el código, otro lo revisa y un tercero ejecuta las pruebas. Es la misma idea que FrontierCode: separar los papeles de «quien escribe» y «responsable técnico».

Consulta también: Seguridad en vibe coding, Cómo configurar Claude Code para que no rompa tu proyecto por la noche y Context Engineering como concepto.

Encontrarás materiales adicionales sobre cómo trabajar con herramientas en la documentación de Ailoot.