← Tutti gli insight
EVALS · 12 MAG 2026 · 8 MIN · Team di engineering

Perché la sua suite di evals appartiene alla CI.

Se i suoi evals non girano a ogni PR, non sono evals — sono uno screenshot di una riunione di marzo.

C'è uno schema che vediamo in quasi ogni sistema con agenti IA in produzione da più di sei mesi: una cartella evals/ con 40 scenari scritti con entusiasmo nella seconda settimana, e un last_run.json precedente all'ultima modifica al prompt.

Questa non è una suite di evals. È uno screenshot di una riunione di marzo.

Il problema dei due ruoli

Quando una suite di evals vive fuori dalla CI, finisce per servire due ruoli che tirano in direzioni opposte:

  1. Convincere sé stessi che il sistema funziona (eseguire una volta, fare la demo, archiviare)
  2. Intercettare le regressioni prima degli utenti (eseguire a ogni modifica, bloccare le release)

Il primo ruolo premia la completezza — scrivere 200 casi che coprano ogni edge case. Il secondo premia la velocità — girare in meno di cinque minuti o nessuno aspetterà.

Fuori dalla CI, la suite tende a derivare verso il primo ruolo, perché il secondo non ha alcun meccanismo che lo imponga. Il risultato è una suite impressionante in demo e inutile nella pratica.

Cosa significa davvero "in CI"

Tre cose concrete, in ordine di costo:

  1. Un sottoinsieme gira a ogni PR. Selezioni 20–40 casi rapidi e ad alta copertura. Devono terminare in meno di 90 secondi e bloccare il merge in caso di fallimento.
  2. La suite completa gira ogni notte contro il branch main. I fallimenti svegliano qualcuno — non la rotazione on-call, ma il proprietario del prompt.
  3. I delta dei punteggi vengono tracciati nel tempo. Non solo pass/fail. Una regressione del 4% nell'accuratezza delle citazioni che non fa scattare un hard gate è comunque una regressione.

Quella centrale — i fallimenti svegliano un proprietario — è la parte che i team saltano, per poi chiedersi perché il drift si accumula.

Cosa rilasciamo con ogni sistema

Un target pnpm eval (o equivalente) che esegue il sottoinsieme rapido in locale in meno di due minuti. Una GitHub Action che esegue lo stesso su PR. Un job notturno che esegue l'insieme completo contro i prompt di produzione. E una dashboard con due grafici: pass rate per tag, e pass rate nel tempo.

Tutto qui. Niente in questo elenco è nuovo. La novità è che è cablato dal primo giorno e resta cablato dopo che ce ne andiamo.

Perché funziona

Gli ingegneri non scriveranno evals per sistemi che non li impongono. La suite di evals non è un artefatto morale, è un pezzo portante della test pyramid. La metta dove vivono gli altri test.

INIZIA

Manda live il primo sistema.

Discovery a prezzo fisso in 2 settimane. Te ne vai con architettura, spike funzionante e piano di build.