Come il team di Claude Code fa la code review: sette passaggi e nessun circuit breaker

Il 15 ottobre 2026 il team di Claude Code ha pubblicato il proprio resoconto su come revisiona il codice, un articolo di ingegneria di quattordici minuti attribuito ad Addy Osmani, Morgan Westlee Lunt e Qing Wang. La frase che spiega perché qualcuno stia cercando questo arriva presto: Claude scrive circa il 90 percento del codice di Claude Code stesso. Il post non è una difesa di quel numero ma una descrizione del meccanismo che doveva esistere alla base prima che fosse sostenibile, e le parti che vale la pena leggere attentamente sono quelle che mancano ancora.

La maggior parte dei riepiloghi si ferma ai due numeri principali: le pull request unite nel codebase di Claude Code sono più che raddoppiate tra giugno e settembre 2026, mentre la quota che ha dovuto essere annullata è scesa di oltre il 40 per cento. Entrambi provengono dal team stesso, ed entrambi possono essere prodotti da diverse configurazioni, inclusa quella che le persone danno per scontata, ovvero che la revisione sia stata rimossa in silenzio. Il post dice che non è così. Hanno spostato la maggior parte della lettura sulle macchine, ottimizzato per il tempo e l'attenzione umani, e investito nel rendere gli errori rapidi e facili da annullare. Tutto il resto è il dettaglio di come.

Perché fin dall'inizio la revisione è diventata il collo di bottiglia

La pressione non è arrivata da una decisione di policy. È arrivata dal volume. Nel monorepo di Anthropic, secondo quanto riporta il post, le modifiche integrate ogni giorno sono passate da circa 2.500 a maggio a più di 30.000 a settembre 2026. Claude Code vive in un proprio repository, separato da quel monorepo, ma è sottoposto alla stessa pressione su scala minore.

Di questo passo, ammette il post, la revisione manuale riga per riga è incredibilmente difficile, se non impossibile. Nessuno lì sostiene che un umano che legge ogni diff sia superfluo. Sostengono che leggere ogni diff non è più scalabile e che "un umano ha letto il codice" è sempre stato un indicatore impreciso per la domanda che conta: cosa potrebbe andare storto con questa modifica e quale controllo, automatizzato o umano, sia quello giusto per individuarlo.

Detta così, il cancello si sposta. La revisione smette di essere una porta in fondo alla strada e diventa continua, più simile al controllo ortografico mentre scrivi. La maggior parte delle modifiche è già stata letta e corretta da Claude prima che una persona le esamini.

Per cosa hanno ottimizzato e cosa conta come fallimento

L'obiettivo dichiarato è che la maggior parte delle pull request nei repository di Claude Code, che il post descrive come la CLI, le app desktop e web e le app mobile, venga unita con al massimo una persona coinvolta nel processo, che può essere l'autore, senza alcun aumento di revert o incidenti. È la terza clausola a renderlo un obiettivo reale anziché un esercizio di riduzione dei costi.

Misurano il tempo umano su entrambi i lati del bilancio: il tempo che le persone dedicano alla revisione e il tempo che dedicano a correggere ciò che il codice scadente rompe. Ridurre il primo non aiuta se il costo riappare sul secondo, e il team lo dice apertamente. Quindi i numeri monitorati sono le approvazioni umane per pull request, riportate come mediana e 95° percentile, i commenti umani e quanto tempo una pull request attende una persona. I tassi di revert e di incidenti stanno alla base di tutto come guardrail: se aumentano, il tempo umano non è stato risparmiato, solo spostato.

Le metriche sul costo delle revisioni sono facili da manipolare se considerate isolatamente; un revisore che approva tutto produce bellissimi grafici sui tempi di approvazione. È il guardrail a impedire che il grafico menta.

Sette passi, non un solo cancello

Il post presenta il percorso di una modifica tipica in sette passaggi numerati. Ogni livello intercetta alcuni problemi e ne lascia sfuggire altri, e i controlli meno costosi vengono eseguiti prima di quelli più costosi.

• Verifica prima che la pull request esista.Claude esegue i test, la build e il linter, e un secondo agente revisiona il diff in un contesto nuovo. Molti ingegneri utilizzano anche skill interne: una va a caccia di bug, una semplifica il diff, una verifica il comportamento end-to-end. Boris Cherny, creatore di Claude Code, ha definito dare a Claude un modo per verificare il proprio lavoro probabilmente la cosa più importante per ottenere buoni risultati, e stima che renda il risultato finale da due a tre volte migliore.

• Revisione AI su ogni pull request. Una revisione Claude legge il diff rispetto all'intero repository e all'intento dichiarato della pull request. Diversi agenti cercano bug in parallelo, poi un gruppo separato vota su ogni problema individuato e questo viene pubblicato solo se un numero sufficiente concorda che sia reale. Le segnalazioni relative a stile, diagnostica o pulizia vengono scartate. Ciò che sopravvive appare come commenti inline contrassegnati Important, Nit o Pre-existing. Al lancio dell'anteprima di ricerca, la percentuale di pull request interne che ricevevano commenti di revisione sostanziali è passata dal 16 per cento al 54 per cento. Gli amministratori impostano ogni repository su Quick, Standard o Deep.

• Revisione di sicurezza. Un passaggio automatizzato separato. Una pull request non può essere unita finché una segnalazione di una delle due revisioni resta aperta; occorre correggerla o chiudere il thread con una breve motivazione. Lo stesso controllo è disponibile pubblicamente come GitHub Action di revisione di sicurezza open source o come comando /security-review.

• Controlli automatizzati che bloccano. Lint, controlli di tipo, test su ogni piattaforma e una build.

• Approvazione umana, commisurata al rischio. Un classificatore analizza la modifica e stabilisce il livello, anziché lasciarlo decidere all'autore. Questo passaggio ha una sezione dedicata qui sotto, perché è qui che si concentra la maggior parte del design interessante.

• Coda di merge, flag e rilascio graduale. La coda riesegue ogni controllo su main con la modifica applicata, così due pull request che passano singolarmente non possono combinarsi in un main rotto. Il nuovo comportamento viene distribuito dietro un flag prima ai dipendenti Anthropic, poi al canale latest, con stable a seguire.

• Rilevamento e rollback rapidi. Le flag si disattivano senza un deploy, c'è una rotazione settimanale di reperibilità e le revisioni degli incidenti chiedono quale livello avrebbe dovuto intercettare il problema. Alcuni errori passeranno comunque, quindi l'ultimo livello serve a notarli rapidamente anziché a prevenirli.

La modifica imposta il livello, non l'autore

Una correzione alla documentazione e una modifica all'auto-aggiornamento non comportano lo stesso rischio, quindi non ricevono la stessa revisione. La tabella del post ha tre livelli e ciascuno risponde a una sola domanda: quante persone, se ce ne sono, devono approvarlo prima che venga unito.

Basso copre documentazione, testi, funzionalità solo interne e modifiche additive dietro un flag; una volta che la revisione automatizzata e la sicurezza sono verdi, non è richiesta alcuna persona. Medio copre modifiche ordinarie al prodotto più aree sensibili come la cache, l'aggiornamento automatico e i prompt di sistema, e richiede una persona. Alto copre il codice a rischio più elevato e un piccolo insieme di percorsi che richiedono sempre due persone.

Il classificatore è solo metà del progetto. Un secondo classificatore chiede se questa specifica modifica richiede un'altra persona anche quando il suo livello dice di no. Alcuni percorsi richiedono sempre una persona indipendentemente dal livello: qualsiasi cosa i proprietari abbiano elencato come sensibile e qualsiasi file di workflow CI. Solo gli autori presenti nell'elenco di fiducia del repository, per lo più il team proprietario, ottengono i percorsi più leggeri; tutti gli altri richiedono una seconda persona. L'approvazione di un agente non vale mai come quella di una persona, quindi la revisione automatizzata può approvare una modifica a basso rischio ma non può occupare un posto che richiede una persona umana. Chi ha promosso la modifica è responsabile della stessa. E un'approvazione copre uno specifico commit, quindi un nuovo commit, incluso il push di un agente o un merge risolto manualmente, richiede nuovamente l'approvazione.

Due dettagli vale la pena rubare anche se non costruirai mai un classificatore. Il livello deriva dalla modifica, non dall'autore, e la fiducia è un controllo separato e più ristretto che si aggiunge a esso. Inoltre, un'approvazione è vincolata a un commit anziché a una pull request, il che chiude il buco più comune nei sistemi di revisione: una spunta verde guadagnata presto in un ramo e spesa su codice che nessuno ha guardato.

Il revisore viene addestrato contro i propri incidenti

È la parte che la maggior parte degli articoli tralascia, e spiega perché l’accordo continua a funzionare invece di andare alla deriva.

Il team ha raccolto le pull request passate che hanno causato incidenti, insieme ai relativi fix-forward e revert, e ha fatto confermare a ingegneri che conoscono quel codice ogni bug e il punto in cui si trovava. Quella raccolta ora è un eval. Il reviewer la esegue ogni giorno. Quando cambiano i suoi prompt, i suoi strumenti o il modello, la modifica deve superare l'intero set: tienila se il punteggio sale, scartala se no. I loro fallimenti sono diventati la suite di test per la cosa che dovrebbe intercettare i loro fallimenti.

Si tratta di un approccio diverso dall’ottimizzare un linter, che viene valutato rispetto a un insieme fisso di regole. Questo revisore viene valutato rispetto ai modi specifici in cui questo codebase si è già rotto, quindi la valutazione cresce ogni volta che qualcosa va storto. Nessun punteggio per esso compare in nulla che Anthropic abbia pubblicato e che abbiamo letto, e il post non afferma che il revisore sia completo.

Il layer che non è ancora stato costruito

Ecco l'ammissione che rende credibile il post. Tutto quanto sopra descrive un sistema che intercetta e inverte gli errori, non uno che si accorge che il proprio tasso di errore sta cambiando. Il team non dispone ancora di circuit breaker che inaspriscano automaticamente le approvazioni quando cambiano i numeri di revert o di incidenti, e gli ingegneri vorrebbero averli prima che altro codice passi ai merge senza intervento umano.

Quello che esiste, invece, è l'attenzione umana. I flag si disattivano senza un deploy, il turno settimanale di reperibilità vigila e le revisioni degli incidenti chiedono quale livello avrebbe dovuto intercettare il problema. La frase di un collega è la frase più utile per chiunque pianifichi un rollout simile: rallentare riduce il tasso di errore, ma soprattutto perché stai facendo meno di tutto. Il team preferisce diventare più rapido nell'accorgersi dei problemi e nel risolverli, piuttosto che più lento nel produrli.

Rileggi i sette passaggi tenendo presente questo. Sei decidono se una modifica va avanti. Il settimo è un insieme di abitudini per notare in seguito. Non c'è alcun ciclo di retroazione collegato dall'esito al gate, e le persone che hanno costruito il sistema lo dicono.

Il secondo compito di Review, che il post in gran parte tralascia

Il post dice esplicitamente che la code review svolge due compiti: individuare e correggere i problemi prima che vengano rilasciati e costruire un contesto condiviso in tutto il team. Si concentra sul primo, per poi tornare sul secondo con una risposta insolitamente onesta: non esiste un processo formale per farlo, nessuno tiene in testa un modello mentale completo di Claude Code e non ritengono che qualcuno ne abbia bisogno. Vuoi capire una parte della base di codice? Chiedi a Claude una spiegazione esattamente di quella porzione.

Due file di istruzioni racchiudono il contesto che un tempo risiedeva nella testa dei revisori. CLAUDE.md dice a Claude cos'è il progetto, lo stack, le convenzioni, gli obiettivi e i non-obiettivi, tenuto volutamente breve. REVIEW.md è scritto dai code owner e indica come si manifesta un fallimento nella loro parte di codice, quali percorsi saltare, e chiede un file e una riga anziché una supposizione.

La responsabilità ha un posto tutto suo: se lo introduci, te ne assumi la responsabilità. Se unisci una modifica piccola o media e qualcosa va storto, la norma è che la sistemi tu. Funziona perché le modifiche sono piccole, perché i flag e i revert annullano la maggior parte degli errori in pochi minuti e perché il raggio d'impatto stabilisce l'asticella per quanti controlli riceve una modifica. È una norma che si aggiunge alla regola di approvazione, non la sostituisce.

Dove un router è adatto, e dove no

La pipeline sopra è una pipeline di chiamate ai modelli: un agente di revisione che legge un diff rispetto a un intero repository, diversi agenti caccia-bug in parallelo, un gruppo che vota su ogni segnalazione, una passata di sicurezza e il revisore rieseguito ogni giorno su una eval in crescita. È un problema di routing prima ancora che un problema di revisione, perché un provider in una giornata storta non dovrebbe bloccare una coda di merge.

OrcaRouter è un unico endpoint compatibile con OpenAI per oltre 200 modelli con una sola chiave, con failover automatico tra provider e zero ricarichi, ovvero il prezzo di listino del provider applicato così com'è. I team che gestiscono la propria versione di questa pipeline ottengono un unico rapporto di fatturazione e un unico punto in cui cambiare modello quando cambia la qualità per un revisore, che è esattamente ciò che la valutazione giornaliera è progettata per rilevare.

Il confine conta. Ospitiamo modelli. Non ospitiamo Claude Code, non eseguiamo Code Review per Claude Code e non abbiamo accesso alla pipeline di cui tratta questo articolo. Code Review per Claude Code è un prodotto di Anthropic, disponibile generalmente nei piani Team ed Enterprise, con una versione più leggera disponibile in locale come /code-review. Se ciò che vuoi è quella pipeline, è lì che si trova; nella versione del tuo team, un router è una decisione di plumbing più che una decisione di revisione.

Cosa può effettivamente copiare un team più piccolo

Scrivi le regole di revisione dove il revisore può leggerle: un breve CLAUDE.md per il progetto e un REVIEW.md per area che indichi come si presenta un fallimento e pretenda un file e una riga invece di una supposizione. Metti per iscritto i livelli di rischio, rendili una proprietà della modifica anziché dell'autore, inizia in modo rigoroso e allenta solo con le prove. Limita ciò che la revisione automatizzata può approvare e non lasciare mai che l'approvazione di un agente conti come quella di una persona. Vincola le approvazioni ai commit. Esegui la coda di merge. Trasforma incidenti e revert in casi di test e ricalcola il punteggio del revisore ogni volta che lo modifichi, perché un revisore non misurato è un linter con un marketing migliore.

Allora osserva il guardrail, non il tempo di approvazione. La stessa impostazione del team ti offre il criterio per valutare qualsiasi modifica al processo di revisione tu stia considerando: i tassi di revert e di incidenti sono rimasti stabili, oppure il tempo si è semplicemente spostato dal revisore alla persona che ripulisce dopo? A quella domanda si può rispondere con dati che la maggior parte dei team possiede già, e questo distingue un processo diventato più veloce da uno che sembra più veloce solo per un trimestre.