Loop Engineering: The Guide for AI Agents

Punti chiave

1. Definizione in una frase. il loop engineering costruisce sistemi che guidano gli agenti tramite prompt su una pianificazione e verso un obiettivo, invece di digitare prompt singoli. La leva si sposta dalla qualità di un prompt alla progettazione del sistema.
2. Due livelli di loop. il loop interno (percepire-ragionare-agire-osservare a ogni turno, già nativo negli agenti) contro il loop esterno che si progetta (pianificazione, helper, lavoro autoalimentato, persistenza su molti turni).
3. Filiazione a tre livelli. (ciascuno inglobante il precedente): Prompt Engineering (1 istruzione) → Context Engineering (contenuto della finestra) → Loop Engineering (sistema che decide cosa guidare tramite prompt, quando, e se il risultato è accettabile). Il prompt e il contesto restano essenziali — un cattivo prompt produce solo un cattivo lavoro più rapidamente.
4. Origine del termine. reso popolare da Addy Osmani (Google) nel giugno 2026, sulla base delle osservazioni di Peter Steinberger ("you should be designing loops that prompt your agents") e Boris Cherny (responsabile Claude Code presso Anthropic: il suo focus si è spostato verso scrivere loop anziché guidare direttamente tramite prompt).
5. Tecnica Ralph. (Geoffrey Huntley, inizio 2026, dal nome di Ralph Wiggum): eseguire l'agente in un semplice loop while, lo stesso prompt a ogni iterazione, rispetto a una specifica scritta, con contesto nuovo a ogni turno. L'innovazione non ovvia è il reset del contesto (evita il degrado dovuto a sessioni lunghe). L'intelligenza deriva da specifiche chiare + risultati verificabili + memoria esterna (PLAN.md, STATUS.md), non da esecuzioni eroiche.
6. Il loop engineering trasforma Ralph in un prodotto. il while diventa un'automazione pianificata, i reset diventano worktree/sub-agenti, il controllo "ALL TASKS DONE" diventa una condizione /goal verificata da un modello separato.
7. 5 building block + memoria. (1) Automazioni (trigger pianificati di scoperta/triage); (2) Worktree (agenti paralleli senza collisioni); (3) Skill (conoscenza del progetto documentata); (4) Plugin/connettori (MCP, accesso a strumenti reali); (5) Sub-agenti (separazione tra generazione e verifica); (6) Memoria (markdown, board Linear/GitHub — al di fuori della finestra di contesto). "Gli agenti dimenticano. I repository ricordano."
8. Claude Code e Codex integrano i 5 building block + memoria. con nomi diversi ma strutture identiche → progettare loop che sopravvivono a un cambio di strumento.
9. Automazioni. Codex (scheda Automations, esecuzioni in una inbox di Triage, le esecuzioni vuote si autoarchiviano); Claude Code (/loop + hook + integrazione GitHub Actions). Primitiva chiave in-sessione = /goal: mantiene il lavoro attivo finché la condizione specificata non è verificabilmente vera, un modello separato e più piccolo valuta il completamento a ogni turno (l'agente non si autovaluta).
10. Stato a metà 2026. /goal rilasciato in Claude Code v2.1.139 (11 maggio 2026), il ramo 2.1.x con Opus 4.8 come modello di default oltre a workflow dinamici che orchestrano ampie flotte di sub-agenti; Codex ha aggiunto /goal nella CLI 0.128.0. I praticanti riportano agenti che lavorano senza supervisione per decine di ore → le condizioni di arresto diventano l'elemento più critico.
11. Scrivere le condizioni di arresto come contratti. stato finale + prova + vincoli + limite di turni/budget. Es.: "copertura di src/billing ≥ 90%; npm test esce con codice 0; nessuna API pubblica modificata; arresto dopo 25 turni o 5$."
12. Tre pratiche per loop affidabili. (team Claude Code): preservare gli errori (affinché il loop impari invece di ripetere), integrare la verifica fin dall'inizio, trattare i test falliti / la CI rossa come segnali di onestà. Un loop senza prova di fallimento crede sempre di aver avuto successo.
13. Worktree. = isolamento git reale (directory separate su branch distinti, cronologia condivisa). Ma "Resti tu il tetto": è la capacità di revisione umana, non il numero di worktree, a determinare quanti agenti si eseguono realmente in parallelo.
14. Sub-agenti maker-checker. = il cambiamento strutturale più potente: un agente verificatore avversariale (modello robusto, ragionamento elevato, istruito a respingere tutto ciò che non è dimostrato) come filtro prima della revisione umana. I modelli che valutano il proprio lavoro sono troppo indulgenti.
15. Scala di maturità (Livelli 0→4). 0 Manuale → 1 Triage (risultati in markdown, nessun codice) → 2 Bozza (correzioni su branch isolati) → 3 PR verificata (sub-agente verificatore come filtro) → 4 Auto-merge (categorie a basso rischio su CI verde). Salire di livello solo se quello attuale produce un lavoro che si sarebbe fatto comunque da sé.
16. 3 rischi che peggiorano (non diminuiscono). la verifica resta di propria responsabilità ("fatto" è un'affermazione, non una prova); il debito di comprensione accelera (il codice viene rilasciato più velocemente di quanto venga compreso); la resa cognitiva (accettare gli output senza giudizio) — due persone che costruiscono lo stesso loop ottengono risultati opposti a seconda che lo usino per far progredire un lavoro che comprendono o per evitare di comprenderlo.
17. Attenzione ai token. i loop pianificati + i modelli verificatori post-turno consumano rapidamente token. Iniziare con cadenze lente e condizioni rigorose, monitorare i costi per diversi giorni, scalare solo dopo la prova di un lavoro utile effettivamente integrato.
18. Sicurezza. i loop autonomi con connettori che toccano la produzione richiedono guardrail, permessi e audit logging.