La guia d'evals per a agents que va publicar l'equip d'enginyeria d'Anthropic el gener de 2026 ho diu sense embuts: els evals automàtics són especialment útils a la integració contínua, executant-se a cada canvi de l'agent i a cada actualització de model, com a primera línia de defensa contra els problemes de qualitat. La guia de bones pràctiques d'OpenAI diu el mateix amb altres paraules: avaluació contínua, evals a cada canvi i un conjunt de casos que creix amb el temps.
El consell és correcte. El problema apareix quan un equip l'aplica al peu de la lletra amb tots els seus evals alhora: el pull request triga el que triga el jutge més lent, el resultat canvia d'una execució a l'altra sense que ningú hagi tocat res i el cost en tokens creix amb cada push. Al cap d'unes setmanes passa una de dues coses: algú marca el job com a opcional, o l'equip deixa de mirar el resultat. En tots dos casos, els evals continuen existint i ja no protegeixen res.
La tesi d'aquesta peça és que no tot eval ha de frenar un pull request. A cada PR hi va la suite de regressió: petita, determinista, barata i a prop del 100 % d'encerts. De nit, o abans de canviar de model, hi van els evals de capacitat: amb un model com a jutge, diverses proves per tasca i un cost que només té sentit pagar un cop al dia. I una regla que no admet excepcions: un canvi de prompt, de skill o de model és un canvi de codi i passa per la mateixa porta.
Dues preguntes diferents, dues suites diferents
La distinció no és nostra. La guia d'Anthropic separa dos tipus d'eval que responen preguntes diferents. Els de regressió pregunten si l'agent continua resolent tot el que resolia, i haurien de tenir una taxa d'encerts propera al 100 %. Els de capacitat pregunten què sap fer bé, i haurien de començar amb una taxa baixa, perquè se centren en les tasques que encara li costen.
Aquesta diferència decideix on s'executa cadascun. Un eval que hauria de passar sempre pot frenar un merge: si falla, alguna cosa s'ha trencat. Un eval dissenyat per fallar sovint no pot frenar res, perquè frenaria gairebé tots els canvis. Barrejar-los al mateix job és la manera més ràpida que l'equip aprengui a ignorar el vermell.
| Suite | Què pregunta | Qui la puntua | Quan s'executa | Què fa al merge |
|---|---|---|---|---|
| Regressió | Continua funcionant el que ja funcionava? | Codi: comparacions exactes, tests, esquemes, contractes | A cada pull request que toca el que avalua | Frena. Hauria de passar gairebé al 100 % |
| Capacitat | Què sap fer bé, i millora? | Rúbrica, sovint amb un model com a jutge calibrat amb persones | De nit i abans de canviar de model o de versió | Informa. Es revisa la tendència, no un PR concret |
| De risc | Això ho pot decidir una màquina? | Una persona amb nom | Quan el canvi toca diners, dades personals, permisos o una regla de negoci | Signa. Sense la seva signatura, no entra |
Elaboració pròpia d'onext, a partir dels tipus d'eval i d'avaluador de la guia d'Anthropic (gener de 2026)
La tercera fila no és un eval automàtic, i precisament per això convé escriure-la a la mateixa taula. És la que expliquem a la teva spec ja és un eval: els criteris de l'especificació diuen quin avaluador correspon a cada cosa, i alguns no els pot puntuar cap màquina.
El que va a cada pull request
La suite que frena un merge ha de ser ràpida, barata i fiable, o l'equip la deixarà de respectar. La guia d'Anthropic enumera les virtuts dels avaluadors basats en codi: ràpids, barats, objectius, reproduïbles i fàcils de depurar. Aquesta llista és, literalment, l'especificació d'una suite de pull request. A la pràctica, quatre decisions la mantenen així:
- Només s'executa quan toca. La documentació d'integració contínua de Promptfoo, una eina d'evals, mostra un flux de GitHub Actions que es dispara als pull requests que canvien els prompts o la configuració dels evals, filtrant per rutes. Un canvi al full d'estils no té per què pagar evals d'un agent.
- El que no ha canviat no es torna a pagar. El mateix exemple desa a la memòria cau els resultats amb una clau que depèn del contingut dels prompts. Si el prompt és idèntic, la crida al model no es repeteix.
- El llindar està escrit. Promptfoo ofereix dues maneres de trencar el build: fallar davant de qualsevol error de l'eval o calcular la taxa d'encerts i sortir amb error si queda per sota d'un objectiu. Per a una suite de regressió, l'objectiu raonable és el que dona Anthropic: gairebé el 100 %.
- Cada prova comença neta. Anthropic insisteix que cada prova estigui aïllada i arrenqui d'un entorn net. Un eval que hereta estat de l'execució anterior falla o passa per motius que ningú no podrà reproduir.
Si al pull request també s'executa algun eval amb un model com a jutge, el seu resultat es publica com a comentari, però no bloqueja. És la mateixa regla que proposem per als criteris amb matís: informen fins que el jutge està calibrat i el llindar acordat. Com es construeix el conjunt de casos d'aquesta suite ho expliquem a el golden set.
El que es queda per a la nit
Els evals de capacitat són cars per disseny, i no per un defecte que es pugui optimitzar. Tres raons, totes de la guia d'Anthropic:
- Fan servir jutges que costen. Els avaluadors basats en models no són deterministes, són més cars que el codi i cal calibrar-los amb avaluadors humans perquè siguin precisos.
- Necessiten diverses proves per tasca. Com que la sortida d'un model varia entre execucions, es fan diverses proves per obtenir resultats més consistents. Cada prova addicional és una altra execució completa de l'agent.
- Mesuren coses diferents segons com es compti. pass@k mesura la probabilitat d'encertar almenys una vegada en k intents; pass^k, la d'encertar en els k. Com més proves, més baixa pass^k, perquè exigir consistència és un llistó més alt. Si l'agent l'ha de fer servir un client, el que importa és la segona.
Res d'això cap en els minuts que un desenvolupador està disposat a esperar davant d'un pull request. Sí que hi cap en una execució nocturna, el resultat de la qual es llegeix al matí com una tendència: quines tasques pugen, quines baixen i quines porten dies encallades. I hi cap abans de canviar de model, que és exactament el moment en què Anthropic demana executar els evals.
La graduació té un límit que la mateixa guia assenyala: la saturació. Quan un agent supera totes les tasques resolubles d'un eval, aquest eval ja no deixa marge per mesurar millores. La suite nocturna necessita tasques noves, i les millors surten de les errades reals. Què vol dir «millor» quan compares dues versions ho desenvolupem a rúbrica i baseline.
Quant costa: el compte que cal fer
No donarem una xifra de cost, perquè no n'hi ha cap que valgui per a tots els equips i no tenim una mesura pròpia que puguem publicar. El que sí que podem donar és el compte. És aritmètica nostra, no de cap font:
Cost d'una execució ≈ nombre de tasques × proves per tasca × (tokens de l'agent + tokens del jutge) × preu per token. Si l'execució va a cada pull request, es multiplica a més pels pull requests del dia que toquen el que s'avalua.
La fórmula ensenya on són les palanques. Les proves per tasca multipliquen tota la resta, i per això no van al pull request. El jutge suma una crida per cada resposta, i per això només va al PR quan informa. El filtre per rutes i la memòria cau redueixen l'últim factor, el nombre d'execucions, sense tocar la qualitat de la suite.
Per tenir números propis en lloc de suposicions, Anthropic proposa seguir la latència, l'ús de tokens, el cost per tasca i la taxa d'errors sobre un banc fix de tasques. Amb dues setmanes d'aquestes dades, la decisió de què entra al pull request deixa de ser una opinió. Si el teu equip construeix producte amb IA, el cost per tasca útil també és una mètrica de negoci, com expliquem a com mesurar la IA d'un producte SaaS.
Un prompt és codi, i passa per la mateixa porta
La regla que més se salta no és tècnica. En molts equips, canviar el codi de l'agent passa per pull request, revisió i CI, però canviar-ne el prompt, una skill o les instruccions compartides es fa directament, perquè «només és text». I canviar la versió del model és una línia en un fitxer de configuració que ningú no revisa.
Totes quatre coses canvien el comportament de l'agent tant com el codi. La guia d'Anthropic demana executar els evals a cada canvi de l'agent i a cada actualització de model; l'exemple de Promptfoo dispara el flux just quan canvien els prompts. Si les skills i les instruccions de l'equip viuen al repositori, com defensem a la guia pràctica de skills, el filtre per rutes les cobreix sense feina addicional. Si viuen en un document compartit fora del repositori, no les cobreix res.
Hi ha un efecte secundari útil: quan un canvi de prompt ha de passar la suite de regressió, l'equip comença a escriure els prompts amb més cura, igual que va passar amb el codi quan van arribar els tests. El volum de casos importa més que la perfecció de cadascun; la documentació d'Anthropic sobre criteris d'èxit ho diu així: més casos amb una puntuació automàtica una mica menys fina valen més que pocs casos puntuats a mà.
Risc Cap suite, per ben repartida que estigui, ho caça tot. Anthropic fa servir el model del formatge suís de l'enginyeria de seguretat: cap capa d'avaluació detecta tots els problemes. Els evals de la CI es combinen amb la monitorització en producció i amb persones que llegeixen transcripcions; la guia insisteix que, sense llegir-les, no se sap si els avaluadors funcionen.
Per on començar aquesta setmana
Si avui no teniu evals a la CI, o els teniu tots al mateix job, aquesta és una seqüència que pot començar una sola persona de l'equip:
- Inventari. Llista els evals que ja existeixen, encara que siguin scripts solts, i marca cadascun com a regressió o capacitat amb la pregunta d'Anthropic: hauria de passar sempre?
- Suite de regressió. Ajunta els de regressió que es puntuen amb codi i afegeix-hi les errades reals de les últimes setmanes, cadascuna convertida en un cas. Sense jutge i amb una sola prova per tasca.
- Disparador per rutes. Enganxa-la al pull request només quan canviïn el codi de l'agent, els seus prompts, les seves skills, les seves instruccions o la versió del model, amb memòria cau per contingut i un llindar escrit.
- Execució nocturna. Mou-hi els de capacitat, amb diverses proves per tasca i el jutge calibrat, i anota cada matí la tendència, no només l'últim resultat.
- Dues setmanes de mesura. Registra latència, tokens i cost per tasca abans d'ampliar res. Amb aquestes dades decidiu què es gradua i què es queda de nit.
Res d'això exigeix una eina concreta: la mateixa lògica serveix amb Promptfoo, amb una altra eina d'evals o amb un script propi en qualsevol sistema de CI. El que canvia el resultat és la separació, no el producte. I si els tests que acabeu posant a la suite els genera l'agent, convé llegir abans per què un test escrit a partir del codi no el prova.
Preguntes freqüents
Cal executar tots els evals a cada pull request?
No. A cada pull request s'executa la suite de regressió: casos petits, deterministes i barats que comproven que el que ja funcionava continua funcionant, i que haurien de passar gairebé al 100 %. Els evals de capacitat, amb un model com a jutge i diverses proves per tasca, són més lents i cars i s'executen de nit o abans de canviar de model.
Quina diferència hi ha entre un eval de regressió i un de capacitat?
Segons la guia d'evals d'Anthropic, un de regressió pregunta si l'agent continua resolent tot el que resolia, i hauria de tenir una taxa d'encerts propera al 100 %. Un de capacitat pregunta què sap fer bé, i hauria de començar amb una taxa baixa, perquè se centra en el que encara li costa. Quan un eval de capacitat se supera amb escreix, pot graduar-se a regressió.
Un eval amb un model com a jutge pot frenar un merge?
Només si el jutge està calibrat amb persones i el llindar està acordat. Anthropic recorda que els avaluadors basats en models no són deterministes, són més cars que el codi i cal calibrar-los amb avaluadors humans. Fins aleshores, el seu resultat informa al pull request, però no el bloqueja.
Canviar un prompt o de model ha de passar per la CI?
Sí. Un prompt, una skill, les instruccions compartides de l'equip o la versió del model canvien el comportament igual que el canvia el codi. La guia d'Anthropic recomana executar els evals automàtics a cada canvi de l'agent i a cada actualització de model, com a primera línia de defensa.
Quant costa executar evals a la CI?
No hi ha una xifra general: depèn del nombre de tasques, de les proves per tasca, dels tokens de l'agent i del jutge i del preu del model. El que sí que es pot fer és mesurar-ho: Anthropic proposa seguir la latència, l'ús de tokens i el cost per tasca sobre un banc fix de tasques. Amb això, cada equip sap què es pot permetre a cada pull request i què ha d'esperar a la nit.
Quants casos necessito per començar?
Pocs. La guia d'Anthropic diu que entre 20 i 50 tasques senzilles tretes d'errades reals són un gran començament. L'important és que cada errada que s'escapi a producció es converteixi en un cas nou de la suite.
Fonts
- Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares i Jiri De Jonghe (Anthropic), «Demystifying evals for AI agents», 9 de gener de 2026.
- OpenAI, «Evaluation best practices».
- Promptfoo, «CI/CD integration».
- Anthropic, documentació de Claude, «Define success criteria and build evaluations».
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →