Lance Martin, di Anthropic, pubblica sul blog claude.dev una guida sulla progettazione delle valutazioni e sul miglioramento di un'applicazione o di uno skill rispetto a queste senza illudersi. Annuncia l'aggiunta di due sottocomandi allo skill claude-api di Claude Code: /claude-api build-eval costruisce una valutazione nel repository, /claude-api hillclimb migliora l'applicazione rispetto a essa, una modifica alla volta, con un insieme di esempi tenuto da parte per rilevare l'overfitting.
La prima parte enuncia quattro proprietà di una buona valutazione. I compiti rispecchiano la produzione. I punteggi aumentano con un modello più capace e un impegno maggiore; in caso contrario, la causa sono compiti ambigui o un valutatore mal calibrato. Il miglior modello resta chiaramente sotto il 100%, senza che lo scarto sia dovuto a compiti impossibili: un compito che fallisce in ogni esecuzione è sospetto, e un buon compito è quello su cui due esperti raggiungono lo stesso verdetto. Infine, la varianza è bassa, il che richiede un valutatore stabile, un impegno applicato in modo costante e un ambiente privo di stato residuo. L'autore aggiunge un'avvertenza sull'adversarial sampling: scegliere i casi che il modello attuale fallisce misura la sua impronta di fallimento piuttosto che la difficoltà reale. Raccomanda casi giudicati difficili da un umano, fallimenti reali tratti da ticket o bug, pur notando che il traffico grezzo può propendere verso il facile.
build-eval interroga l'utente, poi costruisce la valutazione con pause di approvazione. Gli input provengono, in ordine, da trascrizioni di produzione, ticket, cinque-dieci casi scritti a mano, poi casi sintetizzati. Il valutatore è il più economico che si adatti: programmatico quando gli output sono vincolati, altrimenti un modello giudice con una checklist di affermazioni verificabili. Claude valuta alcuni casi e chiede se l'utente avrebbe giudicato diversamente, poi esegue la baseline con un intervallo di confidenza e tre verifiche: stabilità del valutatore, funzionamento tecnico, margine di miglioramento.
La seconda parte riguarda l'hillclimbing. È adatto a superfici economiche da modificare, il cui punteggio è attribuibile, con un obiettivo limitato; il costo è un buon obiettivo. Contro l'overfitting, tre salvaguardie: separare train e test, non incollare mai i fallimenti nel prompt, mantenere le risposte fuori portata. Il comando divide la valutazione, verifica che il rumore sia inferiore al guadagno ricercato, propone una patch per round e la annulla se il train aumenta da solo. In caso di stagnazione, classifica i fallimenti per causa prima di modificare.
Due esempi illustrano tutto ciò. Su un benchmark di assistenza di 44 ticket, il passaggio da Opus 4.8 a Opus 5.5 e poi a Sonnet 5 a basso impegno, con un prompt migliorato, produce 90,5% contro 78,6% sui ticket tenuti da parte, per circa un quinto del costo. Sullo skill claude-api, la valutazione passa dal 66% a circa l'88%: sezioni mancanti, tabelle di tipi, una tabella delle forme API deprecate, e correzioni a compiti e valutatori difettosi.