Loop Claude Code: 4 tipi per automazione ricorrente

Ogni prompt che scrivi in loop Claude Code è già un ciclo: leggi codice, modifichi, testi, ricevi il risultato. Lo fai decine di volte al giorno senza pensarci. La novità del 2026 è che questi cicli ora si possono programmare, parametrizzare e far girare senza supervisione costante. Anthropic ha formalizzato il concetto in quattro tipi distinti di loop, ognuno pensato per uno scenario diverso. Questa guida li analizza tutti, con una matrice decisionale per scegliere quello giusto.

La domanda operativa non è “devo usare i loop?”, perché li usi già. La domanda è: quale tipo di loop ti serve, e come eviti di bruciare token su un’automazione mal calibrata?

I 4 tipi di loop in Claude Code: panoramica tecnica

Anthropic distingue quattro categorie, ordinate per livello crescente di autonomia.

• Turn-based: attivato dal tuo prompt, Claude decide quando ha finito. Ogni interazione manuale è un loop di questo tipo.
• Goal-based: attivato dal tuo prompt con /goal, ma con un criterio di uscita verificabile. Un modello evaluator controlla la condizione a ogni iterazione.
• Time-based: esecuzione a intervalli con /loop (locale) o /schedule (cloud). Non serve intervento umano tra un’iterazione e l’altra.
• Proattivo: combinazione di /schedule, /goal e modalità auto. Nessun intervento umano in tempo reale, Claude agisce su eventi e schedule in autonomia.

Più autonomia significa più token consumati e più rischio di azioni non volute. La scelta del tipo giusto è un atto di ingegneria, non di entusiasmo.

Turn-based e goal-based: dal prompt singolo ai criteri verificabili

Il turn-based loop è il comportamento predefinito di Claude Code. Chiedi di leggere un file, modificarlo e testare il risultato: Claude itera finché non ritiene il task completato. Ideale per refactoring, bug fix, generazione di componenti. Il limite è che serve un umano a ogni giro.

Il salto arriva con /goal. Invece di lasciare a Claude il giudizio su “ho finito?”, definisci una condizione misurabile. Esempio: /goal porta il Lighthouse score della homepage a 90, fermati dopo 5 tentativi. Un modello evaluator separato verifica la condizione a ogni iterazione. Due salvaguardie in una riga di comando. Questo pattern funziona per qualsiasi target numerico o booleano: coverage dei test, zero errori TypeScript, dimensione del bundle. Funziona meno bene per obiettivi soggettivi, dove l’evaluator non ha un criterio oggettivo.

Time-based loop: /loop locale e /schedule cloud

Qui si passa all’automazione ricorrente. /loop 5m controlla la mia PR, rispondi ai commenti, correggi la CI esegue il task ogni 5 minuti nella sessione corrente. Chiudi il terminale, il loop si interrompe. /schedule fa la stessa cosa nelle routine cloud di Anthropic, sopravvivendo alla sessione. Per monitoraggi notturni di pipeline CI, /schedule è la scelta obbligata. La differenza pratica è una sola: persistenza. Il costo in token per iterazione è identico.

Loop proattivi: Claude Code in autopilota

Il quarto tipo combina /schedule, /goal e modalità auto per creare un agente che monitora e agisce senza intervento umano. Esempio: /schedule every hour: controlla #project-feedback per bug report. Ogni ora Claude legge il canale, classifica le segnalazioni, e può aprire issue o proporre fix. Il paragone con n8n o Zapier è inevitabile, ma la differenza è che Claude ragiona sul contesto: può valutare un messaggio ambiguo e decidere se è un bug o una feature request. Un workflow n8n esegue logica deterministica, il loop proattivo esegue logica adattiva. Per chi costruisce sistemi AI aziendali, questa distinzione cambia le automazioni possibili.

Matrice decisionale: quale loop per quale task

Non basta sapere che esistono 4 tipi di loop: serve sapere quando usare quale.

Ottimizzare i loop: skill, qualità e consumo token

Un loop mal configurato è una macchina brucia-token. Tre pratiche riducono il rischio.

Definisci criteri di stop chiari: “migliora il codice” è un obiettivo senza uscita. “Riduci il bundle sotto 200KB” è un obiettivo con uscita. I goal-based loop rendono questo obbligo strutturale, non opzionale.

Calibra la frequenza sulla velocità di cambiamento: se una PR riceve commenti ogni 2 ore, un /loop 5m esegue 24 iterazioni inutili per ogni iterazione utile. Un /loop 1h copre lo stesso scenario consumando un decimo dei token. Pilota sempre un workflow prima di lasciarlo girare tutta la notte.

Usa skill per la verifica: i file SKILL.md codificano i criteri di qualità che Claude verifica a ogni iterazione. Una skill formalizza cosa controllare in modo deterministico, riducendo token sprecati su interpretazioni diverse del prompt. Il comando /code-review integra questa logica per il controllo qualità del codice prodotto dai loop.

Quando i loop non servono (e cosa usare al loro posto)

Non tutto va messo in un loop. Un task mensile non giustifica un /schedule. Un’ottimizzazione con un solo tentativo ragionevole non ha bisogno di /goal. Per workflow deterministici senza ragionamento adattivo, strumenti come n8n restano più efficienti. Per task che richiedono coordinazione tra più agenti, i team di agenti Claude sono un’architettura più adatta. E per chi sta integrando questi pattern nella formazione del proprio team, il consiglio è partire dai turn-based e goal-based prima di passare ai proattivi.

I loop di Claude Code sono un modello mentale per pensare all’automazione in modo progressivo: da “faccio tutto io” a “definisco l’obiettivo e controllo il risultato” a “l’agente monitora e agisce per conto mio”. La domanda che vale la pena farsi prima di configurare qualsiasi loop non è “posso automatizzarlo?”, ma “il valore dell’automazione giustifica il costo di mantenerla?” La risposta, sorprendentemente spesso, è che il loop più semplice è quello giusto.