Non faccio più prompt a Claude. Ho dei loop in esecuzione che fanno prompt a Claude e decidono cosa fare. Il mio lavoro è scrivere loop.
- Boris Cherny, creatore e capo di Claude Code in Anthropic.
Per circa due anni, l'abilità che tutti inseguivano era l'ingegneria dei prompt. Scrivere un buon prompt, condividere abbastanza contesto, leggere l'output, scrivere il prompt successivo. Tenevi l'agente come uno strumento, un turno alla volta.
Quell'epoca sta finendo silenziosamente.
A metà del 2026, tre voci hanno convergito sulla stessa idea a distanza di pochi giorni l'una dall'altra. Boris Cherny (Claude Code) ha detto che il suo lavoro ora è scrivere loop. Peter Steinberger (creatore di OpenClaw) ha detto a milioni di sviluppatori: "Non dovreste più fare prompt agli agenti di codifica. Dovreste progettare loop che fanno prompt ai vostri agenti." E Addy Osmani (Google) ha dato un nome al pattern in un post ampiamente condiviso: Loop Engineering. Questo articolo spiega cosa sia realmente il loop engineering, i problemi che risolve, come li risolve, una demo di codice funzionante che puoi eseguire oggi, e i compromessi onesti che nessuno menziona nei post di hype.
Cos'è il Loop Engineering?
Il loop engineering consiste nel sostituire te stesso come persona che fa prompt all'agente. Progetti un sistema che si occupa del prompting al posto tuo.
Un loop è un obiettivo ricorsivo: definisci uno scopo e una condizione di arresto verificabile, e l'AI itera, scopre il lavoro, lo implementa, lo verifica, registra i progressi finché la condizione non è vera. Tu non sei più nel loop. Sei sopra di esso.
Pensa alla gerarchia in questo modo:
- Ingegneria dei prompt: scrivi una buona istruzione.
- Ingegneria del contesto: assembli le informazioni giuste attorno all'istruzione.
- Ingegneria dell'harness dell'agente: costruisci l'ambiente in cui un agente opera.
- Loop engineering: costruisci il sistema che esegue l'harness su un timer, genera aiutanti, verifica il suo lavoro.
Il vecchio flusso di lavoro: scrivi prompt → leggi output → scrivi prossimo prompt (tu sei il loop).
Il nuovo flusso di lavoro: progetta il loop una volta → il loop scopre il lavoro → il loop assegna agenti → il loop verifica → il loop registra lo stato → ripeti (tu revisioni e guidi).
I Problemi Risolti dal Loop Engineering
Problema 1: Tu sei il collo di bottiglia
Nel prompting manuale, non succede nulla finché non scrivi. Ogni turno aspetta un umano. Gli agenti nel 2026 possono funzionare per ore in modo autonomo; i modelli di classe Claude Opus hanno funzionato senza supervisione per quasi cinque ore su compiti difficili, ma una chat guidata da un umano li limita alla tua velocità di digitazione e alla tua capacità di attenzione. L'agente è inattivo per il 95% del tempo, in attesa di te.
Problema 2: Gli agenti dimenticano tutto tra una sessione e l'altra
Ogni sessione parte da zero. Il modello re-deriva le convenzioni del tuo progetto, i passaggi di build e le lezioni apprese con fatica da zero, o peggio, riempie i vuoti con supposizioni sicure. Questo è ciò che Osmani chiama debito di intenti: intenti non dichiarati che vengono ripagati (o re-indovinati) a ogni singola esecuzione.
Problema 3: L'agente valuta il suo stesso compito
Un agente che ha scritto il codice è fin troppo generoso quando lo revisiona. "È fatto" è un'affermazione, non una prova. Senza una verifica indipendente, le esecuzioni autonome accumulano errori invece di correggerli.
Problema 4: Gli agenti paralleli collidono
Nel momento in cui esegui più di un agente su un repository, iniziano a sovrascrivere i file degli altri: lo stesso disastro di due ingegneri che fanno commit sulle stesse righe senza parlarsi.
Problema 5: Il lavoro ricorrente non viene mai automatizzato
Triage degli errori CI, aggiornamenti delle dipendenze, caccia ai test instabili, etichettatura delle issue, pulizia quotidiana dei bug: questo lavoro è noioso, infinito e perfettamente adatto agli agenti. Ma nessuno fa prompt a un agente per farlo ogni mattina, perché tu dovresti presentarti ogni mattina per fare il prompting.
Come il Loop Engineering Li Risolve: I Sei Mattoni Fondamentali
Un loop che funziona davvero senza supervisione non è un lungo prompt. È un piccolo sistema con cinque capacità più una memoria. Notevolmente, sia Claude Code che OpenAI Codex ora includono tutti e sei nativamente: la forma del loop è diventata indipendente dallo strumento.
- Automazioni : il battito cardiaco
Esecuzioni programmate che fanno scoperta e triage da sole. Questo risolve il Problema 5.
- Claude Code: /loop riesegue un prompt a cadenza (da intervalli di un minuto a finestre multi-giornaliere), attività pianificate con cron, Routines per automazioni pianificate sul cloud, hook del ciclo di vita o GitHub Actions per esecuzioni che sopravvivono alla chiusura del tuo laptop.
- Codex: la scheda Automations: scegli un progetto, un prompt, una cadenza; i risultati finiscono in una casella di posta Triage, le esecuzioni vuote si archiviano da sole.
Il primitivo killer in-sessione è /goal: continua a lavorare tra un turno e l'altro finché una condizione che hai scritto non è verificabilmente vera: "tutti i test in test/auth passano e lint è pulito" e vai via.
- Worktree : isolamento per il parallelismo
I git worktree danno a ogni agente la propria directory di lavoro sul proprio branch, condividendo la cronologia del repository. Le modifiche letteralmente non possono collidere. Questo risolve il Problema 4.
- Claude Code: git worktree, il flag --worktree, o isolation: worktree su un subagente in modo che ogni aiutante ottenga un checkout fresco e auto-pulente.
- Codex: worktree integrato per thread.
Gli utenti esperti riferiscono di eseguire 10-15 agenti paralleli in questo modo.
- Skills : conoscenza del progetto codificata
Una skill è una cartella con un SKILL.md: le tue convenzioni, i passaggi di build e "non lo facciamo così per via di quell'incidente" scritti una volta, letti dall'agente a ogni esecuzione. Questo risolve il Problema 2. Senza skill, il loop re-deriva il tuo progetto da zero a ogni ciclo. Con esse, accumula conoscenza.
- Plugin e Connettori (MCP) : mani su strumenti reali
Un loop che vede solo il filesystem è un loop piccolo. I connettori MCP gli permettono di leggere il tuo issue tracker, interrogare un database, aprire la PR, aggiornare il ticket Linear e pingare Slack quando la CI diventa verde. Questa è la differenza tra un agente che dice "ecco la correzione" e un loop che consegna la correzione.
- Sub-agenti : separa il creatore dal verificatore
L'idea strutturale più importante dell'intero pattern. Un agente (o modello) scrive; un diverso agente con istruzioni diverse verifica. Questo risolve il Problema 3. /goal di Claude Code lo integra: un modello separato valuta se la condizione di arresto è soddisfatta, così il lavoratore non valuta mai il suo stesso compito.
- Claude Code: subagenti in .claude/agents/, team di agenti.
- Codex: subagenti come TOML in .codex/agents/ ad esempio, un modello forte con alto sforzo di ragionamento come revisore di sicurezza, un modello veloce e di sola lettura come esploratore.
- Stato : la spina dorsale della memoria
Un file markdown, un registro di avanzamento o una bacheca Linear: qualsiasi cosa viva fuori dalla conversazione e registri cosa è stato fatto e cosa c'è dopo. Sembra troppo stupido per essere importante. È l'unico trucco da cui dipende ogni agente a lunga esecuzione: il modello dimentica tra un'esecuzione e l'altra; il repository no. Questo risolve anche il Problema 2 a livello di attività, ed è ciò che permette all'esecuzione di domani di riprendere esattamente da dove si è fermata quella di oggi. Insieme alle automazioni, dissolve il Problema 1: il loop funziona mentre dormi.
L'Aspetto di un Loop Reale
Ecco la forma di riferimento (adattata dal loop quotidiano dello stesso Osmani):
- Un'automazione si attiva sul repository. Il suo prompt chiama una skill di triage che legge gli errori CI di ieri, le issue aperte e i commit recenti, e scrive i risultati in STATE.md.
- Per ogni risultato che vale la pena perseguire, il loop apre un worktree isolato e invia un sub-agente creatore a redigere la correzione.
- Un sub-agente verificatore revisiona la bozza rispetto alle skill del progetto e ai test esistenti.
- I connettori aprono la PR, collegano il ticket e pubblicano su Slack.
- Tutto ciò che il loop non può gestire finisce in una casella di posta di triage per te.
- STATE.md registra cosa è stato tentato, cosa è passato e cosa è ancora aperto. L'esecuzione di domani riprende da lì.
Fonti e approfondimenti: Addy Osmani, "Loop Engineering" (addyosmani.com); La copertura di The New Stack sul loop engineering; Il fireside chat di Boris Cherny alla conferenza Scale di Meta e l'intervista a CNBC; Documentazione di Claude Code su Routines (code.claude.com/docs/en/routines); Documentazione di OpenAI Codex Automations.
Se costruisci un loop da questo articolo, mi piacerebbe vederlo!! Rispondi con cosa hai automatizzato per primo.
