Agente AI autonomo: come farlo lavorare per ore senza ottenere spazzatura

Che cos'è un agente AI autonomo e in cosa si differenzia da una richiesta normale

Il lavoro normale con un agente procede passo dopo passo: si scrive un prompt, l'agente compie un passo, si guarda il risultato e si decide il seguito. Un agente AI autonomo lavora invece in un ciclo: si descrive una volta come appare lo stato finale, e poi l'agente ripete da solo il ciclo «fare — verificare — correggere», finché l'obiettivo non è raggiunto o il budget non si esaurisce. Dopo l'avvio si può smettere di seguirlo.

Sembra semplice, ma la prima esperienza tipica va così: l'agente riceve il compito al mattino e la sera si scopre che per ore ha sistemato un bug già corretto, perché aveva dimenticato cosa aveva fatto un'ora prima. Nessuno gli ha detto quando fermarsi e quando chiamare una persona. Qui sotto vediamo come progettare un ciclo che non lo permetta.

Una precisazione importante: il ciclo non sostituisce l'harness. L'harness rende affidabile una singola esecuzione, il ciclo rende continue le esecuzioni. Un ciclo costruito sopra un harness scadente produce solo spazzatura più in fretta.

Un compito è adatto a un agente autonomo?

La prima domanda è se il lavoro ha un traguardo finale che una macchina può verificare. «Tutti i test nella cartella tests/payments passano», «tutte le funzionalità dell'elenco sono in stato passing», «la metrica è cresciuta rispetto alla baseline» — sono obiettivi adatti. «Rendi il codice migliore» o «continua a migliorare i pagamenti» — no: un obiettivo così non ha fine, e il ciclo girerà finché non consumerà tutto il budget.

Conviene distinguere quattro tipi di cicli:

• Passo per passo — inserisci tu ogni prompt; è il normale lavoro interattivo.
• Per obiettivo — definisci l'obiettivo, a fermare il ciclo sono un controllo indipendente o il budget. È l'agente autonomo di ore.
• Per tempo — avvio pianificato (per esempio, l'analisi mattutina delle build CI cadute), e lo fermi a mano.
• Per evento — un trigger esterno (una nuova issue, un deploy caduto) avvia l'elaborazione, e la conclusione dell'evento o il limite di ripetizioni fermano il ciclo.

Un errore frequente è confondere il ciclo per tempo con quello per obiettivo: «ogni 10 minuti continua a fare i pagamenti». Un ciclo pianificato riparte ogni volta dalle istruzioni da zero e non sa cosa è già stato fatto. Se il compito ha una fine, serve un ciclo per obiettivo con una memoria del progresso.

Passo 1. Sandbox: dove l'agente può sbagliare

Un agente che lavora senza supervisione prima o poi farà qualcosa di sbagliato: cancellerà un file, riscriverà una migrazione, lancerà un comando pesante. Quindi la domanda non è «come fare in modo che non sbagli», ma «come fare in modo che un errore non costi nulla».

• Copia di lavoro separata. git worktree dà all'agente una propria cartella e un proprio ramo sopra lo stesso repository. Il ramo principale resta intatto, più agenti non si intralciano e un'esecuzione fallita si elimina con un solo comando.
• Container o macchina virtuale. Se l'agente ha bisogno di pieno accesso ai comandi, avvialo in un container senza accesso alla home, alle chiavi e ai database di produzione.
• Dati di test. Database locale, sandbox dei sistemi di pagamento, chiavi fittizie. Nessun segreto di produzione nell'ambiente dell'agente.

# ramo e cartella propri per l'esecuzione autonoma
git worktree add ../shop-agent -b agent/f03-refunds

# dopo l'esecuzione: vedere il risultato oppure buttarlo via
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Passo 2. Permessi: il minimo sufficiente per il compito

Più a lungo l'agente lavora da solo, più stretti devono essere i suoi permessi. In Claude Code i permessi si configurano in settings.json (liste allow e deny per strumenti e comandi): consenti esplicitamente ciò che serve al compito — eseguire test, linter, modificare file nella copia di lavoro — e vieta ciò che è pericoloso: push sul ramo principale, lavoro con i segreti, comandi di rete, se non servono.

La modalità in cui l'agente esegue tutto senza conferme è ammissibile solo dentro una sandbox isolata, dove il peggior esito è un container gettato via. Su una macchina di lavoro con accesso alle tue chiavi e ai tuoi repository non va mai usata.

I divieti che non si possono violare vanno rafforzati con un meccanismo, non con un testo. La frase «non toccare migrations/» nelle istruzioni è un desiderio; un hook che blocca le modifiche a quella cartella, oppure i permessi del file system, sono una garanzia.

Passo 3. Obiettivo, verifica, arresto — tre righe prima dell'avvio

Un ciclo di lavoro semplice si regge su tre cose, che conviene scrivere prima dell'avvio e non durante:

1. Obiettivo — come appare lo stato finale.
2. Verifica — un modo verificabile da una macchina per sapere se l'obiettivo è raggiunto: un comando che restituisce successo o errore.
3. Condizione di arresto — un limite di tentativi, di tempo o di denaro, superato il quale il ciclo si ferma anche se l'obiettivo non è raggiunto.

Conviene tenere tutto questo in un file di metodologia che modifica solo una persona. Esempio per un backend di pagamenti:

# program.md — metodologia dell'esecuzione autonoma

## Obiettivo
Tutte le funzionalità in .agent/feature_list.json sono in stato passing.

## Metrica
Numero di funzionalità in passing. Cresce in modo monotono. Regressione = rollback immediato.

## Vincoli
- Una sola funzionalità in lavorazione alla volta.
- Non modificare migrations/ e infra/.
- Non toccare le dipendenze senza annotarlo nel registro.

## Ordine di lavoro
1. Prendere la prima funzionalità non in passing.
2. Implementarla, eseguire pytest e il linter.
3. Verde — commit e annotazione in .agent/progress.md. Rosso — correggere.

## Arresto ed escalation
- 3 tentativi falliti su una funzionalità — segnarla come blocked e passare alla successiva.
- Tutte le restanti blocked — fermarsi e scrivere un rapporto.
- Qualsiasi compito che riguarda denaro dei clienti, diritti di accesso, cancellazione di dati — non eseguirlo, ma fare escalation.

Passo 4. Ciclo controllo-correzione con memoria su disco

La finestra di contesto non sopravvive a un lavoro lungo: si riempie, viene compressa, la sessione viene riavviata. Per questo il progresso deve vivere nei file e non nella «testa» dell'agente: l'elenco dei compiti con lo stato, il registro di ciò che è stato fatto e di ciò che non ha funzionato, la cronologia di git.

Un buon modello è la «cricca che si muove solo in avanti», come nel progetto autoresearch di Andrej Karpathy, in cui l'agente per una notte conduce centinaia di esperimenti di machine learning. Ogni iterazione: leggere la metodologia, formulare un'ipotesi, introdurre una modifica, eseguire l'esperimento con un budget di tempo fisso, confrontare con la baseline. Se migliora, commit; se non migliora, rollback. Il risultato va nel registro, poi si passa all'ipotesi successiva.

Da questo schema conviene prendere due decisioni:

• Budget fisso per tentativo. I tentativi diventano confrontabili, e un'ipotesi sbagliata non consuma tutta la notte.
• Nel ramo principale solo i miglioramenti. Tutto ciò che non ha funzionato viene annullato, non lasciato accanto. git log diventa un registro verificato del lavoro, facile da leggere al mattino.

Lo stesso schema mostra la separazione dei ruoli per file: l'infrastruttura e la valutazione non le modifica nessuno, il codice dell'esperimento lo modifica solo l'agente, la metodologia solo la persona. L'agente non può «migliorare» il risultato alterando il modo in cui viene misurato.

Passo 5. Chi decide che è pronto: un valutatore separato

Quando non c'è una persona nel ciclo, l'autovalutazione dell'agente diventa l'unico freno — e questo freno non funziona. L'agente che ha appena scritto il codice tende a considerarlo corretto: vede i propri ragionamenti e «sa» cosa intendeva fare.

Regole per separare generatore e valutatore:

• A valutare non è la stessa sessione che ha svolto il lavoro. In Claude Code per questo sono utili i subagenti: ognuno ha il proprio contesto.
• Il valutatore riceve un contesto pulito: il requisito, il diff e i risultati delle esecuzioni — e nient'altro del ragionamento dell'esecutore.
• Se possibile, il valutatore è un altro modello, o almeno un altro prompt con un altro ruolo.
• Il verdetto si esprime secondo una rubrica, e ogni voce rimanda a una prova: una riga di test, l'output di un comando, un punto del diff.

I controlli automatici restano comunque primari. Il valutatore serve per ciò che i test non colgono: il requisito è stato capito in modo sbagliato, il test è stato adattato al codice, la modifica è andata oltre il compito.

Criteri di arresto: quando l'agente deve arrendersi

Un ciclo senza condizioni di arresto va in loop: è solo questione di tempo. Il minimo indispensabile:

Verifica il progresso nella sostanza, non dal numero di tentativi: «fatte 40 iterazioni» non significa nulla, «il numero di funzionalità verdi è passato da 5 a 9» significa qualcosa. Se un compito è bloccato, è il momento di passarlo a una persona, non di far girare il ciclo un'altra volta.

Rischi dell'agente autonomo che non si vedono subito

I rischi evidenti — file cancellati e build rotta — si chiudono con sandbox e permessi. Più pericolosi sono i costi nascosti che si accumulano per settimane:

• Debito di verifica. «Sembra a posto» al posto di «confermato da una macchina». Il rimedio sono solo condizioni di arresto verificabili dalla macchina, senza eccezioni.
• Perdita di comprensione. Conosci sempre peggio il tuo codice. Il rimedio è la lettura obbligatoria dei diff: la velocità del ciclo non deve superare la tua velocità di lettura.
• Capitolazione cognitiva. Smetti di avere un'opinione sul risultato e accetti tutto. Conviene contare onestamente i casi in cui hai detto «guarderò dopo» e non hai guardato.
• Gonfiamento del contesto. Un'esecuzione lunga accumula storia, e ogni passo successivo costa di più e funziona peggio. Compressione del contesto e memoria esterna servono dal primo ciclo, non quando tutto ha già cominciato a deragliare.

Come avviare il primo ciclo autonomo in una serata

Non iniziate con «l'agente troverà e farà da solo i compiti». L'autonomia cresce per gradini: prima un solo compito con obiettivo e condizione di arresto, poi un'automazione pianificata, poi un esecutore e un verificatore separati in una copia di lavoro isolata, e solo dopo cicli che trovano il lavoro da soli e girano in parallelo.

1. Trova un compito che fai a mano almeno due volte a settimana e che ha un traguardo verificabile.
2. Scrivi obiettivo, verifica e condizione di arresto — tre righe.
3. Crea un worktree separato e configura i permessi: test e modifica dei file consentiti, push e segreti no.
4. Crea un file di progresso e chiedi all'agente di aggiornarlo dopo ogni iterazione.
5. Separa i ruoli: l'esecutore scrive, il verificatore in un contesto separato valuta il diff.
6. Imposta un limite complessivo e alla prima esecuzione controlla il risultato dopo un'ora, non al mattino.

Riepilogo

Un agente AI autonomo è affidabile esattamente quanto lo sono i suoi confini: una sandbox dove un errore non costa nulla, permessi minimi, un obiettivo verificabile dalla macchina, una memoria su disco, un valutatore separato e condizioni di arresto rigide con escalation verso una persona. Senza questi elementi, un'esecuzione lunga non è un risparmio di tempo, ma una pulizia rimandata. Come costruire un ciclo del genere su un progetto reale — dal program.md fino al valutatore indipendente — lo affrontiamo in pratica nel corso di harness engineering.