Un architetto senior non viene pagato per avere l’intuizione giusta, ma per dimostrare che una modifica ha migliorato il sistema e per spiegare, quando qualcosa si rompe, che cosa esattamente si è rotto. Sono due mestieri distinti: il primo è misura comparativa, il secondo è diagnosi differenziale. Confonderli è il modo più rapido per perdere la fiducia di chi finanzia il progetto.

Che cosa un test A/B può decidere, e a quali condizioni

Anthropic colloca il confronto sul traffico reale in un punto preciso del ciclo di vita: «A/B testing validates significant changes once you have sufficient traffic». La frase contiene due condizioni, non una: il cambiamento deve essere significativo e il traffico deve essere sufficiente. Prima di quel punto lo strumento non è l’esperimento sugli utenti ma la suite di eval automatiche, indicata come prima linea di difesa da eseguire in pre-lancio e in CI/CD a ogni modifica dell’agente e a ogni cambio di modello.

Qui va dichiarato un limite invece di riempirlo con nozioni prese altrove: la documentazione Anthropic non pubblica un protocollo statistico per l’A/B test, cioè dimensione del campione, test di significatività, durata dell’esperimento, criteri di arresto. Quelle scelte restano vostre e si difendono con la metodologia sperimentale, non attribuendole al fornitore. Ciò che il fornitore documenta è l’impalcatura di misura attorno all’esperimento, ed è lì che si gioca la credibilità del risultato: un test A/B su una metrica mal definita produce numeri, non decisioni.

L’impalcatura di misura

Il punto di partenza è più modesto di quanto si creda: «In reality, 20-50 simple tasks drawn from real failures is a great start». Casi presi dai guasti veri, non inventati a tavolino. Due indicazioni cambiano poi il modo di leggere il risultato. La prima riguarda l’oggetto della valutazione: «It’s often better to grade what the agent produced, not the path it took», perché un agente che arriva al risultato per una strada diversa dalla vostra non ha sbagliato. La seconda riguarda il non determinismo: pass@k misura la probabilità che almeno un tentativo su k riesca, pass^k che riescano tutti. Un sistema che passa a pass@3 e crolla a pass^3 è un sistema che in produzione fallirà sotto gli occhi degli utenti.

Quando una prova diventa facile va promossa: gli eval con alto tasso di successo «can ‘graduate’ to become a regression suite that is run continuously to catch any drift». È la difesa contro il rischio più costoso, la regressione silenziosa dopo un cambio di prompt o di modello. Se il giudice è un modello, va calibrato su esperti umani; e la suite «is a living artifact that needs ongoing attention and clear ownership to remain useful»: senza un proprietario nominato invecchia e si satura.

Tre guasti che si somigliano

Prompt failure. Il primo posto dove guardare è stop_reason. max_tokens significa risposta troncata, non risposta sbagliata; model_context_window_exceeded va trattato allo stesso modo; refusal arriva come normale risposta HTTP 200 e non come errore, quindi un client che controlla solo lo status code lo archivia come successo. Sui guasti degli strumenti le cause tipiche sono tabulate: se Claude chiama lo strumento sbagliato la causa probabile è l’ambiguità delle descrizioni, e il rimedio è distinguerle per QUANDO usare uno strumento, non solo per che cosa fa; se inventa parametri, le leve sono strict: true e gli input_examples. Un caso che sembra un difetto del modello e non lo è: se avete messo le vostre istruzioni dentro un blocco tool_result, Claude le tratta come contenuto di terze parti potenzialmente ostile e può rifiutarsi di agire.

Allucinazioni. Le tecniche documentate sono in scala: permettere esplicitamente di dire «I don’t know», far estrarre citazioni testuali prima dell’analisi, chiedere che ogni affermazione sia sostenuta da una citazione e ritirata se la citazione non esiste, vietare la conoscenza esterna ai documenti forniti, confrontare più esecuzioni della stessa richiesta. La pagina chiude però con un avvertimento da riportare agli stakeholder: queste tecniche riducono le allucinazioni «significantly» ma non le eliminano, e le informazioni critiche vanno comunque validate.

Model mismatch. Non è quasi mai «modello troppo piccolo». Il caso misurato più istruttivo è l’opposto: prompt scritti per Claude Opus 4.8 sono costati «36% more per ticket on Claude Opus 5 for no change in accuracy». Fuori posto era il prompt, non il modello. Vale lo stesso per i parametri: se avete portato le impostazioni di effort da un modello precedente, la raccomandazione è rifare lo sweep sulle vostre eval invece di riusarle. E prima di cambiare modello vale la pena ricordare che regolare l’effort è spesso una leva migliore del cambio.

Che cosa si porta in riunione

Tre numeri, non uno: tasso di successo sulla suite, dispersione fra tentativi ripetuti, costo per compito completato. Più la data dell’ultima calibrazione del giudice e il nome di chi possiede la suite. È l’unica forma in cui la frase «abbiamo migliorato il sistema» smette di essere un’opinione e diventa un’affermazione che qualcuno può verificare.