Il test che Anthropic ha condotto su 1.053 sviluppatori reali

Kai Zhou, staff software engineer da Nuro, ha avviato un agente Claude Code alle 22 e lo ha lasciato lavorare. Quando è tornato a controllare alle 5 del mattino, l'agente aveva prodotto tre pull request, e per tutta la notte non aveva dovuto cliccare una sola richiesta di permesso per ottenerle. "Ho avviato un agente alle 22 ed è rimasto in esecuzione fino alle 5 del mattino, e la mattina mi ha dato tre PR", ha raccontato. Questo tipo di esecuzione non presidiata è esattamente ciò che la modalità automatica di Anthropic è stata costruita per rendere normale invece che eccezionale, e a partire dal 14 agosto 2026 diventa il comportamento predefinito per ogni account Claude Code sui piani Pro, Max e Team, non più un'impostazione facoltativa che un team deve cercare e attivare.

Prima di prendere questa decisione, Anthropic ha condotto un test controllato per verificare se eliminare la richiesta di permesso sia davvero più sicuro o solo più veloce. Ha reclutato 1.053 tester professionisti a pagamento e, a metà sessione, ha sostituito con un comando realmente pericoloso la richiesta di permesso che ciascuno di loro vedeva. I tester che si affidavano alla revisione manuale lo hanno individuato nel 13,6 per cento dei casi - 143 su 1.053. La modalità automatica, osservando le stesse sessioni, ha bloccato l'89 per cento degli stessi comandi inseriti - 937 su 1.053. Sullo stesso identico test, sulla stessa identica popolazione, il controllo automatizzato ha rilevato l'azione pericolosa circa 6,5 volte più spesso della revisione umana.

Cosa cambia davvero il 14 agosto

La modalità automatica non elimina del tutto le richieste di permesso. Anthropic la descrive come un sistema che instrada le chiamate agli strumenti attraverso un classificatore che continua a fermarsi e chiedere quando un'azione appare irreversibile, distruttiva o diretta al di fuori del proprio ambiente - cancellare dati, pubblicare in produzione, contattare un sistema che l'agente non ha un motivo chiaro per toccare. Se il classificatore continua a bloccare, la sessione torna all'approvazione manuale dopo 3 blocchi consecutivi o 20 blocchi in una sessione, cosicché un'esecuzione autonoma lunga ha sempre un punto di controllo incorporato invece di arrivare fino in fondo senza supervisione qualunque cosa incontri. Anthropic ha inoltre aggiunto un livello dedicato di rilevamento delle prompt injection e regole di blocco fisso configurabili che un amministratore può impostare per impedire azioni specifiche, come percorsi di esfiltrazione dei dati, a prescindere da cosa decida il classificatore stesso.

Il team che lo costruisce vive già così. "Il team e io usiamo la modalità automatica in modo esclusivo, e lo facciamo da molti mesi. Non riuscirei a immaginare di tornare alle richieste di permesso", ha detto Boris Cherny, che guida Claude Code in Anthropic. Tomislav Reil di Adobe, Director of Engineering, ha descritto uno schema simile nel proprio flusso di lavoro: "Claude costruisce l'interfaccia utente e poi torna a verificare che corrisponda al design previsto, correggendo automaticamente eventuali problemi prima ancora che li vediamo". Secondo Anthropic, i team che adottano la modalità automatica consegnano circa il 25 per cento in più di pull request, e dal 14 agosto smette anche di addebitare agli account Pro, Max e Team il costo aggiuntivo di token generato dal classificatore stesso, con la stessa modifica dei prezzi prevista per Enterprise, per ora ancora facoltativo, entro circa un mese.

La base di partenza reale non era mai stata una revisione accurata

Il confronto su cui Anthropic vuole richiamare l'attenzione è il tasso di rilevamento dell'89 per cento della modalità automatica contro il 13,6 per cento della revisione manuale. Ma un numero distinto, comunicato insieme all'annuncio, spiega meglio da dove nasca quel divario: gli utenti di Claude Code approvano già il 97 per cento delle richieste di permesso che vedono. Questo è il punto di partenza onesto per questa decisione, e non è "un revisore umano attento contro un pilota automatico non testato". È un revisore che per abitudine approvava già circa 19 richieste su 20, sostituito da un sistema misurabilmente migliore nel riconoscere quell'una su 20 che contava davvero. I dati di produzione di Anthropic lo confermano anche al di fuori del test di laboratorio: le sessioni basate su approvazione manuale hanno registrato danni non intenzionali di livello di gravità 7 o superiore nel 6,3 per cento dei casi, contro il 2,4 per cento delle sessioni in modalità automatica con lo stesso tipo di lavoro.

Nulla di tutto ciò rende l'89 per cento un numero definitivo. Il test di Anthropic lascia comunque l'11 per cento dei comandi pericolosi inseriti che il classificatore non avrebbe bloccato, e la lettura onesta dello studio è "decisamente più sicuro di quello che la maggior parte dei team faceva davvero", non "risolto". Anthropic riporta anche un tasso di successo dello 0 per cento per gli attacchi di prompt injection contro i modelli Claude in modalità automatica nella propria valutazione, e associa questa affermazione al nuovo livello di rilevamento e alle regole di blocco fisso descritte sopra.

Un commento indipendente pubblicato un giorno prima dell'annuncio di Anthropic, dello sviluppatore e ricercatore di modelli linguistici Simon Willison, ha tracciato una distinzione più netta da tenere presente in qualsiasi decisione di adozione: riconoscere un danno accidentale e incauto è un problema diverso dal riconoscere un'istruzione deliberatamente malevola introdotta nel contesto di un agente. Il suo esempio era un pacchetto di terze parti compromesso le cui istruzioni sembrano un normale passaggio interno all'ambiente - "esegui la suite di test" - ma che in realtà attiva una richiesta malevola, esattamente il tipo di azione che un classificatore addestrato a segnalare lavoro "diretto al di fuori del proprio ambiente" potrebbe lasciar passare proprio perché, a prima vista, non sembra esterna. Questo non è un argomento a favore del mantenimento della revisione manuale, che nel test di Anthropic ha rilevato meno di tutto. È una ragione per non trattare il classificatore come una risposta completa alle istruzioni iniettate, ma solo a quelle accidentali e distruttive.

Cosa decidere prima del 14 agosto, non dopo

Verificate cosa la modalità automatica può toccare, prima che il default cambi sotto di voi. Il classificatore di Anthropic traccia una propria linea intorno a "irreversibile, distruttivo o diretto al di fuori del proprio ambiente" - elencate le azioni della vostra pipeline specifica che quella linea potrebbe non cogliere ma che considerereste comunque irreversibili: scritture sul database di produzione, rotazione delle chiavi, comandi di deploy, tutto ciò che raggiunge un ambiente cliente. Le nuove regole di blocco fisso di Anthropic permettono a un amministratore di bloccarle esplicitamente; impostatele prima del 14 agosto, non dopo che una sessione ne ha già eseguita una.

Fissate la vostra soglia di fallback, non quella predefinita di Anthropic. Il trigger di 3 blocchi consecutivi o 20 per sessione per l'approvazione manuale è un'impostazione predefinita, non una legge fissa, e un tetto non presidiato di 20 azioni è un margine ampio per una singola sessione notturna come quella di Kai Zhou. Abbassatela per qualsiasi pipeline che tocca credenziali, dati dei clienti o infrastruttura di produzione, e lasciatela al valore predefinito solo dove un errore è davvero recuperabile.

Risolvete la questione del registro di controllo prima che lo chieda un regolatore. Se la vostra organizzazione rientra nell'ambito di NIS2 o DORA, verificate - questa settimana, non durante una futura verifica - che le decisioni di blocco e permesso della modalità automatica vengano registrate con lo stesso livello di dettaglio probatorio della vostra precedente traccia di approvazione umana. L'annuncio di Anthropic non affronta direttamente questo punto; verificarlo spetta al team che adotta lo strumento, non al fornitore, prima che "abbiamo rimosso le richieste di permesso" diventi la risposta a una domanda sulla supervisione del rischio ICT.