Loop di verifica in Claude Code: tabella del benchmark, checklist Stop hook e fonti

TL;DR

• La raccomandazione di Anthropic è giusta nella sostanza: il modello che ha un loop di feedback produce lavoro migliore. Il problema è chi esegue il loop. In 116 esecuzioni, il /verify integrato ha restituito PASS 24 volte su 24, anche su una modifica che rompeva un requisito dichiarato.
• Un modello che controlla la propria modifica condivide il proprio punto cieco. Haiku 4.5 ha mancato lo stesso caso di campo univoco in 11 esecuzioni su 11, in tutte le configurazioni con lo stesso modello, e il suo /verify ha messo la spunta accanto al caso sbagliato.
• Su Opus 5.5, /verify è costato 2,5x ($0.96 contro $0.39) e non ha cambiato alcun esito. Opus da solo ha fatto 12 su 12 giusti e ha eseguito la suite di test da sé in 11 di quelle esecuzioni.
• Uno skill di progetto è opzionale per il modello: si è attivato in 10 esecuzioni su 24, 0 su 6 con Haiku. Uno Stop hook si è attivato in ogni esecuzione per circa il 20% in più su Opus.
• Il controllo che ha funzionato veniva da fuori dall'autore: lo stesso /verify eseguito da Opus ha detto FAIL 3 su 3 sulla modifica di Haiku e ha nominato il bug. Collegato come Stop hook, ha fatto correggere il bug a Haiku 3 volte su 3, a $1.36 per task contro $0.76 di Opus che scrive da solo.
• Copia questo: uno Stop hook per la parte deterministica, un verificatore che non sia l'autore per il giudizio, e nessun /verify su Opus per lavoro ben specificato.

Cosa dicono le misure

L'affermazione di Anthropic: "Se Claude ha quel loop di feedback, moltiplicherà per 2-3 la qualità del risultato finale." s4 Il blog la trasforma in un flusso di adozione in 5 passi: scegli il tuo controllo manuale più ripetuto, prova il /verify integrato, scrivi la procedura in linguaggio semplice come skill, rendila deterministica, poi spostala in CI. s1 Dalla v2.1.215, "Claude non esegue più da solo gli skill /verify e /code-review; invocali con /verify o /code-review quando li vuoi." s3

I report dal campo riguardano verifiche dichiarate ma non eseguite. L'issue #96416 è un verdetto di review con 19 dubbi, 5 verificati, e un "accept as-is" emesso comunque. s6 L'issue #97039 è un'affermazione "held up" dopo controlli parziali nonostante una checklist caricata. s7 "La build passa" e "pronto per la produzione" sono soglie diverse, e ogni errore costa 2-3 giri di reprompt. s8

Il nostro benchmark ha valutato ogni "done" con test di accettazione nascosti che l'agente non ha mai visto. 112 esecuzioni di task + 4 esecuzioni /verify tra modelli = 116 esecuzioni, $66.29 di spesa equivalente API. Falsi "done": 12 su 112, 11 di Haiku su T6 in tutte le configurazioni da A a E, 1 di Sonnet su T6 con lo skill, dove i suoi nuovi test fallivano e lo skill non si è mai attivato. s1

Il /verify integrato ha detto Verdict: PASS in 24 esecuzioni su 24 con i tre modelli (23 interpretabili, 1 pass senza etichetta), incluso il T6 rotto di Haiku. Su Opus è costato $0.96 contro $0.39 senza (2,5x) e 125 s contro 75 s; non ha cambiato alcun esito. s3

Lo skill di progetto scritto secondo il flusso in 5 passi è stato invocato in 10 esecuzioni su 24: Opus 8/12, Sonnet 2/6, Haiku 0/6. Lo Stop hook si è attivato in ogni esecuzione, a $0.47 contro $0.39 su Opus (+20%). s19

Il punto cieco è un solo requisito, T6 req. 4: un singolo update che dà lo stesso valore univoco a più documenti corrispondenti deve sollevare DuplicateKeyError. Haiku l'ha mancato in 11 esecuzioni su 11, in ogni configurazione (plain, /verify, skill, hook, test prima). Il /verify di Haiku ha controllato "update di un doc sull'email di un altro" e non ha mai provato un update che colpisce più documenti. La regola test prima non ha aiutato: 3/3 mancano ancora il req. 4, e uno ha rotto anche il req. 3. s1

Stessa modifica di Haiku, /verify eseguito da un altro modello: Sonnet ha detto PASS (1/1), Opus ha detto FAIL 3/3, ogni esecuzione nominando lo stesso caso, un update che scrive lo stesso valore in più documenti, a $0.39 a $0.47 per controllo. Come Stop hook su Haiku (configurazione F), il verificatore Opus ha fatto correggere il bug in 3 esecuzioni su 3; tutte e tre hanno toccato il tetto di 60 turni mentre correggevano, con una media di $1.36 per esecuzione T6 verificatore incluso, contro $0.76 per Opus che scrive T6 da solo con 0 falsi "done". s19

Misure

Banco: Claude Code 2.1.283 headless (claude -p), directory di config isolata, stesso prompt per task, tetto di 60 turni. Repo: msiemens/tinydb @ 18d73a1 (Python, 226 test). Sei richieste di funzionalità da T1 a T6 con 5 requisiti dichiarati ciascuna (T5: 6). Test di accettazione nascosti, uno per requisito dichiarato e mai mostrati all'agente, valutano ogni esecuzione; gira anche la suite del repo. Un falso "done" è un'esecuzione che finisce dichiarando di aver completato mentre un test nascosto o la suite del repo fallisce.

Configurazioni: A plain (solo la richiesta); B /verify (A, poi il /verify integrato come secondo turno); C skill verify (uno skill di progetto invocabile dal modello, scritto secondo il flusso in 5 passi); D Stop hook (prove-it.py: blocca lo stop finché la suite è rossa, e blocca il primo stop chiedendo una riga di prova per requisito); E test prima (una regola di CLAUDE.md: un test che fallisce per requisito prima di qualsiasi codice); F hook verificatore Opus (claude -p /verify --model opus sulla modifica, blocca su un verdetto diverso da PASS, massimo 2 giri).

Limiti: un solo repo (una piccola libreria Python ben testata), sei richieste ben specificate, da 1 a 3 ripetizioni per cella, esecuzioni headless. I test nascosti controllano solo ciò che la richiesta dichiara.

Da fare lunedì

• Scrivi tu un test di accettazione per ogni requisito dichiarato, prima di leggere il "done" del modello. I test nascosti del benchmark hanno preso ciò che ogni controllo dello stesso modello ha mancato.
• Aggiungi uno Stop hook che esegue la tua suite di test e restituisce una decisione block finché è rossa. Si attiva in ogni esecuzione; uno skill no.
• Fai costare al primo stop di un task una riga di prova per requisito (il pattern prove-it.py): un comando e il suo output, non una frase.
• Affida il controllo di giudizio a un modello che non ha scritto la modifica: claude -p /verify --model opus sul diff, bloccando su un verdetto diverso da PASS, con tetto di 2 giri.
• Su Opus 5.5 con una richiesta ben specificata, smetti di digitare /verify per abitudine. È costato 2,5x e non ha cambiato nulla in 12 esecuzioni; riservalo a un'area senza test o alla caccia a un bug preesistente.
• Se deleghi a Haiku 4.5 per risparmiare, metti a budget il verificatore: $1.36 per task con l'hook Opus contro $0.76 per Opus che scrive da solo.
• Registra in un ledger ogni nuovo tentativo di una correzione fallita e ferma il loop dopo una ripetizione, così un hook bloccante non brucia token sulla stessa patch sbagliata.
• Rileggi i tuoi requisiti pensando al caso multi-riga: "un update che corrisponde a più documenti" è la forma del caso che 11 esecuzioni Haiku su 11 non hanno mai provato.

Per andare oltre

• Il flusso in 5 passi e la scala di maturità, dal controllo manuale alla CI: i gradini alti (CI e gate di PR) sono dove va la parte deterministica quando il tuo hook funziona in locale. s1
• Semantica dello Stop hook: una decisione block con un motivo rimanda il turno al modello; leggi il contratto di exit code e JSON prima di scrivere il tuo gate. s19
• Groundtruth, uno Stop hook che rifiuta la fine del turno finché i controlli non passano: la versione deterministica dell'idea, da leggere come implementazione di riferimento. s5
• regressionledger, il lato costo: un hook che impedisce al loop di ritentare la stessa correzione fallita, il pezzo che mancava al nostro Stop hook quando le esecuzioni hanno toccato il tetto di 60 turni. s10

Fonti

• Building verification loops in Claude Code with skills, Anthropic blog. Perché leggerlo: il flusso in 5 passi e la scala su cui è costruito lo skill del benchmark.
• Building verification loops in Claude Code, official Claude channel. Perché leggerlo: tre minuti su cosa fa /verify alla prima esecuzione, prima di decidere se tenerlo.
• Claude Code CHANGELOG, GitHub. Perché leggerlo: la v2.1.215 è dove /verify è diventato invocabile solo dall'utente, il che cambia quanto spesso gira per te.
• Boris Cherny: give Claude a way to verify its work, X. Perché leggerlo: l'affermazione "2-3x la qualità", con le parole esatte.
• Groundtruth, GitHub. Perché leggerlo: un gate Stop hook funzionante da copiare invece di scrivere il tuo da zero.
• Issue #96416, GitHub. Perché leggerlo: una trascrizione datata di un verdetto di review che ha verificato 5 dubbi su 19 e ha accettato comunque.
• Issue #97039, GitHub. Perché leggerlo: lo stesso fallimento due giorni dopo con una checklist caricata, quindi la checklist non è la soluzione.
• AI coding agents can verify some of their work now, dev.to. Perché leggerlo: l'enunciato più chiaro del divario tra "la build passa" e "pronto per la produzione".
• Saguaro, GitHub. Perché leggerlo: il dibattito tra review nel loop e a livello di PR, con il controargomento nei commenti.
• regressionledger, GitHub. Perché leggerlo: il problema del costo dei retry che un hook bloccante crea, e un modo per limitarlo.
• SPICE simulation to oscilloscope to verification with Claude Code, personal blog. Perché leggerlo: un loop di verifica il cui oracolo è uno strumento fisico.
• Hooks reference, code.claude.com. Perché leggerlo: il contratto della decisione block che il tuo Stop hook deve rispettare.

FAQ

Il /verify integrato trova i bug?

Non in questo benchmark. Ha restituito PASS in 24 esecuzioni su 24 con Opus 5.5, Sonnet 5 e Haiku 4.5, inclusa una modifica di Haiku che rompeva un requisito dichiarato. La sua unica scoperta utile è stata un bug upstream preesistente non collegato alla modifica.

Perché un verificatore più forte aiuta un autore più debole?

Il controllo di Haiku ha testato il caso a cui aveva già pensato. Opus, con la stessa modifica e lo stesso /verify, ha provato un update che colpisce più documenti e ha detto FAIL 3 su 3. Sonnet ha detto PASS. Il verificatore deve vedere un caso che l'autore non ha visto.

Costa meno verificare Haiku con Opus, o scrivere con Opus?

Scrivere con Opus. L'hook verificatore Opus su Haiku è costato in media $1.36 per esecuzione T6 e ha toccato il tetto di 60 turni ogni volta; Opus che scrive T6 da solo è costato in media $0.76 con 0 falsi "done".