TL;DR: dal 14 agosto 2026 Claude Code userà auto mode come impostazione predefinita nelle nuove sessioni Pro, Max e Team, salvo configurazioni già fissate. Il classificatore riduce le richieste di approvazione, ma non trasforma un coding agent in un operatore affidabile su produzione. Per usarlo in una PMI servono cinque confini esterni al modello: workspace isolato, credenziali minime, rete controllata, Git protetto e rilascio separato.

Cosa cambia il 14 agosto 2026

Anthropic ha annunciato che le nuove sessioni Claude Code sui piani Pro, Max e Team partiranno in auto mode dal 14 agosto 2026. Chi ha già fissato una modalità predefinita non subirà il cambio; per Enterprise, API e piattaforme cloud l’opzione resta per ora volontaria.

La differenza è pratica. Nella modalità manuale l’agente si ferma spesso davanti a scritture e comandi. In auto mode, le operazioni soggette al controllo dinamico vengono valutate da un classificatore, che può lasciarle proseguire, bloccarle o chiedere un’approvazione. Alcune regole statiche e operazioni già consentite vengono risolte prima di questo passaggio. Dopo tre blocchi consecutivi, o venti nella stessa sessione, Claude Code torna alle approvazioni manuali.

La promessa è meno babysitting. Anthropic dichiara che, in un test controllato con 1.053 professionisti pagati, le persone hanno intercettato il 13,6% dei comandi pericolosi inseriti nell’esperimento, mentre auto mode ne ha bloccati l’89%. Sono dati prodotti e commissionati dal fornitore, in un ambiente di test, quindi non vanno letti come garanzia universale. Mostrano però un problema reale: quando un’interfaccia chiede conferma cento volte, l’utente impara a premere sì.

Auto mode non è il tuo sistema di sicurezza

Un classificatore di permessi risponde a una domanda stretta: questa singola azione sembra compatibile con ciò che l’utente ha chiesto? Non conosce da solo il valore dei dati, il contratto con il cliente, il costo di un fermo o la procedura di rollback dell’azienda.

Se l’agente può leggere una chiave amministrativa, raggiungere il database live e distribuire sulla branch di produzione, il problema esiste prima della classificazione. Auto mode può bloccare molti errori, non deve essere l’ultimo ostacolo tra un prompt ambiguo e un sito fermo.

La mia regola è semplice: la modalità di permesso decide quanto spesso l’agente interrompe il lavoro. L’architettura decide quanto danno può fare quando sbaglia. Sono due livelli diversi e vanno progettati separatamente.

Prima del tool: classifica l’ambiente

Prima di attivare un coding agent, assegna il lavoro a una delle tre classi seguenti:

  • Laboratorio: clone usa e getta, dati sintetici, nessuna credenziale esterna. Qui auto mode può lavorare con ampia autonomia.
  • Staging: repository reale e servizi di test, con token limitati. L’agente prepara patch, esegue test e apre una revisione.
  • Produzione: dati clienti, deploy, DNS, pagamenti o database live. L’agente può analizzare e proporre; l’azione finale resta a una pipeline deterministica o a una persona autorizzata.

Questa classificazione evita la discussione generica su quale modalità sia “sicura”. Lo stesso comando può essere innocuo in un clone temporaneo e grave sul server del cliente.

Ho già affrontato il tema della superficie di danno in Agenti AI sui tuoi file: sandbox o backup?. Il punto vale anche qui: il backup aiuta dopo l’incidente; la sandbox riduce ciò che l’agente può toccare durante il lavoro.

Il modello operativo: cinque confini da configurare

1. Limita il filesystem al task

Avvia la sessione nella cartella del progetto, non nella home dell’utente o in una directory condivisa con altri clienti. Per i task lunghi usa un clone dedicato o un worktree. I file temporanei e gli output generati devono restare in una cartella prevista, così diff e pulizia non coinvolgono materiale estraneo.

Prima della sessione registra lo stato Git. Se esistono modifiche non committate, l’agente deve trattarle come dati dell’utente: non sovrascriverle, non spostarle e non “ripulire” il repository per comodità.

2. Riduci credenziali e privilegi

L’agente non dovrebbe trovare una chiave onnipotente solo perché il terminale dell’amministratore la possiede. Usa credenziali specifiche per ambiente e funzione: lettura quando basta leggere, staging quando basta testare, token con durata e scope ridotti per un’automazione.

Le credenziali non vanno copiate nei prompt, nei log o nel repository. Se un comando può stampare URL di paging, header o variabili d’ambiente, considera anche l’output come materiale sensibile. Il controllo deve coprire ciò che esce dal tool, non soltanto il comando che entra.

3. Controlla rete e destinazioni

Molti incidenti agentici non sono cancellazioni: sono invii al posto sbagliato. Un upload, un push o una richiesta API può essere tecnicamente valido ma diretto a un repository pubblico, a un account personale o al sito live.

Definisci una lista corta di destinazioni ammesse. Se usi server MCP o connettori, esponi solo gli strumenti necessari al task e preferisci operazioni in sola lettura durante analisi e diagnosi. Per le scritture esterne, verifica esplicitamente account, risorsa e ambiente prima della chiamata.

4. Usa Git come confine, non come cestino

Una branch dedicata, una main protetta e una pull request obbligatoria rendono visibile il lavoro dell’agente. Non bastano da sole, ma separano la generazione dalla decisione di integrare.

Il gate minimo deve includere diff leggibile, test, lint e controllo dei file inattesi. Se l’agente modifica dipendenze, migrazioni, configurazioni CI o file di sicurezza, la revisione cambia livello: non è più una normale correzione applicativa.

5. Separa preparazione e rilascio

Il coding agent può arrivare fino a una patch verificata. Il deploy live dovrebbe passare da un comando o workflow distinto, con target esplicito, controlli predefiniti e log. Per DNS, database, pagamenti e pubblicazioni esterne aggiungerei sempre una conferma umana o un’approvazione fuori dalla sessione agentica.

Questo confine elimina una scorciatoia pericolosa: dare all’agente accesso alla produzione perché “tanto sa anche fare i test”. Preparare bene e distribuire bene sono responsabilità diverse.

Caso pratico: plugin WordPress su staging

Immaginiamo una piccola agenzia che deve correggere un plugin custom per WordPress. Il bug riguarda la sanitizzazione di un campo nel pannello amministrativo.

Il task parte da un clone dedicato del repository, senza file .env di produzione. L’agente riceve il ticket, i passi per riprodurre il problema e il comando della suite. Può leggere il codice, preparare una patch, eseguire PHP_CodeSniffer e i test. Può anche creare una build da installare sullo staging.

Non può collegarsi al database live, caricare ZIP nel sito del cliente o inviare email di prova a destinatari reali. Lo staging usa dati fittizi e un account WordPress limitato. La pipeline rifiuta la build se cambia file fuori dal plugin, introduce query non preparate o salta escaping e sanitizzazione.

Alla fine una persona controlla il diff e prova il flusso nel browser. Solo dopo l’approvazione parte il deploy, con backup e rollback già predisposti. Auto mode ha tolto interruzioni durante analisi, modifica e test. Non ha ricevuto il potere di decidere quando il cliente va aggiornato.

Questo è il modo corretto di leggere l’autonomia: non come accesso illimitato, ma come lavoro continuo dentro un perimetro ristretto.

Una procedura da applicare in trenta minuti

  1. Scrivi il risultato atteso e le azioni vietate nel brief del task.
  2. Crea un workspace isolato e verifica che Git sia pulito o che le modifiche esistenti siano note.
  3. Rimuovi credenziali non necessarie; sostituisci i token live con identità di staging a privilegi minimi.
  4. Limita strumenti e destinazioni di rete a quelli richiesti.
  5. Definisci i comandi di verifica prima di avviare il lavoro: test, lint, build e controllo del diff.
  6. Fissa il punto di arresto: patch o pull request pronta, mai deploy implicito.

Per un pilot aziendale aggiungerei durata e metriche. In Pilot AI coding: metriche in 30 giorni propongo di misurare tempo fino alla prima patch utile, tasso di rilavorazione, difetti sfuggiti e tempo di revisione. Qui vanno aggiunti blocchi del classificatore, richieste di escalation e tentativi verso risorse vietate.

Cosa misurare nelle prime due settimane

Non partire dal numero di righe generate. Misura cinque segnali:

  • quante sessioni arrivano a una patch verificabile senza intervento;
  • quante azioni vengono bloccate e per quale motivo;
  • quanto tempo umano serve per il review finale;
  • quanti cambiamenti fuori scope compaiono nel diff;
  • quanti task richiedono accessi più ampi del previsto.

Anthropic riporta circa il 25% di pull request in più tra gli adottanti Team ed Enterprise di auto mode. È un dato del fornitore e non dice nulla, da solo, sulla qualità. Se aumentano le PR ma raddoppiano review e rilavorazione, non hai guadagnato capacità: hai spostato il collo di bottiglia.

L’errore da evitare: sostituire “approve” con fiducia implicita

Il rischio più probabile non è un comando spettacolare. È il graduale allargamento dei privilegi: prima il token di staging, poi quello live “per un test”, poi l’accesso al deploy perché il flusso manuale è lento.

Auto mode nasce anche per ridurre la fatica da approvazione. Se però lo usi per giustificare un ambiente senza confini, ricrei lo stesso problema a un livello più alto. Prima l’utente approvava tutto. Ora l’infrastruttura permette tutto.

Take finale: automatizza il lavoro, non la fiducia

Per una PMI, auto mode è utile quando elimina conferme ripetitive dentro un ambiente ben progettato. Lo attiverei su clone isolati e staging, con Git protetto e credenziali minime. Non lo userei come scorciatoia per consegnare a un agente il pannello completo dell’azienda.

La domanda da fare non è “il classificatore è più bravo di me a leggere un comando?”. È “se entrambi sbagliamo, qual è il massimo danno possibile?”. Se la risposta include dati clienti, produzione o denaro, il confine va spostato prima di avviare la sessione.

Fonti