L’autrice parte da un ricordo concreto: una pipeline di quaranta step crollata al terzo perché mancava un valore di configurazione, trascinando giù anche i trenta step che con quel valore non c’entravano nulla. Non era un problema di prompt: il modello non era la parte che si era rotta. Il guasto stava nel control code, nella logica che avrebbe dovuto decidere cosa fare dopo un fallimento e che invece si è limitata a fermarsi. È il layer sopra il prompt, quello che in ambito AI engineering si chiama loop engineering.
Cosa è (e cosa non è) l’esperimento
Il loop engineering è un pattern di control flow: sostituire un unico grande prompt con un sistema che osserva lo stato, agisce e itera verso un obiettivo. Il termine è stato strutturato da Addy Osmani (Google) in un saggio del giugno 2026, sulla scia di Peter Steinberger e Boris Cherny di Anthropic, con un antenato tecnico nella “Ralph technique” di Geoffrey Huntley (luglio 2025). L’esperimento qui è volutamente più stretto: l’autrice non costruisce un nuovo agent framework e non fa benchmark di un LLM. Costruisce invece un piccolo controller goal-directed deterministico, in cui una semplice regola Python prende ogni decisione al posto di un modello. Zero chiamate LLM, zero dipendenze, zero varianza tra run con lo stesso seed. L’idea: se l’architettura offre un vantaggio reale rispetto a una pipeline lineare, quel vantaggio deve emergere anche quando l’intelligenza a ogni step è un semplice if.
La failure isolation, misurata
L’ambiente è un grafo diretto aciclico di task organizzati in rami indipendenti che confluiscono in poche task di integrazione finali. Ogni task riceve uno di sei comportamenti (dal caso pulito al blocco permanente), con circa un quarto dei task deliberatamente destinati a un vicolo cieco. La baseline è un esecutore lineare che percorre i task in ordine topologico e si ferma al primo ostacolo non risolvibile. Su 300 seed casuali, il controller ha completato in media il 47,7% dei task contro il 2,1% della baseline; ma la metrica che isola davvero la tesi è il numero di rami indipendenti completati: 3,3 su 10,3 per il controller contro 0,4 per la baseline. Il controller non è migliore perché risolve l’impossibile, ma perché si rifiuta di lasciare che un singolo task impossibile fermi tutti gli altri.
Il bug e la trasparenza
Vale la pena notare l’onestà metodologica: l’autrice racconta un bug che aveva quasi invalidato il benchmark. Il lookup delle risorse restituiva un booleano, dove False significava sia “non ancora pronto, richeck” sia “non esisterà mai”. La correzione è stata passare a un segnale a tre stati (RESOLVED, PENDING, MISSING), con test di regressione a conferma. La lezione pratica è esplicita: mai inferire lo stato dal comportamento, non affidarsi a euristiche di terminazione e isolare lo step di reasoning dietro un’interfaccia sostituibile, così che il control flow non sappia se a decidere è una regola, un LLM o un umano.
- La failure isolation è una proprietà architetturale misurabile, indipendente dalla qualità di reasoning del modello.
- Un controller goal-directed converte un fallimento catastrofico e totale in uno parziale e isolato, non rende il sistema “più intelligente”.
- Serve solo se hai rami di lavoro indipendenti: per pipeline puramente sequenziali o cortissime è overhead inutile.
Fonte: Context Engineering Isn’t Enough — A Loop Engineering Experiment With No LLM Inside the Loop — https://towardsdatascience.com/context-engineering-isnt-enough-a-loop-engineering-experiment-with-no-llm-inside-the-loop/
Hai qualcosa da aggiungere? Unisciti alla discussione.