# lushbinary-loop-engineering-ai-coding-agents-guide-2026-06-09

## Veille

Guida tecnica approfondita (blog dell'agenzia Lushbinary) sul **Loop Engineering**: la progettazione dei sistemi che guidano gli agenti di codifica in un loop, anziché guidarli manualmente tramite prompt. Copre la filiazione prompt → context → loop engineering, la tecnica Ralph (Geoffrey Huntley), i **cinque building block + memoria** di un loop, la loro implementazione in Claude Code e OpenAI Codex, la scrittura di condizioni di arresto verificabili, una scala di maturità dell'adozione e i rischi che peggiorano man mano che i loop diventano più sofisticati. Dominio: ingegneria del software agentica, agenti di codifica, harness/orchestrazione.

## Titre Article

Loop Engineering: The Guide for AI Agents

## Date

2026-06-09

## URL

https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/

## Keywords

Loop engineering, agenti di codifica, harness engineering, tecnica Ralph, condizioni di arresto, /goal, /loop, git worktree, skill, sub-agenti, maker-checker, MCP, memoria aziendale, Claude Code, OpenAI Codex, scala di maturità, debito di comprensione, verifica avversariale, FinOps token

## Authors

Lushbinary Team

## Ton

**Profilo**: guida pedagogica B2B in terza persona, registro istruttivo e strutturato (titoli, tabelle comparative, esempi di codice shell/markdown/TOML), livello tecnico elevato rivolto a ingegneri e tech lead. Articolo a duplice finalità: pedagogia sostanziale + gancio commerciale finale (sezione "Why Lushbinary" + consulenza gratuita).

**Stile**: esplicativo e didattico, con formule tipo slogan che condensano ogni idea ("Gli agenti dimenticano. I repository ricordano.", "La leva si è spostata, la complessità non è diminuita.", "Scrivi condizioni di arresto come contratti, non come desideri.", "Resti tu il tetto.", "Costruire loop restando ingegneri."). Metafore: il loop come "battito cardiaco" del sistema; le condizioni di arresto come "contratti" / "test di accettazione"; Ralph Wiggum (personaggio dei Simpson) per la semplicità deterministica. Autorevolezza rivendicata attraverso l'esperienza operativa (integrazioni IA in produzione, sanità/fintech/SaaS/e-commerce "fin dall'era GPT-4") e l'ancoraggio a fonti nominate (Addy Osmani, Peter Steinberger, Boris Cherny, Geoffrey Huntley). Nota finale di trasparenza: contenuto riformulato per conformità di licenza, capacità tratte dalla documentazione ufficiale Anthropic/OpenAI.

## Pense-betes

- **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*.
- **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).
- **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.
- **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).
- **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.
- **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.
- **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."*
- **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.
- **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).
- **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**.
- **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$."
- **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.
- **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.
- **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.
- **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é.
- **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.
- **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.
- **Sicurezza**: i loop autonomi con connettori che toccano la produzione richiedono guardrail, permessi e audit logging.

## RésuméDe400mots

Questa guida dell'agenzia Lushbinary teorizza il **loop engineering**: il passaggio dal *guidare manualmente* un agente di codifica tramite prompt alla *progettazione dei sistemi che lo guidano automaticamente*. Per due anni, estrarre valore da un agente ha seguito uno schema semplice (prompt, contesto, revisione, istruzione successiva) in cui lo sviluppatore manteneva il controllo a ogni turno. A partire da giugno 2026, la leva si sposta: lo sviluppatore smette di essere il principale autore di prompt e diventa il progettista di un **loop esterno** che scopre il lavoro, lo distribuisce, ne convalida i risultati, lo documenta e decide cosa viene dopo. Il termine, reso popolare da **Addy Osmani** (Google), si basa su Peter Steinberger (*"design loops that prompt your agents"*) e Boris Cherny (Claude Code/Anthropic: scrivere loop anziché guidare tramite prompt).

Il loop engineering è il **terzo livello** di uno stack (prompt → context → loop), ciascuno inglobante il precedente; la complessità non diminuisce, la leva si sposta verso la progettazione. La **tecnica Ralph** di Geoffrey Huntley (inizio 2026) ne è la convalida pre-terminologica: un loop `while`, lo stesso prompt, **contesto nuovo a ogni iterazione**, stato durevole su disco (`PLAN.md`, `STATUS.md`). Il loop engineering la trasforma in un prodotto.

Un loop funzionante richiede **cinque building block + memoria**: (1) **automazioni** pianificate (Codex Automations; Claude Code `/loop`, hook, `/goal`); (2) **worktree** git per agenti paralleli senza collisioni; (3) **skill** che catturano la conoscenza del progetto (`SKILL.md`); (4) **plugin/connettori** via MCP (portabili tra strumenti); (5) **sub-agenti** che separano il "maker" dal "checker"; (6) **memoria** al di fuori della finestra di contesto (markdown, board). Claude Code e OpenAI Codex integrano ormai questi building block con nomi diversi ma strutture identiche.

La primitiva `/goal` (Claude Code v2.1.139, 11 maggio 2026, Opus 4.8 di default; Codex CLI 0.128.0) mantiene il lavoro attivo finché una condizione **verificata da un modello separato** non è soddisfatta. Da qui l'imperativo: scrivere le condizioni di arresto **come contratti** (stato finale, prova, vincoli, limite di turni/budget). La separazione **maker-checker** (verificatore avversariale) è il cambiamento più potente. Una **scala di maturità** a 5 livelli (Manuale → Triage → Bozza → PR verificata → Auto-merge) guida un'adozione prudente, con l'essere umano che resta nel loop finché le evidenze non giustificano un passo indietro.

Tre rischi **peggiorano** con la sofisticazione: la verifica resta umana ("fatto" è un'affermazione, non una prova), il **debito di comprensione** accelera, e incombe la **resa cognitiva**. Conclusione: progettare i loop "come qualcuno che intende restare un ingegnere".

## GrapheDeConnaissance

- Addy Osmani —publie→ Loop Engineering (METHODOLOGIE, 0.95)
- Loop Engineering —s_inspire_de→ "you should be designing loops that prompt your agents" (CITATION, 0.92)
- Boris Cherny —affirme_que→ "mon focus est passé à écrire des boucles plutôt qu'à prompter directement" (AFFIRMATION, 0.9)
- Loop Engineering —remplace→ prompting manuel des agents (CONCEPT, 0.93)
- Loop Engineering —est_basé_sur→ Context Engineering (METHODOLOGIE, 0.88)
- Geoffrey Huntley —a_créé→ technique Ralph (METHODOLOGIE, 0.95)
- Technique Ralph —utilise→ réinitialisation du contexte à chaque itération (CONCEPT, 0.93)
- Loop Engineering —est_basé_sur→ technique Ralph (METHODOLOGIE, 0.9)
- Git worktrees —résout→ collisions de fichiers entre agents parallèles (CONCEPT, 0.94)
- Sub-agents maker-checker —permet→ séparation génération / vérification (CONCEPT, 0.93)
- /goal —fait_partie_de→ Claude Code (TECHNOLOGIE, 0.92)
- Claude Code —utilise→ Opus 4.8 (TECHNOLOGIE, 0.9)
- Skills —réduit→ coût de ré-explication du contexte projet (CONCEPT, 0.9)
- Mémoire externe —permet→ persistance de l'état entre runs (CONCEPT, 0.92)
- MCP —permet→ connecteurs portables (CONCEPT, 0.88)
- Loop Engineering —affirme_que→ "la dette de compréhension s'accélère avec des boucles plus rapides" (AFFIRMATION, 0.85)
- Conditions d'arrêt —recommande→ écriture comme des contrats (état, preuve, contraintes, budget) (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/it/fiches/lushbinary-loop-engineering-ai-coding-agents-guide-2026-06-09/