La guía de evals para agentes que publicó el equipo de ingeniería de Anthropic en enero de 2026 lo dice sin rodeos: los evals automáticos son especialmente útiles en la integración continua, ejecutándose en cada cambio del agente y en cada actualización de modelo, como primera línea de defensa contra los problemas de calidad. La guía de buenas prácticas de OpenAI dice lo mismo con otras palabras: evaluación continua, evals en cada cambio y un conjunto de casos que crece con el tiempo.
El consejo es correcto. El problema aparece cuando un equipo lo aplica al pie de la letra con todos sus evals a la vez: el pull request tarda lo que tarda el juez más lento, el resultado cambia de una ejecución a otra sin que nadie haya tocado nada y el coste en tokens crece con cada push. Al cabo de unas semanas pasa una de dos cosas: alguien marca el job como opcional, o el equipo deja de mirar el resultado. En los dos casos, los evals siguen existiendo y ya no protegen nada.
La tesis de esta pieza es que no todo eval debe frenar un pull request. En cada PR va la suite de regresión: pequeña, determinista, barata y cerca del 100 % de aciertos. De noche, o antes de cambiar de modelo, van los evals de capacidad: con un modelo como juez, varias pruebas por tarea y un coste que solo tiene sentido pagar una vez al día. Y una regla que no admite excepciones: un cambio de prompt, de skill o de modelo es un cambio de código y pasa por la misma puerta.
Dos preguntas distintas, dos suites distintas
La distinción no es nuestra. La guía de Anthropic separa dos tipos de eval que responden a preguntas diferentes. Los de regresión preguntan si el agente sigue resolviendo todo lo que resolvía, y deberían tener una tasa de aciertos cercana al 100 %. Los de capacidad preguntan qué sabe hacer bien, y deberían empezar con una tasa baja, porque se centran en las tareas que todavía le cuestan.
Esa diferencia decide dónde se ejecuta cada uno. Un eval que debería pasar siempre puede frenar un merge: si falla, algo se ha roto. Un eval diseñado para fallar a menudo no puede frenar nada, porque frenaría casi todos los cambios. Mezclarlos en el mismo job es la forma más rápida de que el equipo aprenda a ignorar el rojo.
| Suite | Qué pregunta | Quién la puntúa | Cuándo se ejecuta | Qué hace en el merge |
|---|---|---|---|---|
| Regresión | ¿Sigue funcionando lo que ya funcionaba? | Código: comparaciones exactas, tests, esquemas, contratos | En cada pull request que toca lo que evalúa | Frena. Debería pasar casi al 100 % |
| Capacidad | ¿Qué sabe hacer bien, y mejora? | Rúbrica, a menudo con un modelo como juez calibrado contra personas | De noche y antes de cambiar de modelo o de versión | Informa. Se revisa la tendencia, no un PR concreto |
| De riesgo | ¿Esto lo puede decidir una máquina? | Una persona con nombre | Cuando el cambio toca dinero, datos personales, permisos o una regla de negocio | Firma. Sin su firma, no entra |
Elaboración propia de onext, a partir de los tipos de eval y de evaluador de la guía de Anthropic (enero de 2026)
La tercera fila no es un eval automático, y precisamente por eso conviene escribirla en la misma tabla. Es la que explicamos en tu spec ya es un eval: los criterios de la especificación dicen qué evaluador corresponde a cada cosa, y algunos no los puede puntuar ninguna máquina.
Lo que va en cada pull request
La suite que frena un merge tiene que ser rápida, barata y fiable, o el equipo dejará de respetarla. La guía de Anthropic enumera las virtudes de los evaluadores basados en código: rápidos, baratos, objetivos, reproducibles y fáciles de depurar. Esa lista es, literalmente, la especificación de una suite de pull request. En la práctica, cuatro decisiones la mantienen así:
- Solo se ejecuta cuando toca. La documentación de integración continua de Promptfoo, una herramienta de evals, muestra un flujo de GitHub Actions que se dispara en los pull requests que cambian los prompts o la configuración de los evals, filtrando por rutas. Un cambio en la hoja de estilos no tiene por qué pagar evals de un agente.
- Lo que no ha cambiado no se vuelve a pagar. El mismo ejemplo guarda en caché los resultados con una clave que depende del contenido de los prompts. Si el prompt es idéntico, la llamada al modelo no se repite.
- El umbral está escrito. Promptfoo ofrece dos formas de romper el build: fallar ante cualquier error del eval o calcular la tasa de aciertos y salir con error si queda por debajo de un objetivo. Para una suite de regresión, el objetivo razonable es el que da Anthropic: casi el 100 %.
- Cada prueba empieza limpia. Anthropic insiste en que cada prueba esté aislada y arranque de un entorno limpio. Un eval que hereda estado de la ejecución anterior falla o pasa por motivos que nadie podrá reproducir.
Si en el pull request se ejecuta también algún eval con un modelo como juez, su resultado se publica como comentario, pero no bloquea. Es la misma regla que proponemos para los criterios con matiz: informan hasta que el juez está calibrado y el umbral acordado. Cómo se construye el conjunto de casos de esa suite lo contamos en el golden set.
Lo que se queda para la noche
Los evals de capacidad son caros por diseño, y no por un defecto que se pueda optimizar. Tres razones, todas de la guía de Anthropic:
- Usan jueces que cuestan. Los evaluadores basados en modelos no son deterministas, son más caros que el código y necesitan calibrarse con evaluadores humanos para ser precisos.
- Necesitan varias pruebas por tarea. Como la salida de un modelo varía entre ejecuciones, se hacen varias pruebas para obtener resultados más consistentes. Cada prueba adicional es otra ejecución completa del agente.
- Miden cosas distintas según cómo se cuente. pass@k mide la probabilidad de acertar al menos una vez en k intentos; pass^k, la de acertar en los k. Cuantas más pruebas, más baja pass^k, porque exigir consistencia es un listón más alto. Si el agente lo va a usar un cliente, lo que importa es la segunda.
Nada de eso cabe en los minutos que un desarrollador está dispuesto a esperar delante de un pull request. Sí cabe en una ejecución nocturna, cuyo resultado se lee por la mañana como una tendencia: qué tareas suben, cuáles bajan y cuáles llevan días estancadas. Y cabe antes de cambiar de modelo, que es exactamente el momento en el que Anthropic pide ejecutar los evals.
La graduación tiene un límite que la misma guía señala: la saturación. Cuando un agente supera todas las tareas resolubles de un eval, ese eval ya no deja margen para medir mejoras. La suite nocturna necesita tareas nuevas, y las mejores salen de los fallos reales. Qué significa «mejor» cuando comparas dos versiones lo desarrollamos en rúbrica y baseline.
Cuánto cuesta: la cuenta que hay que hacer
No vamos a dar una cifra de coste, porque no existe una que valga para todos los equipos y no tenemos una medida propia que podamos publicar. Lo que sí podemos dar es la cuenta. Es aritmética nuestra, no de ninguna fuente:
Coste de una ejecución ≈ número de tareas × pruebas por tarea × (tokens del agente + tokens del juez) × precio por token. Si la ejecución va en cada pull request, se multiplica además por los pull requests del día que tocan lo evaluado.
La fórmula enseña dónde están las palancas. Las pruebas por tarea multiplican todo lo demás, y por eso no van en el pull request. El juez suma una llamada por cada respuesta, y por eso solo va en el PR cuando informa. El filtro por rutas y la caché reducen el último factor, el número de ejecuciones, sin tocar la calidad de la suite.
Para tener números propios en lugar de suposiciones, Anthropic propone seguir la latencia, el uso de tokens, el coste por tarea y la tasa de errores sobre un banco fijo de tareas. Con dos semanas de esos datos, la decisión de qué entra en el pull request deja de ser una opinión. Si tu equipo construye producto con IA, el coste por tarea útil es también una métrica de negocio, como explicamos en cómo medir la IA de un producto SaaS.
Un prompt es código, y pasa por la misma puerta
La regla que más se salta no es técnica. En muchos equipos, cambiar el código del agente pasa por pull request, review y CI, pero cambiar su prompt, una skill o las instrucciones compartidas se hace directamente, porque «solo es texto». Y cambiar la versión del modelo es una línea en un fichero de configuración que nadie revisa.
Los cuatro cambian el comportamiento del agente tanto como el código. La guía de Anthropic pide ejecutar los evals en cada cambio del agente y en cada actualización de modelo; el ejemplo de Promptfoo dispara el flujo justo cuando cambian los prompts. Si las skills y las instrucciones del equipo viven en el repositorio, como defendemos en la guía práctica de skills, el filtro por rutas las cubre sin trabajo adicional. Si viven en un documento compartido fuera del repositorio, no las cubre nada.
Hay un efecto secundario útil: cuando un cambio de prompt tiene que pasar la suite de regresión, el equipo empieza a escribir los prompts con más cuidado, igual que pasó con el código cuando llegaron los tests. El volumen de casos importa más que la perfección de cada uno; la documentación de Anthropic sobre criterios de éxito lo dice así: más casos con una puntuación automática algo menos fina valen más que pocos casos puntuados a mano.
Riesgo Ninguna suite, por bien repartida que esté, lo caza todo. Anthropic usa el modelo del queso suizo de la ingeniería de seguridad: ninguna capa de evaluación detecta todos los problemas. Los evals del CI se combinan con la monitorización en producción y con personas que leen transcripciones; la guía insiste en que, sin leerlas, no se sabe si los evaluadores funcionan.
Por dónde empezar esta semana
Si hoy no tenéis evals en el CI, o los tenéis todos en el mismo job, esta es una secuencia que puede empezar una sola persona del equipo:
- Inventario. Lista los evals que ya existen, aunque sean scripts sueltos, y marca cada uno como regresión o capacidad con la pregunta de Anthropic: ¿debería pasar siempre?
- Suite de regresión. Junta los de regresión que se puntúan con código y añade los fallos reales de las últimas semanas, cada uno convertido en un caso. Sin juez y con una sola prueba por tarea.
- Disparador por rutas. Engánchala al pull request solo cuando cambien el código del agente, sus prompts, sus skills, sus instrucciones o la versión del modelo, con caché por contenido y un umbral escrito.
- Ejecución nocturna. Mueve allí los de capacidad, con varias pruebas por tarea y el juez calibrado, y anota cada mañana la tendencia, no solo el último resultado.
- Dos semanas de medida. Registra latencia, tokens y coste por tarea antes de ampliar nada. Con esos datos decidís qué se gradúa y qué se queda de noche.
Nada de esto exige una herramienta concreta: la misma lógica sirve con Promptfoo, con otra herramienta de evals o con un script propio en cualquier sistema de CI. Lo que cambia el resultado es la separación, no el producto. Y si los tests que acabáis metiendo en la suite los genera el agente, conviene leer antes por qué un test escrito desde el código no lo prueba.
Preguntas frecuentes
¿Hay que ejecutar todos los evals en cada pull request?
No. En cada pull request se ejecuta la suite de regresión: casos pequeños, deterministas y baratos que comprueban que lo que ya funcionaba sigue funcionando, y que deberían pasar casi al 100 %. Los evals de capacidad, con un modelo como juez y varias pruebas por tarea, son más lentos y caros y se ejecutan de noche o antes de cambiar de modelo.
¿Qué diferencia hay entre un eval de regresión y uno de capacidad?
Según la guía de evals de Anthropic, uno de regresión pregunta si el agente sigue resolviendo todo lo que resolvía, y debería tener una tasa de aciertos cercana al 100 %. Uno de capacidad pregunta qué sabe hacer bien, y debería empezar con una tasa baja, porque se centra en lo que todavía le cuesta. Cuando un eval de capacidad se supera con holgura, puede graduarse a regresión.
¿Un eval con un modelo como juez puede frenar un merge?
Solo si el juez está calibrado contra personas y el umbral está acordado. Anthropic recuerda que los evaluadores basados en modelos no son deterministas, son más caros que el código y necesitan calibrarse con evaluadores humanos. Hasta entonces, su resultado informa en el pull request, pero no lo bloquea.
¿Cambiar un prompt o de modelo debe pasar por el CI?
Sí. Un prompt, una skill, las instrucciones compartidas del equipo o la versión del modelo cambian el comportamiento igual que cambia el código. La guía de Anthropic recomienda ejecutar los evals automáticos en cada cambio del agente y en cada actualización de modelo, como primera línea de defensa.
¿Cuánto cuesta ejecutar evals en el CI?
No hay una cifra general: depende del número de tareas, de las pruebas por tarea, de los tokens del agente y del juez y del precio del modelo. Lo que sí se puede hacer es medirlo: Anthropic propone seguir la latencia, el uso de tokens y el coste por tarea sobre un banco fijo de tareas. Con eso, cada equipo sabe qué puede permitirse en cada pull request y qué tiene que esperar a la noche.
¿Cuántos casos necesito para empezar?
Pocos. La guía de Anthropic dice que entre 20 y 50 tareas sencillas sacadas de fallos reales son un gran comienzo. Lo importante es que cada fallo que se escape a producción se convierta en un caso nuevo de la suite.
Fuentes
- Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares y Jiri De Jonghe (Anthropic), «Demystifying evals for AI agents», 9 de enero de 2026.
- OpenAI, «Evaluation best practices».
- Promptfoo, «CI/CD integration».
- Anthropic, documentación de Claude, «Define success criteria and build evaluations».
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →