Tag: Evals

Hace tres días salió Claude Opus 5.5. Antes de que terminara el día tenía cinco mensajes distintos preguntándome lo mismo: ¿es el mejor para programar ahora?

Mi respuesta debería haber sido fácil. No lo fue.

El problema no es falta de datos. La mayoría de los benchmarks de IA para programar que circulan hoy no miden lo que dicen medir. Hace unas semanas expliqué por qué el 96% de SWE-bench Verified es ruido — contaminación de datos, tests rotos, un puñado de repos repetidos hasta el cansancio. Si no lo leíste, el resumen cabe en una frase: ese número no predice si el modelo te sirve a ti.

Eso deja una pregunta sin responder, y me la hicieron cinco veces esta semana: vale, ¿pero entonces qué SÍ miro? No es solo "el coste por tarea" — de eso ya hablé aparte. Es más concreto que eso.

En corto: los benchmarks de IA para programar que importan en 2026 son los que resisten la contaminación con datasets privados o rotativos, miden tareas multi-paso sobre entornos reales — no snippets sueltos — y reportan tasa de éxito junto al coste por tarea. Terminal-Bench, el subset privado de SWE-bench Pro, el time-horizon de METR y las arenas con voto humano cumplen esas condiciones mejor que cualquier leaderboard de un solo número. Pero la señal más fiable no la publica ningún laboratorio: es el eval que montas tú mismo sobre tickets ya cerrados de tu propio repo.

¿Qué es un benchmark de IA para programar?

Un benchmark de IA para programar es un conjunto fijo de tareas de código con un criterio de éxito objetivo — tests que pasan, un PR que mergea sin romper nada — que se usa para comparar modelos o herramientas de forma reproducible.

Esa definición esconde la trampa: "reproducible" no significa "representativo". Puedes sacar un resultado perfecto en 500 tareas de Django y que eso no prediga nada sobre tu backend en Go o tu monorepo de TypeScript.

Los benchmarks fallan por tres motivos: el dataset se filtra al entrenamiento de la siguiente generación de modelos, las tareas son demasiado pequeñas para parecerse a trabajo real, y casi ninguno reporta el coste de llegar al resultado. Arreglar esos tres puntos separa un benchmark útil de uno decorativo.

Las señales que sí predicen algo en 2026

Datasets que se resisten a la contaminación

SWE-bench Pro nació para resolver el problema de memorización. Su subset público usa código con licencia copyleft (GPL) precisamente porque esa licencia "viral" hace improbable que entre en datasets de entrenamiento — pero sigue siendo código técnicamente indexable.

La parte que sí es genuinamente invisible para cualquier modelo es el subset privado, hecho con codebases 100% propietarios de 18 startups que nunca salieron de la infraestructura interna de Scale. Ahí es donde cae el rendimiento en serio: Claude Opus 4.1 pasa de 22,7% a 17,8% de resolución, y GPT-5 de 23,1% a 14,9%, según los datos publicados por Scale AI. Esa caída — y no el número público — es la que te dice cuánto del "96%" original era memoria y cuánto era capacidad real.

Evals multi-paso sobre entornos reales: Terminal-Bench

Terminal-Bench no pide generar una función: pide operar una terminal completa — instalar dependencias, compilar en varios lenguajes, depurar un fallo del sistema y verificar que el resultado final funciona de punta a punta. Se parece mucho más a un día de trabajo real que resolver un issue de una línea.

En la versión 4.0, GPT-6 Astra lidera con 58,2%, Claude Fable 5.1 queda a 0,3 puntos con 57,9%, y GLM-5.3 se queda en 41,8% — cifras del leaderboard de septiembre de 2026. Lo interesante no es quién gana: según los mismos datos, Opus 5.5 iguala a GPT-6 Astra por cerca del 40% del coste por tarea — el mismo argumento de coste que desarrollé en el post sobre agentic systems. Medir tareas de terminal completas es más honesto que medir un parche aislado, porque obliga al modelo a manejar el mismo desorden que un desarrollador maneja todos los días.

El eval con feedback real: Aider Polyglot

Aider Polyglot evalúa 225 ejercicios de Exercism en seis lenguajes con dos intentos: en el segundo, el modelo recibe el error real de los tests que falló en el primero. Mide algo que casi ningún benchmark mide — si el modelo sabe iterar con feedback, que es como trabajas tú con un agente en el día a día.

GPT-5 lidera con 0,880 sobre casi 60 modelos evaluados. Lo que vale la pena mirar no es el primer puesto, sino la distancia entre el primer y el segundo intento: ahí ves si un modelo corrige su error o lo repite.

La curva, no la foto: el time-horizon de METR

METR no compara modelos entre sí: mide la duración de tarea (en tiempo humano) que un modelo resuelve con 50% de éxito, y sigue esa cifra en el tiempo. Según su modelo, en 2024-2025 esa duración se dobló cada 4 meses, frente al ritmo de 7 meses que se mantuvo entre 2019 y 2025.

Este benchmark no te dice qué herramienta elegir hoy — te dice si conviene re-evaluar tu stack cada trimestre o si puedes esperar tranquilo. Es la única señal de esta lista pensada para planear, no para decidir ya.

Arena Elo con voto humano

WebDev Arena y Copilot Arena hacen algo que ningún leaderboard automático hace: ponen a dos modelos a resolver la misma tarea y dejan que un desarrollador real vote a ciegas cuál prefiere. WebDev Arena acumula más de 80.000 votos con un modelo Bradley-Terry, el mismo sistema detrás del Elo de ajedrez.

La ventaja: ningún laboratorio puede optimizar tan fácil para "gustarle más a un humano a ciegas" como puede optimizar para un test set conocido. La desventaja, en la siguiente sección.

Tu propio eval sobre tickets cerrados

Esta es la señal que ningún leaderboard público te va a dar, y es la más fiable de todas.

En el hilo de Hacker News sobre Real-SWE — un benchmark construido sobre código privado de empresas reales — el dato que más se repite es este: el modelo que lidera SWE-bench Verified con más del 90% de resolución cae por debajo del 40% cuando el código es privado y nunca lo vio en entrenamiento.

Lo mismo aparece en el hilo sobre el benchmark que corrió Databricks contra su propio monorepo de millones de líneas: los agentes que brillan en demos cortas se atascan en cuanto el contexto supera lo que cualquier dataset público simula.

La conclusión no es "desconfía de todo": tu repo es, literalmente, el benchmark más resistente a la contaminación que existe, porque nadie más lo tiene. Así lo montas:

1. Saca 15-20 tickets ya cerrados de los últimos tres meses, con PR mergeado y tests en verde.
2. Convierte el criterio de aceptación de cada ticket en un test o script de verificación automática — esto es, literalmente, revisar por contrato antes de aceptar código de un agente.
3. Corre el modelo o herramienta candidata contra cada ticket sin que vea la solución original.
4. Mide tres números por tarea: ¿pasó?, cuánto tardó, cuánto costó en tokens o en API.
5. Repite el mismo set cada vez que cambies de modelo — así tu decisión no depende de lo que un laboratorio decida publicar esa semana.

Comparativa: qué benchmark mirar y qué esconde cada uno

Cuándo NO fiarte de un benchmark

Cuando no reporta coste ni latencia junto al éxito. Un benchmark que solo enseña "resolución" es publicidad, no medida — un modelo puede ganar en tasa de éxito y perder si triplica el gasto para llegar ahí. Más sobre esto aquí.

Cuando el dataset lleva más de medio año circulando en abierto. SWE-bench Verified subió de 74,9% a 80,9% en seis meses sin que la capacidad real de los modelos diera ese salto — eso es saturación, no progreso.

Cuando el ranking lo publica el mismo laboratorio que compite en él. Nadie audita sus propios deberes con objetividad — por eso el subset privado de SWE-bench Pro, sobre código que los labs no han visto, vale más que cualquier leaderboard propio.

Cuando el dominio del benchmark no es el tuyo. Terminal-Bench mide shell, compilación y DevOps — no te dice si un modelo escribe buenos componentes de UI o una migración de base de datos limpia. Adapta la pregunta al benchmark, no al revés.

Qué hacer con esto hoy

La próxima vez que un modelo salga con un número enorme en portada, no preguntes cuánto sacó — pregunta en qué dataset, público o privado, y con qué coste llegó ahí. Si no puedes responder las tres, el número no sirve para decidir nada.

Móntate el set de 15-20 tickets esta semana, no cuando salga el siguiente modelo. Es el mismo criterio de escribir la especificación antes de generar código que enseño en Construye con IA, y la plantilla de eval la comparto en Dominicode Labs.

Preguntas frecuentes

¿Qué benchmark debo mirar si solo tengo tiempo para uno?

Ninguno público. Monta tu propio set de 15-20 tickets cerrados de tu repo — toma una tarde y te dice más que cualquier leaderboard general. Si quieres una referencia externa, Terminal-Bench es hoy la más honesta porque exige resolver tareas completas, no un fragmento aislado.

¿Terminal-Bench sirve para evaluar modelos para desarrollo frontend?

No directamente. Terminal-Bench mide tareas de shell, compilación y DevOps — un modelo puede sacar 58% ahí y ser mediocre escribiendo componentes de interfaz. Úsalo como señal de capacidad general para seguir instrucciones en varios pasos, no como predictor de calidad en frontend.

¿SWE-bench Pro ya resolvió el problema de la contaminación?

Solo en su subset privado. La parte pública usa código con licencia GPL precisamente para dificultar que entre en datasets de entrenamiento, pero sigue siendo código técnicamente indexable — no tan hermético como el subset privado, hecho con codebases 100% propietarios que Scale nunca publicó. La caída de hasta ocho puntos que reporta Scale AI al pasar a código privado es la prueba de cuánta capacidad real hay detrás del número público.

¿Cómo monto mi propio eval sin gastar semanas en ello?

Con 15 tickets cerrados es suficiente para empezar. No necesitas infraestructura nueva: conviertes el criterio de aceptación de cada ticket en un test automático, corres el candidato contra esos 15 casos y mides éxito, tiempo y coste. Es el proceso que detallo en el ebook gratuito "Revisión por Contrato".

¿Vale la pena perseguir el ranking cada vez que sale un modelo nuevo?

No. El time-horizon de METR muestra que la capacidad sube de forma predecible — perseguir cada lanzamiento individual es ruido. Lo que vale la pena es correr tu propio set cada vez que cambies de modelo en producción, no cada vez que sale un post nuevo de benchmarks.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

En mayo me pasaron la factura de OpenAI de una empresa de soporte. 1.600 $ al mes.

Fui a ver en qué se gastaba. No era un agente sofisticado: era un clasificador de tickets. Llega un mensaje, el modelo decide si es facturación, bug, acceso o feature, le pone prioridad y marca si necesita un humano.

Doscientos mil tickets al mes por el modelo más caro que tenían en producción. Acertaba el 96 %, pero pagaban precio de razonamiento frontera por una tarea de cinco respuestas.

Llevaban seis meses regalando el mejor argumento a favor de la destilación de modelos: el modelo caro ya había resuelto ese problema doscientas mil veces, y esas respuestas se borraban cada noche.

En corto: la destilación de modelos consiste en usar las salidas de un modelo grande (teacher) como datos de entrenamiento para uno pequeño (student). El pequeño reproduce su comportamiento en una tarea concreta a una fracción del coste. Gana cuando la tarea es estrecha, repetitiva y de alto volumen; pierde en cuanto la tarea cambia o necesita generalizar fuera de lo que viste al construir el dataset.

¿Qué es la destilación de modelos?

La destilación de modelos (model distillation) es entrenar un modelo pequeño —el student— para que imite el comportamiento de uno grande —el teacher— en una tarea específica, usando como dataset las respuestas que el grande ya ha generado.

La idea tiene once años y viene de Hinton, Vinyals y Dean (2015), que la propusieron para comprimir el conocimiento de un ensemble de redes en un único modelo desplegable. Lo que ha cambiado no es la técnica. Es que ahora el profesor cobra por token.

El caso más visible son los DeepSeek-R1 distilled: cogieron 800.000 muestras curadas con R1 y con ellas hicieron fine-tuning supervisado de modelos base Qwen2.5 (1.5B a 32B) y Llama (8B y 70B). Sin refuerzo, solo SFT sobre las salidas del grande. El de 32B reporta 72,6 en AIME 2024 y 94,3 en MATH-500.

Un modelo de 32B razonando cerca de uno de cientos de miles de millones de parámetros. Ese es el truco entero.

Destilación no es fine-tuning, ni RAG, ni cuantización

Destilación y fine-tuning clásico comparten mecanismo y se diferencian en quién pone las etiquetas: un modelo en la destilación, una persona en el fine-tuning. RAG no toca los pesos y la cuantización no cambia el comportamiento.

Aquí es donde casi todo el mundo se lía, y es lo que decide si tu proyecto funciona. Las cinco técnicas suenan parecidas porque todas prometen "mejor o más barato", pero cada una toca una pieza distinta:

La distinción que importa: destilación y fine-tuning clásico son el mismo mecanismo con distinta procedencia de las etiquetas. Destilar es fine-tuning donde el etiquetador es una máquina que ya sabe hacerlo. Eso es lo que lo vuelve viable, porque el cuello de botella del fine-tuning nunca fue el entrenamiento: era conseguir diez mil ejemplos etiquetados de forma consistente.

Y la que más confunde: la cuantización no es destilación. Cuantizar es coger ese mismo modelo y guardar sus pesos con menos bits. No hay profesor, ni alumno, ni dataset. Es compresión, no transferencia. Si lo que quieres es correr un modelo en tu máquina sin tocar su comportamiento, eso es cuantización, y va por la guía de modelos para correr en local.

Escribí hace tiempo sobre cuándo usar RAG, fine-tuning o simplemente más contexto. La destilación es la cuarta opción de ese mismo debate, y la que menos gente considera, porque suena a paper. No lo es: OpenAI y AWS tienen botones para hacerlo.

¿Cuánto cuesta destilar un modelo y cuánto ahorra?

Destilar un clasificador que hace 200.000 llamadas al mes cuesta unos 112 $ una sola vez y baja la factura mensual de 1.600 $ a 31,20 $. Se amortiza en poco más de dos días.

Volvamos a los tickets. Doscientas mil clasificaciones al mes, unos 700 tokens de entrada y 20 de salida cada una: 140 millones de tokens de entrada y 4 millones de salida.

Con los precios públicos de la API de OpenAI a septiembre de 2026:

Fíjate en un detalle que casi nadie anticipa: un modelo destilado cuesta exactamente el doble que su versión base. OpenAI cobra 0,20 $ de entrada por el nano ajustado frente a 0,10 $ del nano de catálogo. Es la prima por servir tus pesos. Si en tu presupuesto pusiste el precio base, tu presupuesto está a la mitad de la realidad.

Y fíjate en lo que dice esa tabla si la lees entera: el nano de catálogo sale por 15,60 $, la mitad que el destilado. La destilación no es lo que compras para ahorrar; es lo que compras cuando el nano de catálogo no pasa tus evals y la alternativa era seguir pagando 1.600 $.

Aun así, el salto de 1.600 $ a 31,20 $ son 51 veces. Eso no lo consigue ningún prompt.

Y es una cota baja: la tabla carga los mismos 700 tokens de entrada a todas las filas, también al destilado, que en realidad va con un prompt mucho más corto. Ahora vemos por qué.

¿Y cuánto cuesta destilar? La parte facturable es ridícula:

• Generar 10.000 ejemplos con Astra: 7M de entrada a 10 $ más 0,2M de salida a 50 $ = 80 $.
• Entrenar el nano: 7,2M de tokens de entrenamiento a 1,50 $ el millón ≈ 11 $ por época, unos 32 $ con tres épocas.

112 $ para ahorrar 1.569 $ al mes. Se amortiza en poco más de dos días.

Esto es el mismo razonamiento que aplico en coste por tarea en lugar de precio por token, llevado al caso extremo: una tarea tan estrecha que cabe entera en los pesos de un nano.

Y si trabajas en español, el tokenizador cobra alrededor de un 26 % más por el mismo texto en castellano: un argumento más a favor de destilar, porque ese sobrecoste lo pagas en cada llamada mientras sigas con el grande. El desglose del precio por tarea del frontera está en el análisis de GPT-6 Astra.

Cómo se construye el dataset para destilar un modelo

El dataset se construye filtrando las salidas del teacher contra un esquema y descartando las que no validan, nunca corrigiéndolas a mano. La destilación no falla en el entrenamiento: falla porque el dataset está sucio.

Aquí la teoría se estrella contra el suelo.

El teacher acierta el 96 %, sí. Pero también devuelve JSON malformado, inventa categorías que no están en tu enum y se contradice en casos límite. Si esos ejemplos entran al entrenamiento, no estás destilando conocimiento: estás enseñando a tu modelo pequeño a equivocarse con seguridad.

La regla es simple: valida la salida del teacher contra un esquema antes de que entre al dataset, y descarta lo que no pase. No lo arregles a mano. Descártalo.

import { z } from 'zod'
import OpenAI from 'openai'

const openai = new OpenAI()

// El contrato de salida. Si el teacher no lo cumple, el ejemplo no entra.
const TicketLabel = z.object({
  category: z.enum(['facturacion', 'bug', 'acceso', 'feature', 'otro']),
  priority: z.enum(['baja', 'media', 'alta']),
  needsHuman: z.boolean(),
})

type TicketLabel = z.infer<typeof TicketLabel>

async function labelWithTeacher(ticket: string): Promise<TicketLabel | null> {
  const response = await openai.responses.create({
    model: 'gpt-6-astra',
    input: [
      { role: 'system', content: LONG_PROMPT }, // el prompt largo, con reglas y casos límite
      { role: 'user', content: ticket },
    ],
    text: { format: { type: 'json_object' } },
  })

  let raw: unknown
  try {
    raw = JSON.parse(response.output_text)
  } catch {
    return null // JSON malformado: fuera del dataset
  }

  const parsed = TicketLabel.safeParse(raw)
  return parsed.success ? parsed.data : null
}

Podrías forzar el esquema en la API con json_schema, pero entonces no verías lo que el teacher hace mal. Aquí lo que interesa es medir cuánto descartas.

Y ahora el detalle del JSONL que decide tu factura:

import { appendFile } from 'node:fs/promises'

for (const ticket of tickets) {
  const label = await labelWithTeacher(ticket.body)
  if (!label) continue // ejemplo sucio: fuera

  await appendFile('dataset.jsonl', JSON.stringify({
    messages: [
      { role: 'system', content: SHORT_PROMPT }, // el prompt CORTO, no el largo
      { role: 'user', content: ticket.body },
      { role: 'assistant', content: JSON.stringify(label) },
    ],
  }) + '\n')
}

Ese SHORT_PROMPT puede partir por la mitad la factura del student, y se explica en una frase: el teacher necesita el prompt largo con todas las reglas; el student se las aprende en los pesos. Si entrenas con el prompt largo, condenas al modelo pequeño a reenviarlo en cada llamada para siempre y tiras por la ventana buena parte de la reducción de tokens.

Tratar los esquemas como contrato —y no como validación decorativa— es lo que enseño en el curso de Zod. En destilación deja de ser higiene y pasa a ser el filtro que decide la calidad de tu modelo.

OpenAI te ahorra parte de este trabajo: la Responses API guarda las respuestas 30 días por defecto, así que puedes filtrar tus salidas reales de producción en vez de generarlas de cero.

Amazon Bedrock Model Distillation hace lo mismo con los invocation logs de CloudWatch y automatiza el ciclo entero. Si activas sus técnicas de síntesis de datos, amplía tu dataset hasta un máximo de 15.000 pares prompt-respuesta, y te factura aparte esas llamadas extra al teacher.

Qué dicen los que ya han destilado un modelo en producción

En el hilo de Hacker News Distillation makes AI models smaller and cheaper hay dos comentarios que valen más que la mitad de los artículos sobre el tema.

El primero, de NitpickLawyer, sobre cuántos ejemplos hacen falta de verdad: "you can use as few as 1-2k traces to reach similar results. Much cheaper." Mil o dos mil trazas, no cien mil. Encaja con lo que recomienda OpenAI, que sugiere arrancar el fine-tuning con 50 demostraciones bien hechas y medir antes de escalar.

El segundo, de v3ss0n, resume el riesgo en cuatro palabras: "Sometimes better, sometimes dumber."

Esa es la frase honesta. El student no hereda el 100 % del teacher: hereda su comportamiento en la distribución de datos que le enseñaste. A veces mejora, porque se especializa. A veces se vuelve tonto justo en el caso raro que no estaba en tus 10.000 ejemplos.

Por eso el orden correcto es: primero las evals, después destilar. Sin forma automática de comparar student contra teacher sobre casos difíciles, no sabrás cuál de las dos te ha tocado. Lo conté en evals deterministas para agentes de IA: mide el dato que sale, no el texto que lo envuelve. En clasificación es trivial, y es justo lo que hace que destilar sea seguro aquí y peligroso en tareas abiertas.

Cuándo NO destilar un modelo

Cinco situaciones en las que esto se te vuelve en contra. Las he visto todas.

1. La tarea cambia cada mes. Un modelo destilado es una foto del comportamiento del teacher el día que generaste el dataset. Si añades dos categorías de ticket en octubre, el student no las conoce y no hay prompt que lo arregle: toca regenerar dataset y reentrenar. Con un modelo de catálogo eso son diez minutos editando texto.

2. No tienes volumen. Los 112 $ se amortizan en dos días con 200.000 llamadas al mes. Con 2.000 llamadas no se amortizan nunca. Por debajo de unas decenas de miles de llamadas mensuales, quédate en el modelo pequeño de catálogo con un buen prompt.

3. Los términos de servicio de tu proveedor. Destilar gpt-6-astra en gpt-4.1-nano dentro de OpenAI es una función que ellos te venden. Sacar las salidas para entrenar un Qwen que corres tú es otra conversación, y merece leerse los Business Terms con alguien de legal delante.

4. El proveedor puede quitarte el botón. No es teórico. La documentación de Bedrock dice hoy, textualmente, que "Distillation is not currently available for Anthropic models on Amazon Bedrock", sin plazo de restauración. Si montas tu arquitectura de costes sobre destilar Claude en Bedrock, ese pilar ahora mismo no existe. Y ojo al despliegue: con los modelos de Llama el job corre en US West (Oregón), y servir el destilado pasa por comprar provisioned throughput —coste fijo mensual, no precio por token— o copiarlo a otra región y comprarlo allí.

5. Necesitas que generalice. Si tu caso de uso es "un asistente que responde de todo", destilar es exactamente lo contrario de lo que quieres. La destilación compra rendimiento en una distribución estrecha pagando con generalidad. Para un clasificador es el negocio del siglo. Para un copiloto de propósito general es amputarse una pierna para correr más rápido.

Cómo empezar a destilar: los tres pasos de esta semana

No empieces destilando. Empieza midiendo.

Coge tu tarea más repetitiva —la que llama al modelo miles de veces al día con el mismo prompt— y haz tres cosas esta semana, en este orden:

1. Monta 50 casos de eval con la respuesta correcta conocida, incluyendo los diez casos raros que te preocupan.
2. Pasa esos 50 casos por el modelo pequeño de catálogo con tu prompt actual. Si aguanta, has terminado: cambia el modelo y ahórrate el proyecto entero. Este paso se lo salta demasiada gente, porque destilar suena más interesante que probar el nano.
3. Solo si el pequeño falla, genera 1.000 ejemplos con el teacher, valídalos contra un esquema, entrena y vuelve a pasar los mismos 50 casos.

La decisión no la toma tu intuición sobre lo difícil que es la tarea. La toma esa tabla de 50 filas.

Si quieres montar el sistema completo alrededor de esto —el harness, los contratos de salida y las evals que hacen que un flujo con IA sea fiable y no solo demostrable— es lo que trabajamos en Construye con IA.

Y en Dominicode Labs está el pipeline de destilación con el validador de dataset y el script de evals que usamos en producción.

Preguntas frecuentes

¿Qué diferencia hay entre destilación y fine-tuning?

Son el mismo mecanismo con distinta procedencia de las etiquetas. En el fine-tuning clásico las etiquetas las produce una persona; en la destilación las produce otro modelo, el teacher. Eso cambia el cuello de botella entero: conseguir diez mil ejemplos etiquetados por humanos de forma consistente cuesta meses, y generarlos con un modelo frontera cuesta 80 $ y una tarde.

¿Qué son el modelo teacher y el modelo student?

El teacher es el modelo grande y caro cuyo comportamiento quieres reproducir; el student es el modelo pequeño que se entrena con sus salidas. En una destilación dentro de la plataforma de OpenAI, un par típico es GPT-6 Astra como teacher y GPT-4.1-nano como student. En Amazon Bedrock, Amazon Nova Pro como teacher y Nova Micro o Nova Lite como student.

¿Cuántos ejemplos necesito para destilar un modelo?

Menos de los que crees. OpenAI recomienda empezar el fine-tuning con 50 demostraciones bien construidas y medir antes de escalar, y los rangos que reportan los profesionales van de 1.000 a 2.000 trazas para clasificación o extracción. Para razonamiento la cifra sube mucho: los DeepSeek-R1 distilled se entrenaron con 800.000 muestras curadas. El número de ejemplos escala con la variedad de la tarea, no con su dificultad.

¿Cuál es la diferencia entre destilación de modelos y cuantización?

Son operaciones distintas que solo comparten el objetivo de abaratar. La cuantización coge un modelo y guarda sus pesos con menos bits —de 16 a 4, por ejemplo— para que ocupe menos memoria: es el mismo modelo comprimido, sin entrenamiento ni datos nuevos. La destilación entrena un modelo diferente y más pequeño usando las salidas del grande como dataset, y el resultado es otro modelo con otros pesos. Puedes hacer las dos cosas: destilar un Qwen de 7B y después cuantizarlo a 4 bits para que quepa en tu portátil.

¿Puedo destilar GPT o Claude en un modelo open source?

Técnicamente sí, y mucha gente lo hace. Legalmente depende del contrato que hayas firmado. Los Business Terms de OpenAI, en su redacción de mayo de 2025, prohíben usar el Output para desarrollar modelos de IA que compitan con sus productos y servicios, salvo excepción permitida, y otros proveedores tienen cláusulas equivalentes. Destilar dentro de la plataforma del proveedor (Astra a nano en OpenAI, Nova Pro a Nova Micro en Bedrock) es una función que te venden ellos y no tiene discusión. Sacar las salidas para entrenar un modelo que corres tú conviene revisarlo con alguien de legal, no con un post de blog.

¿La destilación sustituye a RAG?

No, resuelven problemas distintos y a menudo conviven. RAG inyecta conocimiento que cambia —documentación, catálogo, tickets recientes— en el contexto de la consulta. La destilación graba comportamiento en los pesos: cómo clasificar, qué formato devolver, qué criterio aplicar. Si el modelo no sabe el precio actual de un producto, destilar no ayuda en nada y RAG sí. Si el modelo pequeño no sigue tu criterio de prioridad, RAG no ayuda y destilar sí. En un clasificador sobre documentación viva querrás las dos.

¿Cómo sé si el modelo destilado aguanta en producción?

Con evals deterministas sobre un conjunto fijo de casos, ejecutadas antes y después. En clasificación o extracción es directo, porque la salida es estructurada y comparas el campo, no el texto. Lo mínimo viable es un set de 50 a 100 casos con la respuesta correcta conocida, sesgado a propósito hacia los casos límite. Si el student pierde más de lo que tu negocio tolera en los casos raros, la conclusión no siempre es descartar la destilación: a veces es enrutar, mandar el 95 % fácil al student y el 5 % dudoso al teacher. Esa arquitectura híbrida suele dar la mejor relación coste-precisión.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

"AI Is Already Better at Coding Than Most Software Developers."

El titular circula en inglés y provoca siempre dos reacciones. El que lo comparte con un "ya está, se acabó". Y el que responde "pues a mí me inventó un import que no existe".

Los dos discuten la conclusión sin mirar de dónde sale. Y sale de un sitio concreto: los benchmarks de IA programando. De uno solo, en realidad. SWE-bench Verified.

La tesis, y no te va a gustar ninguna de sus dos mitades: el titular es literalmente cierto en el examen. Y el examen se rompió.

No porque la IA sea mala escribiendo código —es buenísima—, sino porque mide una tarea que no se parece a tu trabajo: un bug de cinco líneas, en un repo que el modelo ya había visto, con los tests ya escritos por otro.

En corto: OpenAI dejó de reportar ese benchmark por saturación, tests rotos y contaminación. El 91% de sus tareas son bugs de menos de una hora.

De dónde sale el número: un leaderboard con todos empatados

Snapshot del leaderboard de SWE-bench Verified a 15 de septiembre de 2026:

Ahí tienes el 96% del titular. Y el primer problema no es el 96, sino la distancia entre filas: menos de un punto entre los tres punteros.

Un examen en el que todos sacan la misma nota ha dejado de ser un examen. Es un sello.

SWE-bench Verified es un benchmark de 500 tareas construidas a partir de issues reales de GitHub en repositorios de Python populares: el modelo recibe el repo y el enunciado del issue, y tiene que entregar un parche que pase una suite de tests ya escrita. Sobre el papel suena exactamente a tu trabajo. Por eso el titular funciona tan bien, y por eso conviene abrir la caja.

Por qué OpenAI retiró SWE-bench Verified

Esto no lo dice un escéptico de la IA con ganas de tráfico. Lo dice OpenAI, en un post titulado "Why SWE-bench Verified no longer measures frontier coding capabilities", y lo confirman Mia Glaese y Olivia Watkins, de su equipo de Frontier Evals, en esta entrevista.

Tres razones, las tres con número.

Saturación. El estado del arte pasó de 74,9% a 80,9% en seis meses. Cuando la aguja apenas se mueve ya no mides capacidad: mides techo.

Tests rotos. Auditaron el subconjunto de problemas que los modelos fallan una y otra vez, un 27,6% del dataset: seis ingenieros revisaron 138 problemas a mano. Más del 59% tienen tests defectuosos que rechazan soluciones funcionalmente correctas: unos demasiado estrechos, otros demasiado amplios, que exigen features ni siquiera documentadas en el enunciado.

Traducido: parte de lo que el leaderboard cuenta como fallo del modelo es un fallo del corrector.

Contaminación. Esta es la peor. Dándoles solo el Task ID —sin enunciado y sin código—, todos los modelos frontera auditados (GPT-5.2, Claude Opus 4.5, Gemini 3 Flash) reproducen el parche correcto o el enunciado verbatim.

Parte de la nota es memoria. No razonamiento. Y no hay forma de saber qué parte.

La recomendación de OpenAI es reportar SWE-bench Pro en su lugar. Guárdate ese nombre.

Qué mide de verdad el examen

Epoch AI analizó tarea por tarea qué hay dentro de esas 500 muestras:

El parche medio de ese trabajo va de cinco a catorce líneas. Y un análisis de Amazon sobre el mismo dataset, recogido por Epoch: el 78% de los cambios tocan funciones, no clases, con 1,87 funciones de media.

La diversidad es peor que el tamaño. Doce repositorios, y los cinco mayores concentran más del 80% de las muestras. Casi la mitad es Django, de los proyectos Python más presentes en cualquier corpus de entrenamiento. La mitad de los issues son anteriores a 2020, en un dataset construido en octubre de 2023.

Conclusión literal de Epoch: mide "arreglar issues pequeños y bien definidos" en "repos de Python open source familiares".

Falta el detalle que más duele, y no sale en ninguna tabla: los tests ya vienen escritos. La parte difícil —decidir qué significa "correcto" en este sistema y para estos usuarios— venía hecha antes de que el modelo empezara.

Los parches que pasan sin resolver nada

SWE-Bench+ auditó los parches que el benchmark daba por buenos. El 32,67% son solution leakage: la solución venía escrita en el propio issue o en sus comentarios. Otro 31,08% queda como sospechoso: pasa con tests demasiado débiles para garantizar que el parche arregle algo.

Al filtrar ambos casos, SWE-Agent con GPT-4 cae de 12,47% a 3,97%. Mismo modelo. La nota se divide por tres.

SWE-bench Pro vs SWE-bench Verified: 27 puntos de diferencia

SWE-bench Pro, de Scale AI, está diseñado para resistir la contaminación. Mismo modelo, dos exámenes, febrero de 2026: 80,8% en Verified y 53,4% en Pro. Veintisiete puntos por cambiar el papel del examen.

Pasa lo mismo fuera de Python. Terminal-Bench 2.0 mide 16 categorías de tareas de terminal en Docker y en septiembre de 2026 sus líderes van altísimos: GPT-5.6 Sol 91,9%, Claude Mythos 5 88,0%, GPT-5.6 Terra 87,4%.

Ahora coge TerminalWorld-Verified, con escenarios más parecidos a un entorno real: los modelos evaluados allí, con marcas de entre 57% y 82,7% en Terminal-Bench 2.0, caen a un rango de 49% a 62,5%.

El número no describe al modelo. Describe al examen.

Un diseño mejor existe: SWE-Lancer usa más de 1.400 encargos freelance de Upwork con un millón de dólares en pagos reales, y pregunta si el trabajo se habría cobrado. Cítalo por el diseño, no por el marcador: es de febrero de 2025.

Qué mide ese 96% y qué mide tu lunes

Nada de esto significa que la IA no programe bien. Programa muy bien, y cada mes mejor.

Significa otra cosa, más incómoda: el número que usas para decidir no mide lo que crees. Mide velocidad en una tarea acotada, con el criterio de corrección regalado, sobre repos que el modelo ya conocía. Tu lunes no se parece a eso: repo privado que no estuvo en ningún corpus, requisitos a medio escribir y ninguna suite que te diga si lo que acabas de aceptar está bien.

Hay un experimento que mide esa brecha. METR hizo un ensayo aleatorizado con 16 developers open source experimentados sobre 246 tareas reales en sus propios repositorios: más de 22.000 estrellas y más de un millón de líneas de media cada uno. Estimaron que irían un 24% más rápido con IA. Al terminar creían haber ido un 20% más rápido. La medición decía que habían sido un 19% más lentos.

Y la advertencia sin la cual ese dato no se puede usar: el estudio es de julio de 2025, con Cursor Pro y Claude 3.5/3.7. Modelos viejos. No describe el rendimiento de las herramientas de hoy, y quien lo cite como si lo hiciera te está vendiendo algo.

Sirve para una sola cosa, y es suficiente: nadie sabe si va más rápido hasta que lo mide. Ni tú ni yo. Es la conclusión a la que llegué desde otro camino cuando escribí que el cuello de botella ya no es escribir código, sino verificarlo.

Cómo evaluar código generado por IA en tu repo: 4 pasos

El leaderboard no te va a decir si un modelo te sirve. Eso lo mides tú, en tu repo. Cuatro pasos:

1. Congela veinte tareas tuyas. Veinte PRs de tu proyecto ya cerrados, de dificultad variada. Ese es tu benchmark privado: no está en ningún corpus y se parece a tu trabajo por construcción. Cómo montarlo lo detallo en evals de código generado por IA.
2. Escribe tú el criterio, y antes. Aquí está el fallo que copian los benchmarks: los tests los puso otro. Define el contrato —entradas, salidas, errores, invariantes— antes de pedir el código. Eso es revisión por contrato para código de agentes de IA, la diferencia entre revisar un diff y auditar una promesa. Si quieres el método completo, descarga el ebook gratuito.
3. Mide tiempo, no sensación. Cronómetro desde que abres la tarea hasta que pasa code review, reescrituras incluidas. Ese es el único número que importa.
4. Compara en tu harness, no en el ranking. El mismo modelo con distinto contexto, herramientas y reglas rinde de forma muy diferente. La variable que más mueve tu resultado casi nunca es el modelo.

Es la mecánica del curso Construye con IA y el principio del libro Spec-Driven Development: sin criterio escrito antes no evalúas nada, ni a un modelo ni a un humano.

Cifras verificadas a 17 de septiembre de 2026.

La próxima vez que veas un titular con un porcentaje, haz una sola pregunta antes de compartirlo o de indignarte: ¿qué examen era?

Casi siempre, la respuesta explica el titular entero.

Preguntas frecuentes

¿Qué es exactamente SWE-bench Verified?

Un benchmark de 500 tareas construidas a partir de issues reales de GitHub en repositorios de Python populares. Al modelo se le da el repo y la descripción del issue, y tiene que producir un parche que pase una suite de tests ya existente. Es el número detrás de casi todos los titulares sobre IA programando. Su problema no es que sea falso: su perfil de tarea —bugs pequeños, repos muy conocidos, criterio de corrección regalado— se parece poco al trabajo diario en una base de código privada.

Si OpenAI dejó de usarlo, ¿por qué todo el mundo lo sigue reportando?

SWE-bench Verified se sigue reportando por inercia y por comparabilidad: todos los modelos anteriores tienen una puntuación ahí, así que es la única cifra que permite poner dos años de lanzamientos en la misma tabla. OpenAI recomienda reportar SWE-bench Pro en su lugar, y lo razonable es leer las dos juntas. La diferencia entre ambas te dice más que cualquiera por separado.

Entonces, ¿los benchmarks de IA programando no sirven para nada?

Sirven para una pregunta más estrecha de la que se les hace: comparar modelos bajo condiciones idénticas y detectar regresiones entre versiones. No sirven para estimar cuánto vas a ganar tú en tu proyecto, porque su diseño elimina las dos partes más caras de tu trabajo: definir qué es correcto y verificar que el cambio no rompe nada más.

¿No es contradictorio decir que la IA programa muy bien y a la vez desconfiar del 96%?

Decir que la IA programa muy bien y desconfiar del 96% son dos afirmaciones sobre cosas distintas. La primera habla de capacidad de generar código, que es real y muy alta. La segunda habla de qué mide un número concreto, y ese número resume un tipo de tarea muy particular. La IA genera código excelente a una velocidad que ningún humano iguala; lo que no hace es decidir qué debería hacer ese código ni garantizar que encaja en tu sistema. Ese trabajo es ahora la parte cara.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

La semana del 3 de septiembre de 2026, OpenAI lanzó GPT-6 Astra y su presidente dijo que era la llegada de la AGI. Esa misma semana, dos organizaciones independientes de evaluación publicaron su medición del modelo. Los mismos días, el mismo modelo.

Epoch AI le puso la nota más alta que ha registrado nunca en su índice.

Artificial Analysis le puso exactamente la misma nota que a su antecesor.

No hablo de capturas de X. Son dos organizaciones serias que agregan decenas de benchmarks —Epoch combina más de cincuenta— para medir en buena parte las mismas capacidades. Y llegaron a veredictos opuestos.

Cuarenta y ocho horas después del lanzamiento, una de las dos reescribió su índice.

Aquí es donde el resto de artículos te explica cuál de los dos tiene razón. Este no.

La pregunta "¿es AGI?" no tiene respuesta, y no por motivos filosóficos. Por motivos de instrumentación: el sistema con el que medimos modelos se rompió justo cuando más falta hacía. Y tiene una consecuencia práctica para ti: si los benchmarks públicos no se ponen de acuerdo sobre el modelo más potente del mundo, tú no puedes elegir modelo leyendo leaderboards.

Un apunte de vocabulario, porque de él depende todo lo demás: AGI (Artificial General Intelligence) es un sistema capaz de aprender y resolver cualquier tarea intelectual que resuelva una persona, en dominios que no ha visto antes y sin reentrenarse para cada uno. No existe un test acordado que diga cuándo se cruza esa línea. Por eso la discusión se libra a base de benchmarks, y por eso cuando los benchmarks se contradicen no queda árbitro.

Brockman dijo AGI. Y en el mismo briefing se desdijo

GPT-6 Astra llegó en preview limitada el 3 de septiembre y en disponibilidad general el 4. Entrenado sobre más de 100.000 GPUs en Stargate, Texas: el mayor training run de OpenAI.

Greg Brockman, presidente de OpenAI, cerró el briefing con un "Welcome to the AGI era" y dijo que personalmente cree que han llegado.

En ese mismo briefing admitió que "no hay un momento AGI claramente definido" y que la transición está siendo "más gradual de lo esperado".

Léelo otra vez. Hemos llegado a un sitio que no sabemos definir, por un camino que no hemos notado recorrer.

Eso no es un anuncio técnico. Es posicionamiento.

Qué puntuó GPT-6 Astra en ARC-AGI-3: hay dos números, y solo uno compara

ARC-AGI-3 mide generalización: puzzles interactivos que el modelo no ha visto y debe resolver explorando.

GPT-6 Astra puntuó 99,9 % en ARC-AGI-3. Ese es el número que circuló, y es real. Lo que casi nadie contó es que hay dos números.

Dependen del harness, la capa que conecta el modelo con el entorno (bucle de acciones, formato de observaciones, gestión del contexto).

El adapter propio fue además 3,66 veces más rápido con un 49 % menos de tokens.

Si leíste el rango del ~17–63 % que la propia organización del benchmark da para llamadas stateless, encaja: 62,7 % es el techo de ese rango, el que se alcanza con el harness estándar y el razonamiento al máximo.

No es trampa: optimizar tu arnés es legítimo. Pero no es comparable. Es cronometrar una vuelta con un neumático que solo tiene un equipo.

En el harness estándar, el que sí compara, la foto es esta: GPT-5.6 Sol 7,78 %, Claude Opus 5 30,16 %, Astra 62,7 %.

El salto es brutal. Y es de 30 a 62. No a 99,9.

Hay un detalle mejor que el titular: con el razonamiento al máximo, el coste bajó de 49.791 $ a 26.098 $ mientras la puntuación subía de 35,2 % a 62,7 %. Pensar más salió más barato, y ARC explica por qué: con razonamiento máximo resuelve las partidas con menos acciones, y menos acciones son menos coste total. Esa curva coste/acierto es la que deberías mirar, y el coste por tarea con precios de API lo desgloso en el post hermano.

Astra necesitó menos acciones que la mediana humana en el 96 % de los niveles. Eso es eficiencia de juego, no de coste: los 12,78 $ que cita ARC son lo que cobró un jugador humano por partida intentada, antes de bonus, y los 26.098 $ son el coste total de la evaluación entera del modelo. Unidades distintas. ARC no publica cuántas partidas jugó Astra, así que el coste por partida del modelo no se puede calcular.

Iguala al humano moviendo fichas. Lo que cuesta cada ficha, hoy, nadie lo ha publicado.

Y ahora lo que debería haber sido el titular. ARC Prize dice, textualmente, que "saturating the benchmark would not represent 'proof of achieving AGI'" y que "we are not claiming that it is AGI". Avisan de que ARC-AGI-3 tiene un alcance muy acotado y no representa la apertura del mundo real.

Cuando los autores del benchmark que lleva AGI en el nombre te avisan de que aprobarlo no prueba AGI, el problema no está en el modelo.

Epoch AI vs Artificial Analysis: dos índices, el mismo modelo, veredictos opuestos

Epoch AI y Artificial Analysis agregan decenas de benchmarks para medir en buena parte las mismas capacidades, y publicaron veredictos opuestos sobre GPT-6 Astra en la misma semana: 169 puntos y primer puesto histórico en el índice ECI de Epoch, 61 puntos y empate con GPT-5.6 Sol en el Intelligence Index de Artificial Analysis.

Mismo modelo, misma semana. Uno ve el récord absoluto de su índice; el otro, un empate técnico.

El 5 de septiembre, Artificial Analysis reescribió su índice. Versión 4.2. Añadió dos benchmarks (AA-Briefcase y GDP.pdf), eliminó GPQA-Diamond por saturado —los modelos ya lo resuelven— y subió los datos de test privados al 40 % del peso.

Con las reglas nuevas, Astra saca 4 puntos a Sol y queda segundo. Sigue detrás de Fable 5.1.

El motivo declarado: "the top of the leaderboard moved so fast that an interim update was necessary".

No acuso a nadie de manipular nada: recalibrar tu instrumento cuando deja de discriminar es lo honesto.

Pero mira lo que significa: la regla de medir cambió en 48 horas porque el objeto medido se salía del rango.

Si tu termómetro necesita recalibrarse cada dos días, lo que tienes no es una medición. Es una foto con fecha de caducidad.

Donde GPT-6 Astra no brilla (y casualmente es tu trabajo)

GPT-6 Astra saca 57,7 % en Terminal Bench 4.0, el benchmark que mide tareas reales de línea de comandos.

Un modelo del que se dice que inaugura la era AGI falla más de 4 de cada 10 tareas de ese benchmark de terminal. Tú vives en la terminal.

En GDPval-AA v2, que mide trabajo profesional real, pierde unos 80 puntos Elo. Retrocede también en soporte bancario, SciCode y razonamiento de contexto largo.

OpenAI, por su parte, publicó cifras espectaculares: FrontierMath Tier 4 v2 97,6 %, GPQA Diamond 96,0 %, ARC-AGI-2 95,0 %, ExploitBench 100 %, SRE-Bench 88,0 %, DeepSWE v1.1 74,1 %, OSWorld 2.0 72,6 %.

Son cifras de OpenAI recogidas por the-decoder, no mediciones independientes: probablemente ciertas y seguro que favorables. El mismo juego que conté en la comparativa entre Opus 5, GPT-5.6 y Kimi K3.

El patrón que explica las dos listas: verificación

François Chollet, creador de ARC, no dice que esto sea AGI. Ha adelantado su previsión porque el progreso va más rápido de lo que esperaba: "Sooner, because progress is happening faster than I expected".

Su definición sigue siendo la más útil: la inteligencia no es la habilidad en sí, es la eficiencia con la que un sistema adquiere habilidades nuevas ante entornos desconocidos.

Gary Marcus fue más directo: "Success on ARC-AGI is great and impressive, but not—despite the name of the task—proof of AGI". Su apuesta: fallará en tareas abiertas y solo rendirá bien en dominios verificables. Concede que es "pretty impressive" y llama "extraordinarily vindicating" que OpenAI adopte world models simbólicos, aunque marca su análisis como "VERY tentative".

Junta ahora las dos listas.

Donde Astra arrasa —matemáticas, exploits, puzzles ARC— existe una función de verificación barata y automática. El resultado es correcto o no, y lo decide una máquina en milisegundos.

Donde flojea —GDPval, contexto largo, soporte— no existe esa función. Alguien tiene que leer la salida y opinar.

No es casualidad. Es exactamente lo que predice la tesis de Marcus.

Y es exactamente tu problema cuando un agente escribe código en tu repo.

¿Dónde te funciona bien? En lo que tiene tests. ¿Dónde te la cuela? En lo que solo puedes juzgar leyendo.

Más capaz y más opaco

Astra usa recurrent depth, una técnica que oculta parte de su razonamiento, y es el primer modelo que OpenAI clasifica en umbral "crítico" de ciberseguridad en su preparedness framework. Marcus avisa de que es menos monitorizable que sus predecesores.

Más capaz y más opaco a la vez. Otra razón para no delegar el juicio.

El leaderboard ya no te sirve. Monta tu eval

Si dos organizaciones independientes de evaluación no se ponen de acuerdo sobre el modelo más potente del planeta, y uno reescribe su regla de medir en 48 horas, el leaderboard público ha dejado de ser herramienta de decisión. Es periodismo. Interesante, pero no accionable.

Lo que decide es un eval propio. Y se monta en una tarde:

1. Coge de 20 a 30 casos reales de tu dominio. De tu backlog cerrado, no inventados.
2. Define para cada uno una verificación automática: un test que pasa, un schema que valida, un diff que coincide. Si no puedes verificarlo sin leerlo, no entra en el set.
3. Ejecútalo contra dos o tres modelos candidatos.
4. Mide acierto, coste y latencia. Los tres. Un modelo que acierta un 4 % más y cuesta el triple no es mejor: es más caro.
5. Congela el set y reejecútalo cada vez que cambies de modelo o de versión.

Ese conjunto te dirá lo que ningún índice te dirá nunca: si Astra es mejor para ti. Cómo construirlo paso a paso lo desarrollo en evals deterministas para agentes de IA.

Si lo que te falta no es el eval sino el criterio para revisar lo que genera el agente, empieza por el ebook gratuito Revisión por Contrato: 30 páginas para convertir el "esto parece bien" en algo verificable, la versión aplicada de revisar código de agentes por contrato. El flujo entero, de la idea al producto con agentes, es lo que montamos en Construye con IA, y esas mediciones se discuten a diario en Dominicode Labs.

La pregunta no es si GPT-6 Astra es AGI.

Es si es mejor que lo que ya usas, en tu repo, para tu caso.

Esa la respondes tú, o no la responde nadie.

Preguntas frecuentes

¿GPT-6 Astra es AGI?

No con los datos actuales, y ese es el problema. OpenAI lo insinúa, ARC Prize lo niega explícitamente ("we are not claiming that it is AGI"), Chollet adelanta plazos sin firmar la afirmación y Marcus la rechaza. Sin definición operativa ni test que zanje la discusión, la pregunta no es respondible.

¿Por qué ARC-AGI-3 da 99,9 % y 62,7 % para el mismo modelo?

Porque son dos harness distintos. El 62,7 % sale del arnés estándar de ARC, igual para todos los proveedores. El 99,9 % sale del Provider Adapter, el arnés propio de OpenAI. Los dos son reales; solo uno es comparable con Claude Opus 5 o GPT-5.6 Sol.

¿Debería cambiar mi stack a GPT-6 Astra?

Depende de si tu trabajo se parece más a matemáticas competitivas o a tareas de terminal. Astra marca récords donde hay verificación automática barata, pero saca 57,7 % en Terminal Bench 4.0 y retrocede en contexto largo. En coding, Artificial Analysis lo sitúa detrás de Claude Fable 5.1. Pruébalo con tus casos antes de migrar.

¿Por qué Artificial Analysis reescribió su índice dos días después del lanzamiento?

Porque su scoring dejó de discriminar entre modelos punteros. Añadieron AA-Briefcase y GDP.pdf, retiraron GPQA-Diamond por resuelto y subieron los datos privados al 40 % del peso. Su explicación: "the top of the leaderboard moved so fast that an interim update was necessary". Honesto, y deja claro que un índice público es una foto, no una medida estable.

¿Qué significa que un modelo solo rinda en dominios verificables?

Que brilla donde una función dice sí o no sin intervención humana: un test que pasa, un exploit que funciona. Cuando el criterio es difuso —un informe, una decisión de arquitectura, atender a un cliente— no hay señal de evaluación limpia y el rendimiento cae. Es el motivo por el que tu agente acierta más en el código cubierto por tests.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.