Il codice raddoppia, gli annullamenti diminuiscono: come Anthropic ha smesso di leggere tutto

Il 15 ottobre 2026 il team che sviluppa Claude Code, l’assistente di programmazione di Anthropic, ha pubblicato un resoconto di come revisiona il proprio codice. Il punto di partenza è insolito: Claude scrive circa il 90% del codice di Claude Code. Fra giugno e settembre il numero di modifiche integrate nel software è più che raddoppiato, e la quota da annullare è scesa di oltre il 40%. La produzione è aumentata mentre il tasso di errore diminuiva, perché il team ha smesso di chiedere «una persona ha letto tutto?» e si è chiesto quale controllo, automatico o umano, debba intercettare ciascun errore.

Il doppio delle modifiche, quota annullata in calo del 40%

Un team software non modifica direttamente il prodotto. Ogni modifica passa per una pull request, una proposta che attende di essere revisionata e poi integrata nel codice principale. Quando una modifica integrata rompe qualcosa e viene rimossa, si parla di revert. Questi sono i due contatori di Anthropic.

Il calo riguarda la quota di modifiche annullate, non il loro numero. Prendendo le soglie annunciate così come sono, volume per due e quota per 0.6, il numero di annullamenti sarebbe cresciuto di circa il 20% su un volume raddoppiato. Il calcolo è nostro; Anthropic non pubblica la cifra. Il risultato è questo: il volume è raddoppiato senza che gli annullamenti ne seguissero il ritmo.

Nessuno può più leggere tutto: 30’000 modifiche al giorno

Anthropic conserva la maggior parte del codice in un unico grande repository. A maggio vi venivano integrate circa 2’500 modifiche al giorno. A settembre, oltre 30’000.

A quel ritmo nessuna persona legge ogni riga. Il team ne ha tratto la conseguenza: «una persona ha letto il codice?» è, a suo avviso, un indicatore indiretto impreciso. La domanda giusta è cosa potrebbe andare storto e quale controllo dovrebbe intercettarlo. La risorsa scarsa non è più il codice, ma l’attenzione umana. L’obiettivo diventa integrare la maggior parte delle modifiche con al massimo una persona nel processo, che può essere l’autore.

La salvaguardia si riassume in una frase: se annullamenti o incidenti aumentano, il tempo umano non è stato risparmiato, ma soltanto spostato dalla revisione alla riparazione. L’efficienza si misura quindi alla fine del processo. Il team segue le approvazioni umane per modifica, il tempo trascorso aspettando una persona e, come freno, annullamenti e incidenti.

Sette livelli di controllo, ognuno intercetta ciò che sfugge agli altri

1. Lavoro verificato prima di essere proposto. A Claude viene dato un modo per eseguire ciò che scrive, test, compilazione, schermata da confrontare con il progetto, e deve mostrare il risultato anziché annunciare di aver finito. Boris Cherny, creatore di Claude Code, stima che questo migliori il risultato finale di due-tre volte. Un secondo agente, partendo da zero, revisiona la modifica.
2. Una revisione da parte di agenti su ogni modifica. Diversi agenti cercano bug in parallelo, un altro gruppo vota su ogni rilievo e vengono pubblicati soltanto quelli su cui si raggiunge un accordo. Ognuno va corretto oppure chiuso con una motivazione.
3. Una revisione di sicurezza bloccante. Finché un rilievo resta aperto, la modifica non viene integrata.
4. Controlli automatici obbligatori. Stile del codice, tipi, test sulle varie piattaforme, compilazione. Il modulo di ogni modifica chiede come sia stata testata e come annullarla.
5. Approvazione umana proporzionata al rischio, descritta sotto.
6. Una coda di integrazione, poi un rilascio graduale. La coda riesegue ogni controllo sul codice più recente. La nuova funzionalità raggiunge prima i dipendenti di Anthropic, dietro un interruttore che la attiva o disattiva.
7. Rilevamento rapido e ripristino. L’interruttore disattiva una funzionalità senza un nuovo rilascio. Ogni settimana il team di reperibilità si chiede quale livello avrebbe dovuto intercettare ciascun incidente.

Rischio	Esempi	Approvazioni umane
Basso	Documentazione, testi, funzioni interne, aggiunte dietro un interruttore	Nessuna, una volta superati i controlli automatici e di sicurezza
Medio	Normali modifiche al prodotto, aree sensibili (cache, aggiornamento automatico, istruzioni del modello)	Una persona
Alto	Il codice più rischioso	Due persone

Un classificatore stabilisce il livello in base alla modifica stessa, non al suo autore. Alcuni file, come quelli che governano i controlli automatici, richiedono sempre una persona.

Due regole da copiare per prime

La prima: l’approvazione di un agente non conta mai come quella di una persona. Una revisione automatica può autorizzare una modifica a basso rischio; non occupa un posto che richiede un essere umano. La seconda: chi ha richiesto la modifica ne risponde, come se avesse scritto personalmente il codice. Su una modifica scritta da un agente, la persona che lo dirige conta come uno dei revisori richiesti. Un’approvazione copre inoltre una versione specifica: un’aggiunta che non ha visto richiede una nuova approvazione.

Anche il revisore viene revisionato

Il revisore automatico migliora attraverso un ciclo continuo. Ogni incidente passato diventa un caso di test, confermato da un esperto, e ogni giorno il revisore viene valutato su tutti i casi. È emerso un nuovo problema: un agente che scrive e uno che revisiona possono tenersi occupati all’infinito. Il revisore segnala un errore, l’agente lo corregge, il revisore ne trova un altro. Una modifica ha attraversato oltre 50 cicli durante la notte prima che una persona la fermasse manualmente. Ora, dopo tre cicli, il revisore chiede all’autore di fare un passo indietro e ripensare l’approccio.

Misura (Anthropic)	Prima	Dopo
Modifiche che ricevono commenti sostanziali	16%	54%
Modifiche approvate in un solo ciclo di revisione	65%	78%
Modifiche che richiedono cinque cicli o più	8.9%	1.5%
Numero medio di revisioni prima dell’approvazione	2.08	1.32

Le persone non sono scomparse. Decidono se costruire una funzionalità, revisionano il codice rischioso, fatturazione, aggiornamento automatico e file di controllo, valutano scelte architetturali che altri copieranno, leggono le prove, risultati dei test, schermate e rilievi dei revisori, e rispondono degli esiti.

Non è un’idea nuova: le macchine controllano le macchine da molto tempo

Nessuno controlla manualmente ogni pacchetto che attraversa Internet. Il protocollo TCP associa una somma di controllo a ciascun pacchetto e richiede di nuovo quelli che arrivano danneggiati o non arrivano. La memoria di un server corregge da sola un bit alterato mediante codici di correzione degli errori. Un database scrive ogni modifica in un registro che un server di riserva riproduce, mentre altri processi lo sorvegliano. La contabilità in partita doppia, che ha più di cinque secoli, registra ogni operazione due volte, in dare e in avere, affinché i conti debbano quadrare. Nel 1948 Claude Shannon dimostrò che un messaggio può essere trasmesso in modo affidabile su un canale rumoroso, purché si aggiunga la ridondanza adeguata.

Questi sistemi non sono mai diventati affidabili facendo ispezionare ogni passaggio a una persona. Sono diventati affidabili facendo controllare le macchine da altre macchine, con controlli progettati da persone. Il codice scritto dagli agenti si inserisce in questa tradizione.

Il collo di bottiglia si è spostato

Scrivere più rapidamente sposta il collo di bottiglia sulla lettura. Nel 2025 Faros AI ha analizzato i dati di oltre 10’000 sviluppatori in 1’255 team. Quelli che usavano intensamente l’IA integravano il 98% di pull request in più, ma il tempo di revisione aumentava del 91%, i bug per sviluppatore del 9% e la dimensione media delle modifiche del 154%. Lo studio non rileva miglioramenti significativi a livello aziendale, né nel ritmo di consegna né nella qualità. Faros vende strumenti di misurazione e misura l’attività, non il valore consegnato: sono correlazioni. Descrivono comunque il muro contro cui urtano i team quando accelerano senza ripensare la revisione.

Il metodo Anthropic presuppone una base. Il team può alleggerire la revisione umana perché quasi tutto è reversibile: test eseguibili da un agente, interruttori, rilascio graduale, ripristino in pochi minuti. Senza, revisionare meno non è un’opzione. Riconosce anche una lacuna: non esiste ancora un meccanismo che inasprisca le approvazioni quando aumentano annullamenti o incidenti, e gli ingegneri ne vogliono uno prima che altro codice venga integrato senza revisore umano.

Cosa ne ricaviamo per un’organizzazione

• Misurare l’attesa, non le righe. Il volume di codice prodotto non dice nulla sull’efficienza. Lo dicono il tempo in cui una modifica attende una persona, le approvazioni per modifica e il tasso di annullamento.
• Costruire la base prima di aprire il rubinetto. Test eseguibili da un agente, interruttori, rilascio graduale, ripristino rapido. Iniziare con rigore, allentare quando le prove lo consentono.
• Trasformare ogni revisione ripetuta in una regola, un test o uno strumento. E ogni giorno mettere alla prova il revisore automatico sul peggior incidente vissuto dall’organizzazione: nessun altro possiede quel caso di test.
• Mantenere una persona responsabile. In un istituto regolamentato la domanda utile è chi approva ogni modifica e chi ne risponde. È il principio dei quattro occhi, applicato a un revisore che non dorme mai.

Tutti possono acquistare l’accesso agli stessi modelli. A distinguere le organizzazioni è ricostruire il processo intorno ad essi e mantenere le persone dove giudizio, fiducia e responsabilità non possono essere delegati.