La revisione di Anthropic Claude Code sostituisce la lettura umana di routine mentre l'AI scrive il 90% del codice

La revisione di Anthropic Claude Code è entrata in un territorio inesplorato perché, secondo l'azienda, Claude scrive ora circa il 90% del codice del prodotto. Da giugno a settembre 2026, le pull request unite sono più che raddoppiate. Eppure, la quota che ha richiesto un revert sarebbe diminuita di oltre il 40%.

È questa combinazione a raccontare la vera storia. Anthropic non ha risposto all'esplosione di codice scritto dalle macchine assegnando agli esseri umani più righe da ispezionare. Ha trasferito la maggior parte della lettura di routine ad altri agenti Claude, riservando poi l'approvazione umana alle modifiche più rischiose.

Non si tratta semplicemente di una versione più veloce della revisione convenzionale. Cambia il significato stesso della revisione, chi la svolge e dove inizia la responsabilità. Anthropic considera ora l'attenzione umana una risorsa scarsa, da dedicare al rischio anziché a ogni singola riga.

L'approccio arriva anche con un'importante limitazione. I risultati principali sono misurazioni interne di Anthropic, senza dati grezzi pubblicati né verifiche indipendenti. Il processo dipende da un'ampia automazione, infrastrutture interne, rilasci graduali e un accesso insolitamente esteso ai propri modelli.

Il confronto risultante non è tra Claude e i programmatori umani. È tra copertura automatizzata e ispezione umana universale. Anthropic scommette che controlli stratificati, approvazioni mirate e reversibilità a basso costo possano gestire più rischi della lettura riga per riga alla velocità delle macchine.

Cosa è cambiato nella revisione di Anthropic Claude Code

Anthropic ha trasformato la revisione del codice da un unico controllo umano in un sistema continuo di verifiche automatizzate, agenti revisori, approvazioni mirate e rollback rapidi.

L'azienda ha descritto il sistema in un post tecnico del 15 ottobre dedicato alla revisione di Claude Code. Gli autori Addy Osmani, Morgan Westlee Lunt e Qing Wang hanno inquadrato il problema attorno al volume di output. Quando gli agenti generano modifiche più velocemente di quanto le persone possano leggerle, una coda tradizionale diventa un collo di bottiglia per la distribuzione.

Anthropic afferma che ogni pull request riceve una revisione di Claude prima che una persona la esamini. Il revisore legge la modifica proposta nel contesto del repository più ampio e dell'intento dichiarato nella pull request. Per le correzioni di bug, cerca di identificare la causa principale anziché limitarsi a verificare la patch visibile.

Diversi agenti cercano quindi potenziali difetti in parallelo. Un altro gruppo vota su ogni rilevamento e il sistema pubblica un problema solo quando un numero sufficiente di revisori concorda. Anthropic afferma di aver testato filtri che rimuovono commenti limitati a stile, diagnostica o pulizia facoltativa.

I rilevamenti rimanenti ricevono etichette di gravità. Gli sviluppatori o gli agenti devono correggere ogni rilevamento oppure chiudere il relativo thread motivandolo. Una revisione di sicurezza automatizzata separata può inoltre impedire il merge finché un problema resta irrisolto.

Queste revisioni si affiancano alle salvaguardie convenzionali. Le pull request devono ancora superare linting, controlli di tipo, build e test su tutte le piattaforme supportate. Una coda di merge riesegue i controlli rispetto al ramo main corrente, riducendo i fallimenti causati da modifiche individualmente valide che interagiscono male tra loro.

La revisione inizia prima che esista una pull request. Claude esegue test, build o verifiche visive e mostra le prove risultanti. Un subagente con un contesto nuovo ispeziona quindi il diff, riducendo la probabilità che l'agente autore si limiti a ripetere le proprie ipotesi iniziali.

Le precedenti pratiche di coding di Anthropic raccomandavano di separare i contesti di creazione e verifica. Il nuovo flusso di lavoro trasforma tale raccomandazione in un sistema operativo per l'intero team.

L'approvazione umana dipende dal rischio classificato della modifica. Il lavoro a basso rischio può essere unito dopo il superamento dei controlli automatizzati e di sicurezza. Gli esempi includono documentazione, modifiche ai testi, funzionalità interne e aggiunte nascoste dietro feature flag.

Il normale lavoro sul prodotto richiede generalmente una persona. Anche aree sensibili come caching, system prompt e meccanismi di aggiornamento ricevono attenzione umana. Le modifiche a rischio più elevato richiedono due persone, mentre alcuni percorsi protetti attivano sempre la revisione manuale.

Il classificatore valuta la modifica, non il fatto che sia stata scritta da una persona o da un agente. Un secondo classificatore può comunque richiedere il coinvolgimento umano quando il livello originario appare troppo permissivo. L'approvazione di un agente non occupa mai uno slot riservato a una persona.

Questa distinzione è importante. Anthropic non ha eliminato la responsabilità umana né ha sostenuto che la revisione AI renda il software privo di errori. Ha separato il rilevamento ordinario dei difetti dalle decisioni che coinvolgono architettura, direzione del prodotto, sistemi sensibili e rischio accettabile.

La persona che ha istruito Claude resta responsabile del risultato. Ogni approvazione si applica a uno specifico commit, quindi modifiche successive possono invalidarla. Nel modello di Anthropic, la delega cambia chi scrive e legge il codice, ma non chi possiede il risultato.

I numeri rendono insostenibile la revisione solo umana

Le metriche riportate da Anthropic suggeriscono che la produzione di codice abbia già superato qualsiasi processo di revisione basato sulla lettura umana universale.

L'azienda afferma che le pull request unite nel repository di Claude Code sono più che raddoppiate tra giugno e settembre 2026. Nello stesso periodo, la quota che ha richiesto revert è diminuita di oltre il 40%.

Queste cifre descrivono una direzione, non una performance completa. Anthropic non ha divulgato il numero assoluto di pull request, il tasso iniziale di revert, il tasso finale di revert o la variazione statistica. Un calo relativo del 40% potrebbe partire da una base alta oppure bassa.

Anche la cifra del 90% richiede una formulazione prudente. Anthropic afferma che Claude scrive circa il 90% del codice di Claude Code. Ciò non significa che il modello scelga autonomamente le priorità del prodotto, definisca ogni requisito o si assuma la responsabilità del deployment.

Gli ingegneri continuano a dirigere le attività, valutare le prove, risolvere compromessi progettuali e decidere se il lavoro debba esistere. La paternità del codice da parte delle macchine misura la generazione di codice, mentre l'ingegneria del software comprende molto più della produzione di righe.

Anche con queste precisazioni, Anthropic affronta un reale problema di scalabilità. Il suo monorepo separato sarebbe cresciuto da circa 2.500 modifiche unite al giorno a maggio a oltre 30.000 a settembre. L'azienda ha sviluppato un sistema interno di controllo del codice sorgente chiamato Scion per gestire quel carico di lavoro.

Claude Code utilizza un repository separato, quindi la cifra di 30.000 modifiche non misura direttamente il team del prodotto. Tuttavia, il resoconto di Anthropic sulla sua riprogettazione del controllo del codice sorgente mostra la pressione più ampia che circonda la sua infrastruttura di sviluppo.

Le storie di Scion e Claude Code indicano lo stesso collo di bottiglia. Una volta che gli agenti di coding possono creare, testare e rivedere modifiche in modo continuo, la scrittura del codice smette di controllare il throughput. Code di revisione, build, autorizzazioni, sistemi di integrazione e controlli di rilascio diventano i fattori limitanti.

La revisione tradizionale del codice presuppone che un numero gestibile di modifiche arrivi dalle persone. Un'altra persona legge ogni diff, richiede revisioni e approva la versione finale. Questo modello inizia a rompersi quando l'output cresce più velocemente della capacità dei revisori.

Aggiungere revisori non risolve completamente il divario. Gli ingegneri esperti sono scarsi e una revisione costante interrompe il lavoro di progettazione, debugging e decisione sul prodotto. Un'organizzazione può aumentare il personale addetto alle revisioni pur continuando a perdere attenzione condivisa in un flusso crescente di modifiche.

Anthropic misura quindi più del numero di commenti prodotti. Tiene traccia delle approvazioni umane per pull request, dei commenti umani, dei tempi di attesa, dei revert e degli incidenti. L'obiettivo dichiarato è ridurre il tempo di revisione umana senza trasferire quel tempo al recupero in produzione.

L'azienda riferisce inoltre che il proprio revisore AI commerciale ha aumentato dal 16% al 54% la quota di pull request interne che ricevono commenti sostanziali. La maggior parte delle modifiche oltre le 1.000 righe attirerebbe rilevamenti, mentre la maggior parte delle modifiche più piccole risulta pulita.

Questo risultato non dimostra da solo l'accuratezza. Più commenti possono rappresentare un rilevamento migliore, più rumore, oppure entrambi. Anthropic afferma di valutare la qualità dei commenti osservando se gli sviluppatori correggono i rilevamenti, li respingono o identificano il comportamento segnalato come intenzionale.

Il segnale più ampio è organizzativo. Anthropic non considera più la lettura umana di ogni riga modificata come la prova determinante della revisione. Misura se il sistema combinato intercetta i problemi, indirizza bene l'attenzione e limita i danni in produzione.

Questo cambiamento mette sotto pressione ogni organizzazione ingegneristica che impiega agenti di coding. Se l'output degli agenti cresce mentre la politica di revisione resta fissa, le code si espandono e i previsti guadagni di produttività scompaiono. I team devono limitare la generazione oppure riprogettare il modo in cui la convalidano.

La copertura automatizzata sfida l'ispezione umana universale

Il confronto centrale è tra un'ampia copertura delle macchine e la convinzione che ogni modifica significativa meriti una lettura umana diretta.

L'ispezione umana universale offre una promessa intuitiva. Un ingegnere qualificato comprende il codice, vede la modifica e si assume la responsabilità prima della distribuzione. Questa pratica può diffondere conoscenza e intercettare ipotesi che i test automatizzati non colgono.

Tuttavia, la promessa si indebolisce quando la revisione diventa frettolosa. Una persona davanti a una grande coda può scorrere invece di ragionare, approvare codice dall'aspetto familiare o concentrarsi sullo stile anziché sul comportamento. Una firma umana non garantisce la comprensione.

L'alternativa di Anthropic utilizza più livelli specializzati. Un agente crea la modifica, un altro la revisiona con un contesto nuovo, diversi agenti cercano bug e agenti separati valutano ogni rilevamento. Revisione di sicurezza, integrazione continua, controlli di merge, rilascio graduale e rollback coprono diverse modalità di fallimento.

Questo ricorda una difesa in profondità. Nessun singolo livello necessita di un richiamo perfetto perché livelli successivi possono intercettare ciò che quelli precedenti non hanno rilevato. La classificazione del rischio indirizza quindi il raro giudizio umano verso le modifiche dal maggiore impatto potenziale.

Il meccanismo offre inoltre ad Anthropic una copertura di revisione più ampia. Le macchine possono ispezionare ogni pull request senza attendere la disponibilità di un collega. Possono esaminare il contesto del repository, applicare convenzioni documentate e ripetere gli stessi controlli su migliaia di modifiche.

Le istruzioni archiviate in CLAUDE.md descrivono il progetto, le sue convenzioni e i suoi confini. Un file REVIEW.md separato indica al revisore come appare un fallimento in un particolare repository. I proprietari del codice possono identificare percorsi sensibili ed escludere quelli irrilevanti.

Quando il revisore segnala ripetutamente un errore, il team può trasferire la lezione a monte. Può aggiungere una regola di lint, migliorare un file di istruzioni, modificare una skill o creare un nuovo controllo automatizzato. Il feedback della revisione diventa quindi infrastruttura riutilizzabile.

I fallimenti passati diventano casi di valutazione. Anthropic afferma di aver raccolto pull request associate a incidenti, revert e correzioni successive. Gli ingegneri hanno verificato i bug sottostanti e il revisore ora viene eseguito ogni giorno su quell'insieme.

Si tratta di un distacco significativo dalla revisione come incontro tra due persone. Il sistema tenta di preservare le lezioni in controlli eseguibili anziché dipendere dalla memoria individuale. Ogni incidente può ampliare la futura copertura di rilevamento dell'organizzazione.

Tuttavia, la revisione umana gestisce ancora questioni che non possono essere ridotte alla correttezza locale. Gli ingegneri decidono se una funzionalità debba esistere, se un'astrazione stabilisca un precedente dannoso e se le prove supportino il deployment.

Ispezionano anche aree sensibili, tra cui fatturazione, meccanismi di aggiornamento, integrazione continua e flussi di rilascio. Queste modifiche possono avere un ampio raggio d’impatto anche quando il loro codice appare localmente corretto.

Il processo, quindi, non sostiene che le macchine siano revisori migliori sotto ogni aspetto. Assegna alle macchine il lavoro di lettura che possono svolgere ripetutamente, affidando alle persone le decisioni che riguardano finalità, architettura, incertezza e responsabilità.

Questa divisione trasforma anche le competenze ingegneristiche. Gli ingegneri devono specificare l’intento, individuare i vincoli, progettare le verifiche, interpretare le evidenze e riconoscere quando un agente ha ottimizzato l’obiettivo sbagliato. Leggere il codice resta utile, ma non è più l’unica strada per comprenderlo.

Il team Scion di Anthropic ha offerto un esempio correlato. Gli ingegneri hanno riferito che Claude talvolta perseguiva progetti inefficienti o eccessivamente difensivi, conformi ai pattern locali. Gli umani dovevano respingere tali direzioni perché comprendevano i compromessi a livello di sistema.

L’espressione “human in the loop” può oscurare questo ruolo. Una persona che si limita ad approvare l’output della macchina è una salvaguardia debole. Una persona che definisce i confini, sceglie le evidenze e sa quando fermare l’automazione esercita un controllo significativo.

Per le altre organizzazioni, la lezione non è rimuovere i revisori. È distinguere l’ispezione meccanica dal giudizio. La copertura automatizzata diventa preziosa quando le persone mantengono l’autorità sulle decisioni ad alta conseguenza e sulle evidenze poco chiare.

Come le revisioni di Claude Code evitano cicli infiniti tra agenti

Anthropic ha scoperto che autori AI e revisori AI possono generare lavoro illimitato, a meno che il processo di revisione non sia progettato esplicitamente per convergere.

Più revisioni non significano automaticamente revisioni migliori. Anthropic descrive una pull request di Claude Code che ha attraversato più di 50 cicli di revisione e correzione durante la notte. L’autore alla fine ha interrotto il ciclo.

Il revisore non stava individuando un nuovo difetto critico a ogni passaggio. Anthropic ha usato la cronologia delle versioni per esaminare i rilievi ripetuti e ha rilevato che circa il 59% riguardava codice già presente alla prima revisione.

L’agente continuava a trovare ulteriori vecchi problemi anziché valutare solo la nuova correzione. Ogni commento innescava un’altra correzione, un commit e una revisione. Il sistema restava attivo senza avanzare in modo efficiente verso uno stato finale accettabile.

Questo fallimento illustra un rischio peculiare della revisione del codice con AI. Una persona può scartare in pochi secondi un suggerimento di scarso valore. Un agente autore tende invece ad agire su quel suggerimento, producendo un altro diff che offre all’agente revisore altro materiale.

Anthropic ha risposto introducendo controlli di convergenza. Dopo tre cicli, il revisore chiede all’autore di riconsiderare l’approccio. I passaggi successivi si concentrano sul nuovo diff invece di cercare ripetutamente nell’intera modifica.

Il revisore segnala inoltre un’intera classe di difetti correlati in un’unica volta. Ciò consente all’autore di correggere ogni occorrenza anziché ricevere commenti simili in cicli consecutivi. I rilievi già pubblicati non dovrebbero riapparire.

Anthropic afferma che questi cambiamenti hanno migliorato il proprio ciclo interno di revisione. Secondo quanto riportato, la quota di pull request approvate dopo un ciclo di revisione e correzione è salita dal 65% al 78%.

Le pull request che richiedevano cinque o più cicli sarebbero scese dall’8,9% all’1,5%. La media delle revisioni prima dell’approvazione è diminuita da 2,08 a 1,32. Queste metriche restano riportate dall’azienda stessa, ma affrontano un problema operativo che molti flussi di lavoro basati su agenti trascurano.

La convergenza conta perché il lavoro automatizzato non è gratuito solo perché non richiede uno stipendio. Ogni ciclo aggiuntivo consuma capacità del modello, ritarda la modifica, crea altro codice e aumenta il materiale che i controlli successivi dovranno ispezionare.

Lo stesso problema si manifesta quando i revisori reagiscono in modo eccessivo a minacce ipotetiche. Anthropic afferma che la revisione avversariale può diventare miope, incoraggiando validazioni o complessità eccessive. Un sistema ottimizzato per scoprire possibili guasti può creare nuovi costi di manutenzione.

La profondità basata sul rischio offre un possibile controllo. Il servizio Code Review di Anthropic, generalmente disponibile, supporta diversi livelli di revisione per repository ordinari e critici. L’azienda afferma che la maggior parte delle revisioni si conclude ora in sei-dieci minuti.

Tuttavia, un revisore più rapido non risolve la questione di governance sottostante. I team devono ancora decidere quali rilievi contano, quali percorsi meritano un’ispezione più approfondita e quanti cicli siano accettabili.

Anche le istruzioni di revisione possono diventare un livello di policy nascosto. Se CLAUDE.md, REVIEW.md o i prompt di classificazione contengono assunzioni deboli, gli agenti possono applicarle in modo coerente nell’intero repository.

La coerenza aiuta solo quando la regola è corretta. I team hanno bisogno di responsabilità chiare, controllo di versione, casi di valutazione e revisione delle istruzioni che guidano i loro revisori. Altrimenti, l’automazione può scalare una policy errata più velocemente di quanto gli umani se ne accorgano.

È qui che il contesto ingegneristico condiviso diventa importante. Le organizzazioni che adottano agenti necessitano di registri durevoli delle decisioni architetturali, delle lezioni tratte dagli incidenti e degli approcci respinti. Una knowledge base ingegneristica ricercabile può contribuire a preservare quel contesto oltre il singolo thread di revisione.

Il processo di Anthropic funziona perché tratta il revisore come un sistema che necessita di misurazione. Tiene traccia di accuratezza, rumore, cicli, incidenti e risposte degli sviluppatori. Installare un revisore AI senza questi cicli di feedback significherebbe copiare lo strumento visibile, ma perdere il modello operativo.

Cosa i risultati di Anthropic non dimostrano ancora

Le affermazioni più forti restano auto-riportate e Anthropic non ha dimostrato che i suoi risultati si trasferiscano a team con infrastrutture, budget o tolleranza agli errori diversi.

La prima incertezza riguarda la misurazione. Anthropic ha riferito che le pull request unite sono più che raddoppiate e che la quota di revert è diminuita di oltre il 40%. Non ha pubblicato il dataset sottostante, i tassi assoluti o la distribuzione della gravità degli incidenti.

Una quota di revert in calo può essere incoraggiante pur nascondendo esiti importanti. I team possono correggere in avanti anziché effettuare un revert, disattivare un feature flag o tollerare una regressione che non riceve mai tale etichetta. I revert sono utili, ma incompleti.

I tassi di incidenti offrono un’altra barriera di protezione, eppure il post pubblico non fornisce una serie dettagliata di incidenti. Senza dati sulla gravità e sull’esposizione, gli osservatori esterni non possono stabilire se il processo abbia ridotto il rischio o abbia cambiato il modo in cui i guasti venivano gestiti.

Il dato del 90% di attribuzione agli autori comporta un’ambiguità simile. Non specifica se la misurazione conti righe generate, righe accettate, commit o un’altra unità. Non rivela nemmeno quanto prompting, editing e iterazione umani abbiano preceduto il codice finale.

L’ambiente di Anthropic è insolitamente favorevole a questo metodo. L’azienda controlla i modelli, può spendere una notevole capacità di calcolo per revisori paralleli e sviluppa infrastrutture interne attorno a carichi di lavoro generati dagli agenti.

I suoi dipendenti usano inoltre Claude Code internamente prima dei rilasci pubblici. Le nuove funzionalità possono passare attraverso il deployment interno, un canale latest e poi un canale stabile. I feature flag consentono al team di disabilitare un comportamento senza un deployment completo.

I team che operano sistemi medici, finanziari, industriali o critici per la sicurezza possono affrontare requisiti diversi. Un rollback rapido non può annullare ogni conseguenza. Una migrazione dati difettosa, una modifica all’autorizzazione o un’azione esterna possono produrre danni irreversibili.

Anthropic riconosce che le merge errate dipendono ancora da autori, ingegneri on-call, telemetria e dashboard per essere rilevate. Non dispone ancora di circuit breaker automatici che aumentino i requisiti di approvazione quando crescono revert o incidenti.

Questa lacuna conta perché la classificazione del rischio può diventare obsoleta. Una modifica etichettata come a basso rischio può interagire con dipendenze nascoste. Anche una serie di modifiche singolarmente sicure può produrre uno stato combinato pericoloso.

La sicurezza introduce un’altra preoccupazione. Anthropic usa la revisione automatizzata della sicurezza, ma i suoi stessi materiali sul rischio mostrano perché la supervisione umana resti necessaria. La sua valutazione del sabotaggio descrive il monitoraggio dei modelli come un controllo in evoluzione, non come una garanzia completa.

Le reazioni della community hanno sollevato interrogativi più ampi su costi e comprensione. Alcuni sviluppatori sostengono che Anthropic possa sostenere pattern di revisione che altrove sarebbero antieconomici. Altri temono che un minor numero di persone impegnate a leggere i diff indebolisca la conoscenza collettiva della codebase.

Anthropic afferma apertamente che nessuno nel team Claude Code mantiene un modello mentale completo del prodotto. Gli ingegneri chiedono invece a Claude di spiegare il sottosistema pertinente quando ne hanno bisogno.

Questo approccio può mantenere aggiornate le spiegazioni, ma crea una dipendenza. Se la spiegazione generata non coglie un’interazione, l’ingegnere potrebbe prendere una decisione usando una mappa incompleta. La stessa famiglia di modelli potrebbe inoltre ripetere assunzioni incorporate nel codice che revisiona.

La revisione tra modelli diversi potrebbe offrire ulteriore diversità, ma non migliora automaticamente l’accuratezza. Sistemi diversi possono condividere pattern di addestramento o fallire per ragioni non correlate. La proprietà importante è l’evidenza indipendente, non semplicemente un nome di modello diverso.

Nessuna di queste domande invalida i risultati riportati da Anthropic. Ne limita ciò che tali risultati dimostrano. L’azienda ha mostrato un processo interno dettagliato con metriche direzionali incoraggianti, non un sostituto universale della revisione umana del codice.

Tre segnali verificheranno se il modello regge

Il prossimo test sarà capire se Anthropic riuscirà a preservare la qualità mentre aumentano le merge senza intervento umano, i prodotti di revisione raggiungono altre aziende e i concorrenti adottano controlli diversi.

Il primo segnale è la policy di approvazione di Anthropic stessa. Il suo processo attuale consente a modifiche selezionate a basso rischio di essere unite senza un revisore umano separato dopo il superamento dei controlli automatizzati.

Occorre osservare se questo confine si estenderà a una porzione maggiore del codice di prodotto. Se Anthropic aggiungerà i circuit breaker desiderati dai suoi ingegneri, un’escalation automatica potrebbe rendere più credibile un’adozione più ampia. L’aumento degli incidenti o il ritorno ad approvazioni più rigide indebolirebbero questa tesi.

Il secondo segnale è rappresentato dalle evidenze di organizzazioni esterne che utilizzano la revisione automatizzata. Anthropic ha rilasciato Code Review per i clienti Team ed Enterprise, creando un test più ampio su repository e culture ingegneristiche non familiari.

Le metriche utili non saranno il numero di commenti o di pull request revisionate. I team dovrebbero riportare rilievi accettati, difetti sfuggiti, falsi positivi, latenza della revisione, sforzo umano e incidenti in produzione.

Risultati comparabili al di fuori di Anthropic rafforzerebbero l’affermazione secondo cui la revisione AI a più livelli può scalare. Rumore elevato, uso crescente dei modelli o tassi di incidenti invariati suggerirebbero invece che il successo di Anthropic dipende dal suo ambiente interno.

Il terzo segnale è la risposta della concorrenza. OpenAI, GitHub, Google, Cursor e altri fornitori di agenti per la programmazione affrontano lo stesso squilibrio tra codice generato e capacità dei revisori.

Le loro scelte riveleranno se la revisione basata sul rischio diventerà un modello condiviso. I sistemi concorrenti potrebbero privilegiare la revisione tra modelli diversi, sandboxing più robusto, verifica formale, valutazione specifica per repository o approvazione umana più persistente.

Gli sviluppatori dovrebbero resistere alla tentazione di ridurre questo dibattito alla domanda se l’AI possa trovare bug. La domanda pratica è se un sistema completo di revisione possa allocare l’attenzione, preservare la responsabilità e recuperare in sicurezza quando ogni livello manca qualcosa.

Per i leader ingegneristici, l’azione immediata è la misurazione. Stabilite valori di riferimento per tempi di revisione, difetti sfuggiti, falsi positivi, tassi di revert e gravità degli incidenti prima di modificare la policy di approvazione. Senza questa base di riferimento, merge più rapide possono sembrare un miglioramento mentre spostano i costi altrove.

I team dovrebbero inoltre distinguere i cambiamenti reversibili da quelli irreversibili. Documentazione, modifiche segnalate all’interfaccia e strumenti interni non meritano lo stesso processo riservato ad autenticazione, fatturazione, migrazioni o infrastruttura di rilascio.

La revisione di Anthropic Claude Code offre una risposta concreta a un problema che molti team dovranno presto affrontare. Considera la revisione come un sistema di controllo a più livelli, anziché come prova che una persona abbia letto ogni riga.

I dati riportati dall’azienda rendono questa risposta degna di essere testata, non copiata ciecamente. Se i vostri agenti raddoppiassero domani l’output di codice, quali evidenze permetterebbero ai vostri revisori di smettere in sicurezza di leggere tutto oggi?