Anthropic paga i propri ingegneri 80.000 dollari al mese. Quegli ingegneri ora integrano 8 volte più codice al giorno rispetto a un anno fa. Non perché il modello sia diventato più intelligente, ma perché hanno smesso di inviare prompt a Claude e hanno iniziato a costruire sistemi che lo fanno al posto loro.
Brian Cherny, responsabile di Claude Code presso Anthropic, afferma: "Non invio più prompt a Claude. Ho dei cicli in esecuzione che interrogano Claude e decidono cosa fare. Il mio lavoro è scrivere cicli".
La maggior parte degli sviluppatori legge queste parole senza avere idea di cosa significhi nella pratica. Alla fine di questo articolo lo saprai, e avrai tutto il necessario per costruirne uno questo fine settimana.
Cos'è davvero un ciclo
Un prompt è una singola istruzione. Un ciclo è un obiettivo verso cui l'IA continua a lavorare finché non lo raggiunge.
La differenza sta in chi è al comando. Con un prompt, spingi Claude attraverso ogni passaggio manualmente. Con un ciclo, definisci l'obiettivo una volta sola e il sistema esegue l'intero processo autonomamente: trova il lavoro, lo esegue, verifica il risultato e decide cosa fare dopo. Tutto senza che tu debba essere presente.
1Prompt | tu scrivi, Claude risponde, tu scrivi di nuovo2Ciclo | il sistema trova il lavoro, Claude esegue,3 | il sistema verifica il risultato, ripete finché non è fatto
Ogni vero ciclo ha cinque fasi:
1Scoperta | trovare cosa deve essere fatto2Pianificazione | decidere come farlo3Esecuzione | svolgere il lavoro4Verifica | controllare rispetto all'obiettivo5Iterazione | non è finito? reinserire il risultato e ricominciare
Tre di queste fasi svolgono tutto il lavoro vero e proprio.
La verifica è il cuore. Senza un controllo reale sul risultato, non hai un ciclo: hai solo un agente che concorda con se stesso ripetutamente. Il controllo deve essere oggettivo. Un test che passa o fallisce. Una build che compila o meno. Un linter che restituisce zero o un valore diverso da zero. Non un secondo agente a cui viene chiesto di "rivedere". Due ottimisti che concordano non costituiscono una verifica.
Lo stato è ciò che permette al ciclo di imparare. A ogni passaggio, l'IA deve ricordare cosa ha già tentato, altrimenti ripeterà lo stesso errore all'infinito. Un vero ciclo mantiene un registro al di fuori della conversazione: cosa è stato fatto, cosa ha fallito, cosa c'è dopo. L'agente dimentica tra una sessione e l'altra. Il file no.
Una condizione di arresto è ciò che mantiene il sistema sano. Un ciclo senza uscita continua a girare finché non ha successo, si rompe o esaurisce il tuo budget. Ogni ciclo serio ha due modi per fermarsi: il successo e un limite rigido. Senza questo, hai costruito una macchina che ti addebita costi in silenzio.
Il test delle 4 condizioni prima di costruire qualsiasi cosa
Un ciclo ripaga il suo costo solo quando tutte queste quattro condizioni sono vere. Se ne manca una, mantienilo come prompt manuale.
1Condizione 1 | l'attività si ripete almeno settimanalmente2 | meno di una volta a settimana - il costo di setup non si ripaga mai34Condizione 2 | qualcosa può rifiutare automaticamente l'output errato5 | un test, una build, un linter, un controllo dei tipi6 | senza un filtro automatico, torneresti a rivedere ogni diff78Condizione 3 | l'agente può svolgere il lavoro dall'inizio alla fine9 | senza restituirti metà del lavoro a metà dell'opera1011Condizione 4 | il "fatto" è oggettivo, non una questione di opinioni12 | se la qualità è una questione di gusto, un essere umano vince ancora
Buoni primi cicli:
1Triage dei fallimenti CI | ogni notte, classifica i fallimenti, abbozza le correzioni2Aggiornamento dipendenze | settimanale, scansiona gli aggiornamenti, apre le PR3Passaggi di lint-and-fix | a ogni PR, applica correzioni di stile automaticamente4Bozze da issue a PR | su codebase con una solida copertura di test
Cattivi primi cicli - tieni un essere umano al comando:
1Riscritture architetturali | questione di giudizio, il ciclo devierà2Codice di autenticazione o pagamenti | errori irreversibili troppo costosi3Deploy in produzione | necessita di un filtro di approvazione umana4Lavoro di prodotto vago | il "fatto" non è oggettivo
I cinque blocchi di costruzione
Ogni ciclo funzionante è assemblato da cinque parti. Claude Code le include tutte e cinque.
1 - L'automazione (il battito cardiaco)
È ciò che rende un ciclo un vero ciclo e non solo un'esecuzione singola. Un trigger si attiva secondo una pianificazione o un evento, consegna l'attività a Claude e riporta i risultati senza che tu debba controllare.
1/loop | riesegue un prompt a intervalli regolari2/goal | continua finché una condizione che hai scritto non è vera3hooks | attivano comandi in punti specifici del ciclo di vita dell'agente4cron | esegue dopo che hai chiuso il laptop tramite GitHub Actions
Il più importante è /goal. Un piccolo modello separato controlla se la condizione è soddisfatta, così l'agente che ha scritto il codice non è lo stesso che lo valuta.
1/loop 30m /goal "Tutti i test in test/auth passano e il lint è pulito."2Scansiona src/auth per errori, abbozza correzioni, apri PR quando l'obiettivo è raggiunto.
2 - Competenze (scrivi la conoscenza del progetto una volta sola)
Una competenza è il modo in cui smetti di rispiegare lo stesso contesto del progetto a ogni sessione. Un file SKILL.md contiene le istruzioni, le convenzioni e le regole che il ciclo legge a ogni esecuzione.
Senza competenze, il ciclo ricalcola l'intero progetto da zero a ogni ciclo. Con le competenze, l'intento si accumula: le convenzioni, i passaggi di build, le cose che sono andate male in passato, scritte una volta, lette per sempre.
1skills/2 ci-triage.md - regole di classificazione, pattern di correzione, criteri di escalation3 frontend.md - Tailwind, Next.js, SEO, regole di accessibilità4 security.md - pattern di autenticazione, validazione input, lista delle cose da non toccare5 deps.md - regole di aggiornamento, controlli di compatibilità, pattern di rollback
L'automazione richiama la competenza per nome. Il lavoro ricorrente rimane manutenibile invece di marcire all'interno di una pianificazione che nessuno aggiorna.
3 - Sotto-agenti (tieni il creatore lontano dal controllore)
La cosa strutturale più utile in qualsiasi ciclo. Separa l'agente che scrive dall'agente che controlla.
Il modello che ha scritto il codice è troppo generoso nel valutare il proprio lavoro. Un secondo agente con istruzioni diverse, e talvolta un modello più potente, coglie ciò che il primo ha giustificato a se stesso.
1Agente creatore | modello veloce ed economico - esplora, implementa, abbozza2Agente controllore | modello potente, alto impegno - rivede, verifica, rifiuta
1.claude/agents/2 explorer.md | sola lettura, modello veloce, trova cosa deve essere fatto3 implementer.md | scrive la correzione, esegue i test4 reviewer.md | audit di sicurezza, qualità del codice, filtro oggettivo
Un modello. Tre specialisti. Il ciclo gira mentre non stai guardando e il verificatore è l'unico motivo per cui puoi effettivamente allontanarti.
4 - Connettori (affinché agisca, non suggerisca)
La differenza tra un ciclo che dice "ecco la correzione" e un ciclo che apre la PR, collega il ticket e invia un ping su Slack una volta che la CI è verde.
1GitHub | legge repository, crea branch, apre PR, reagisce ai webhook2Linear | aggiorna ticket, collega PR, chiude elementi quando la verifica passa3Slack | pubblica risultati di triage, avvisa umani in caso di escalation4Sentry | indaga su avvisi live, abbozza correzioni per quelli ad alta frequenza
Senza connettori, il ciclo descrive cosa farebbe. Con i connettori, lo fa.
5 - Il file di stato (l'agente dimentica. Il file no.)
Il pezzo che sembra troppo stupido per essere importante, ma che è la spina dorsale di ogni ciclo funzionante. Un file markdown al di fuori della conversazione che registra cosa è fatto, cosa ha fallito e cosa c'è dopo.
1# Stato del ciclo - ci-triage23## Ultima esecuzione42026-06-09 03:30 UTC - 7 fallimenti classificati, 3 correzioni abbozzate, 4 escalation56## In corso7- claude/fix-auth-token-refresh - test passati localmente, in attesa di CI89## Completato oggi10- claude/bump-axios-1.7.4 - integrato, CI verde1112## Escalation agli umani13- src/billing/refund.ts - test falliti in 3 modi, causa principale non chiara1415## Lezioni apprese16- 2026-06-08: PowerShell riscontra problemi TLS su runner Windows. Usa bash.17- 2026-06-07: tests/e2e/checkout richiede il segreto webhook di Stripe. Salta se mancante.
L'esecuzione di domani legge questo file e riprende. Senza di esso, ogni esecuzione riparte da zero.
Com'è fatto un vero ciclo
Triage dei fallimenti CI: uno dei migliori primi cicli perché la verifica è automatica e la posta in gioco in caso di output errato è bassa.
1Trigger | ogni notte alle 3:00 o su evento di fallimento CI2Competenza | ci-triage.md3Lettura stato| STATE.md - cosa ha fallito ieri, cosa è stato corretto
Il ciclo esegue:
1Passaggio 1 | legge i fallimenti CI da GitHub tramite connettore2Passaggio 2 | classifica ciascuno: env / flake / bug / dipendenza / infra3Passaggio 3 | per ogni fallimento correggibile - apre worktree, invia agente implementatore4Passaggio 4 | agente revisore controlla la correzione rispetto a test e regole di sicurezza5Passaggio 5 | filtro superato - apre PR e collega ticket Linear6Passaggio 6 | filtro fallito - invia escalation alla casella di posta di triage umana7Passaggio 7 | aggiorna STATE.md8Passaggio 8 | pubblica il riepilogo notturno su Slack
Al mattino ti svegli con un messaggio su Slack, una casella di posta di triage con solo i problemi difficili e una serie di PR che hanno già superato la revisione automatica. Non hai inviato prompt per nemmeno un passaggio.
Il ciclo che si accumula in tutta l'azienda
La versione più potente non è un singolo ciclo. Sono cicli multipli che scrivono su un sistema di artefatti condiviso, così imparano l'uno dall'altro.
In SuperDesign, i loro cicli coprono supporto, SEO, crescita del prodotto e annunci. Ognuno ha il proprio trigger e flusso di lavoro. Ma tutti scrivono nello stesso archivio di segnali condiviso.
Il ciclo di supporto nota cinque utenti che chiedono come esportare qualcosa. Crea un segnale:
1tipo: segnale2titolo: L'esportazione è troppo difficile da trovare3frequenza: 54categoria: attrito5tag: [feedback, prezzi, conversione]
Il ciclo SEO nota una pagina con traffico forte ma scarsa conversione. Crea un altro segnale. Il ciclo di crescita del prodotto legge entrambi i segnali insieme alle analisi e identifica che l'attrito nell'esportazione è maggiore di quanto suggerito dai dati grezzi, perché ora due fonti indipendenti confermano lo stesso problema. Il ciclo degli annunci trova una lacuna nelle parole chiave e la inserisce direttamente nel ciclo SEO.
1Ciclo supporto | trova attrito, scrive segnale2Ciclo SEO | trova lacuna nei contenuti, scrive segnale3Ciclo prodotto | legge entrambi i segnali, identifica la priorità4Ciclo annunci | trova lacuna nelle parole chiave, alimenta il ciclo SEO
Nessuno di questi cicli è un'automazione isolata. Operano da una base di conoscenza condivisa di ciò che l'azienda sta imparando. Ogni ciclo rende ogni altro ciclo più intelligente. Questo è l'effetto composto.
I fallimenti di cui nessuno ti avverte
Il ciclo Ralph Winchester. Un agente destinato a segnalare il completamento solo quando finito, lo segnala in anticipo. Il ciclo esce su un lavoro fatto a metà e continua a girare e addebitare costi mentre non produce nulla. Soluzione: un filtro rigido che può far fallire oggettivamente il lavoro, non un morbido "mi sembra a posto".
Deriva dell'obiettivo durante sessioni lunghe. I vincoli scompaiono al 47° turno mentre il contesto si riassume da solo. Soluzione: un file AGENTS.md permanente che l'agente rilegge all'inizio di ogni esecuzione.
Debito di comprensione. Più velocemente il ciclo rilascia codice che non hai scritto, maggiore è il divario tra ciò che esiste e ciò che capisci. Il conto che fa male non è quello dei token. È il giorno in cui esegui il debug di un sistema che nessuno nel team ha mai letto. Soluzione: leggi ogni diff che il ciclo apre.
Resa cognitiva. La spinta a smettere di formarsi un'opinione e accettare tutto ciò che il ciclo restituisce. Progettare il ciclo è la cura quando lo fai con giudizio, ed è l'accelerante quando lo fai per evitare di pensare. Stessa azione, risultato opposto.
Costi dei token che si accumulano. Ogni iterazione del ciclo rilegge l'intero contesto e la mole cresce a ogni passaggio. Traccia il costo per modifica accettata. Sotto un tasso di accettazione del 50%, il ciclo costa più di quanto risparmia.
L'ordine di costruzione che funziona davvero
Tutti coloro che rilasciano cicli che sopravvivono in produzione lo fanno allo stesso modo:
1Passaggio 1 | rendi affidabile UNA esecuzione manuale per prima2Passaggio 2 | trasformala in una competenza - salva le istruzioni in SKILL.md3Passaggio 3 | avvolgi la competenza in un ciclo - aggiungi il filtro e la condizione di arresto4Passaggio 4 | POI pianificala
Pianificare qualcosa che non hai reso affidabile a mano è esattamente il modo in cui i cicli esplodono mentre dormi. Dimostralo una volta. Rendilo solido. Poi automatizzalo.
La metrica che conta non è quanti token sono stati spesi o quante attività sono state tentate. È il costo per modifica accettata. Se il ciclo ti dà dieci risultati e ne rifiuti sei, stai facendo il lavoro di revisione che avrebbe dovuto risparmiarti.
Il cambiamento che è già avvenuto
Nel 2024 la leva era nel prompt. Miglior prompt, miglior output, miglior sviluppatore. Nel 2026 la leva è un piano più in alto: il sistema che decide su cosa lavora Claude, quando, con quale filtro e quale stato sopravvive tra le esecuzioni.
Gli ingegneri di Anthropic integrano 8 volte più codice al giorno non perché hanno trovato un modo migliore per fare domande a Claude. Perché hanno smesso di fare domande e hanno iniziato a costruire sistemi che fanno domande a Claude per loro conto, continuamente, durante la notte, mentre dormono.
Il ciclo non rende il lavoro più facile. Sposta dove avviene il lavoro. Dallo scrivere prompt al progettare il sistema che scrive prompt. Dal tenere lo strumento al costruire la fabbrica.
La maggior parte degli sviluppatori continuerà a inviare prompt a mano e si chiederà perché il divario continua ad allargarsi. Alcuni passeranno un fine settimana a costruire il loro primo ciclo (un'automazione, una competenza, un file di stato, un filtro) e non torneranno più indietro.
