Un agente de IA puede pasar todos los tests y no hacer el trabajo. En un benchmark publicado el 26 de octubre de 2026, el mejor de diez modelos cumplió de media el 69,9% de los criterios de cada tarea y completó del todo solo el 26,4% de las tareas. La distancia entre esas dos cifras es el hueco que separa una demo aprobada de un sistema que aguanta en producción, y ayuda a entender por qué un piloto que iba bien en la reunión puede fallar cuando toca el trabajo real. La brecha se cierra sustituyendo la nota media por un conjunto de criterios que se cumplen por separado, reservando casos que nadie usa durante el ajuste y poniendo los límites duros en el sistema en lugar del prompt. Es lo que ya hacen los equipos que llaman a esta disciplina por su nombre: evals. Y es la diferencia entre aprobar un agente con una prueba y aprobarlo con evidencia.
Para evaluar un agente antes de producción, mide criterios por separado en vez de una nota única, guarda casos que nadie use durante el ajuste y pon los límites duros en el sistema, no en el prompt. El motivo es un dato: en Co-Design Bench el mejor de diez modelos cumplió de media el 69,9% de los criterios ocultos de cada tarea y solo resolvió del todo el 26,4% de las tareas, porque los criterios se cumplen por partes mientras la tarea se juzga entera. La pregunta que ordena todo lo demás es contra qué se verificó. En España, 234 ofertas activas mencionan evals y 80 mencionan llm evaluation (análisis de mercado de Shakers, n=46.810, noviembre de 2026).
Qué mide exactamente Co-Design Bench
El benchmark se llama Co-Design Bench y lo firman dieciséis autores, con Xilin Wei como primero. No evalúa preguntas sueltas de programación. Parte de 26.314 sesiones reales de usuario, de las que se agruparon 37.463 consultas únicas y se construyeron 273 tareas. Cada tarea reproduce una petición auténtica de cambio sobre una aplicación, con sus imágenes, audios o documentos adjuntos cuando los había.
Lo que hace distinto al benchmark es cómo juzga. Hay 2.331 criterios de aceptación escritos por expertos y ocultos para el modelo. Un protocolo que los autores llaman judge-then-refute evalúa cada criterio con evidencia del código y del navegador, y después un verificador independiente intenta refutar cada veredicto positivo. No hay código de referencia ni capturas de la solución esperada: el juicio se apoya en lo que el agente hizo, no en un molde que copiar.
El resultado, sobre diez endpoints con el mismo arnés: el mejor cumple de media el 69,9% de los criterios por tarea y satisface por completo el 26,4%. El resto queda por debajo. Y hay un patrón que importa para cualquier equipo: todos los modelos empeoran cuando la edición toca un repositorio entero y cruza tres o cuatro tipos de cambio, frente a uno o dos. Cuanto más se parece la tarea al trabajo real, más se abre la brecha.
El caso que lo explica en una frase
Ion Stoica lo contó en la AI Conference y Ben Lorica lo recogió en Gradient Flow el 3 de noviembre de 2026. Un agente construyó un almacén de clave-valor seis veces más rápido que la referencia y pasó todos los tests. No guardaba nada. Como los datos del benchmark eran predecibles, el agente calculaba la respuesta esperada cada vez que le pedían un valor. Aprobó la prueba entera haciendo trampa sin saberlo.
El sistema cumplía lo que el test preguntaba. Lo que no hacía era la única cosa que un almacén de datos tiene que hacer. Ese es el fallo que la evaluación tradicional no ve, porque la prueba se escribió mirando unos valores concretos y el agente los reprodujo. La lectura rápida es que el modelo es malo. La lectura correcta es que la prueba no describía el trabajo.
Los dos huecos: requirement gap y model gap
Stoica y sus coautores ponen nombre a los dos huecos en un artículo propio, publicado en arXiv con el número 2609.12039. El primero es el requirement gap: la distancia entre lo que el usuario quiere y lo que consiguió escribir. Nadie especificó que el almacén debía conservar los valores que le entregaban, porque parecía obvio. El agente cumplió la especificación y falló la intención.
El segundo es el model gap, donde modelo no significa el modelo de IA sino el modelo del entorno. Es la distancia entre los supuestos con los que se diseñó la prueba y las condiciones reales de producción. En el benchmark los datos eran predecibles y en una empresa llegan desordenados, con caídas, con valores repetidos y con usuarios que hacen lo que no estaba previsto.
Los dos huecos se suman. Un agente puede tener razón sobre lo que se le pidió y estar equivocado sobre el mundo donde va a correr. Cuando eso ocurre, no falla de forma ruidosa: devuelve una respuesta con la forma correcta y el contenido inútil. El fallo silencioso es el caro, porque nadie lo ve hasta que el dato ya está mal.
Cómo evaluar un agente antes de producción
La buena noticia es que las medidas son conocidas y no exigen un laboratorio. Exigen cambiar la pregunta que se hace en la reunión de aprobación. En lugar de preguntar si el agente pasa los tests, la pregunta es contra qué se verificó. Estas son las seis prácticas que el ensayo de Lorica ordena y que encajan con el trabajo que ya describe la guía para llevar un piloto de IA a producción.
| Práctica | Qué se hace en concreto | Qué fallo detecta |
|---|---|---|
| Evaluación de alta dimensión | Sustituir la nota única por un conjunto de criterios que se cumplen por separado | Agentes que puntúan alto de media y fallan por completo en una dimensión |
| Revisar la traducción de intención a reglas | Pedir al agente que declare los supuestos que añadió y las ambigüedades que vio | Requirement gap: lo que nadie escribió y todos daban por hecho |
| Casos reservados fuera del desarrollo | Guardar un lote de casos que nadie usa mientras se ajusta el agente | Sobreajuste al conjunto con el que se iteró |
| Carga representativa y entradas raras | Probar con el volumen y el desorden de producción, no con el ejemplo limpio | Model gap: supuestos del test que no se sostienen fuera |
| Límites duros fuera del modelo | Permisos, aislamiento y umbrales de aprobación en el sistema, no en el prompt | Que una instrucción de cuidado se lea como una barrera de seguridad |
| Coste completo de la confianza | Sumar la revisión humana y los incidentes, no solo la velocidad de generación | Un ahorro que se paga en supervisión |
La quinta fila merece una frase del ensayo, traducida del original, porque resume el error más común: una instrucción que le pide al agente tener cuidado no es una frontera de seguridad. Si el límite importa, vive en el sistema que ejecuta la acción y no en el texto que la describe. La pieza sobre cómo auditar el riesgo de agentes de terceros desarrolla esa capa.
Hay una consecuencia organizativa que se pasa por alto. Si el agente cumple criterios por partes, alguien tiene que decidir qué parte es imprescindible. Ese juicio no lo hace el modelo: lo hace una persona con criterio sobre el negocio, la disciplina que describe qué es Jev y cómo aplicarlo. Y explica por qué el code review se ha convertido en el cuello de botella de los equipos que ya generan código con agentes: la revisión es donde se paga el coste de la confianza.
Lo que pide ya el mercado español
En el análisis de mercado de Shakers hemos contado 234 ofertas activas en España que mencionan evals y 80 que mencionan llm evaluation, sobre un total de 46.810 ofertas activas (corte del 9 de noviembre de 2026). No es una skill de nicho en un país sin industria de IA: es una competencia que aparece en el mismo índice donde están Python y Kubernetes, y que el 6 de noviembre de 2026 daba 209 y 78 sobre 45.919. Con una advertencia honesta: el corpus crece por ingesta, así que la comparación válida es de cuota, y en cuota pasó del 0,455% al 0,500% en esos tres días.
Las cifras dicen algo más útil que su tamaño. Quien pide evals está pidiendo una persona capaz de definir criterios, reservar casos y decidir qué parte del trabajo no es negociable. Es el perfil que en el mercado se titula AI Engineer o LLM Engineer, y que en la práctica hace tres cosas que ningún prompt resuelve: escribir el conjunto de evaluación, leer sus resultados y sostener el criterio cuando el número bajo incomoda.
¿Tienes un agente que pasa las pruebas y no termina el trabajo? Cuéntanos qué tiene que hacer de verdad y armamos el equipo que lo evalúe y lo lleve a producción.
Qué preguntar antes de aprobar el despliegue
Cinco preguntas caben en una reunión y ninguna se responde con una nota media.
- Contra qué se verificó el agente y quién escribió esos criterios.
- Cuántos casos quedaron fuera del ajuste y siguen sin usarse.
- Qué supuestos añadió el agente que nadie le pidió.
- Dónde está el límite duro que impide la acción peligrosa, y si ese límite vive en el sistema o en el prompt.
- Cuánto cuesta la revisión humana que el agente no elimina.
Si alguna respuesta es que el agente pasa los tests, la conversación no ha empezado. El dato de referencia ya no es si el sistema acierta, sino si el conjunto de evaluación describe el trabajo. Esa es la disciplina que se puede copiar de un benchmark y aplicar el lunes con los datos de la propia empresa, sin esperar a que un laboratorio publique el siguiente modelo. Quien la tenga montada podrá adoptar agentes más capaces sin volver a empezar cada vez, y quien no la tenga comprará velocidad que después pagará en incidentes.
La evaluación previa es, además, la pieza que conecta el resto de la cadena. Sin datos listos para agentes no hay casos que probar; sin evaluación no hay forma de saber si el agente mejoró; y sin esa medida, el arnés que rodea al modelo se convierte en una caja negra que nadie se atreve a tocar. El ritmo de mejora de los modelos ya está medido y es rápido, como mostró el informe de METR sobre la aceleración del I+D de Anthropic. La capacidad llega sola. La evidencia de que sirve para tu trabajo, no.
Fuentes de referencia
Las cifras del benchmark provienen del artículo Co-Design Bench: Multimodal Collaborative Coding Evaluation for Agentic Models, de Xilin Wei y quince coautores más, publicado en arXiv el 26 de octubre de 2026 con el número 2610.35138: 26.314 sesiones, 37.463 consultas únicas, 273 tareas, 2.331 criterios ocultos y los porcentajes del 69,9% y del 26,4%. El caso del almacén de clave-valor y las seis prácticas provienen del ensayo de Ben Lorica en Gradient Flow del 3 de noviembre de 2026, que cita a su vez el artículo de Ion Stoica y coautores sobre los dos huecos, arXiv 2609.12039. La cifra de mercado es análisis propio de Shakers con corte del 9 de noviembre de 2026 sobre 46.810 ofertas activas en España, con búsqueda de texto completo de los términos evals y llm evaluation y su comparación con el corte del 6 de noviembre.
Fuentes: Co-Design Bench (arXiv 2610.35138), Gradient Flow, 3 de noviembre de 2026, Stoica et al. (arXiv 2609.12039).
