Loop Engineering: l’Evoluzione dei Prompt

Loop Engineering: l’Evoluzione dei Prompt

Perché nel 2026 i migliori AI Engineer hanno smesso di scrivere prompt e hanno iniziato a progettare sistemi che li scrivono al posto loro

Per due anni, l’unica competenza che contava nel lavorare con l’intelligenza artificiale era scrivere un buon prompt: istruzione, risposta, correzione, di nuovo istruzione. Poi, in meno di 48 ore a giugno 2026, tre figure di riferimento del settore, uno sviluppatore indipendente, il responsabile di Claude Code in Anthropic e un ingegnere di Google. hanno detto praticamente la stessa cosa nello stesso momento: quell’epoca è finita. Non si scrivono più prompt agli agenti, si progettano i sistemi che li scrivono al posto nostro. Questo si chiama Loop Engineering, ed è l’argomento di questo articolo: cos’è, come funziona, quali sono le sue sei componenti e perché ogni team IT dovrebbe iniziare a prendersela sul serio. Continuate a leggere l’articolo “Loop Engineering: l’Evoluzione dei Prompt“

Indice dei contenuti – Loop Engineering: l’Evoluzione dei Prompt

1. Cos’è il Loop Engineering e perché se ne parla proprio ora

2. Dal prompt al loop: tre passaggi che hanno cambiato le regole

3. Le sei componenti di un loop, spiegate senza fuffa

4. Esempio pratico: un loop che lavora mentre il team dorme

5. Claude Code vs Codex: stessa idea, strumenti diversi

6. Esempio pratico: triage automatico dei bug per un piccolo team IT

7. Quello che il loop non farà mai al posto tuo

8. Conclusioni: la velocità è la competenza che conta davvero

1. Cos’è il Loop Engineering e perché se ne parla proprio ora

Iniziamo subito a parlare di Loop Engineering: l’Evoluzione dei Prompt. Immagina di essere un giovane AI Engineer alle prime armi. Fino a poco tempo fa la tua giornata tipo era questa: apri la chat con l’agente, scrivi un’istruzione dettagliata, leggi la risposta, correggi qualcosa che non va, rilanci. Un turno alla volta, con te sempre al centro del processo. Questo è il prompt engineering, ed è ancora una competenza fondamentale.

Il Loop Engineering nasce da un’osservazione semplice: se un agente è ormai capace di lavorare per ore in autonomia, correggendo i propri errori, perché deve essere sempre un umano a dirgli cosa fare passo dopo passo? La risposta è che non deve più esserlo. Il Loop Engineering è la pratica di costruire un piccolo sistema che trova il lavoro da fare, lo assegna, lo verifica, registra cosa è stato completato e decide il passo successivo — mentre tu, invece di scrivere prompt uno alla volta, disegni una sola volta il ciclo che li scrive al posto tuo.

Il nome è stato coniato ufficialmente il 7 giugno 2026 da Addy Osmani, direttore dell’area Cloud AI di Google, in un saggio pubblicato sul suo blog personale e ripreso il 22 giugno da O’Reilly Radar. Il giorno prima, lo sviluppatore Peter Steinberger aveva scritto una frase diventata virale nella community tecnica: gli sviluppatori non dovrebbero più scrivere prompt agli agenti di coding, ma progettare i loop che lo fanno per loro. Boris Cherny, a capo di Claude Code in Anthropic, ha confermato la stessa idea dal punto di vista di chi costruisce questi strumenti: il suo lavoro, oggi, è scrivere loop, non prompt.

2. Dal prompt al loop: tre passaggi che hanno cambiato le regole – Loop Engineering: l’Evoluzione dei Prompt

Per capire perché il Loop Engineering è un salto e non una moda passeggera, conviene vedere la progressione che lo precede. Ogni livello non sostituisce il precedente, ma lo racchiude in un sistema più grande.

Il prompt engineering riguarda le parole che scrivi: come formuli un’istruzione perché il modello capisca esattamente cosa vuoi. Il context engineering riguarda tutto ciò che il modello può vedere: documenti, cronologia, strumenti collegati, memoria. Il Loop Engineering riguarda il ciclo che si ripete: agisci, osserva il risultato, decidi il prossimo passo, ripeti, finché una condizione di arresto verificabile non è soddisfatta.

Esempio pratico: se chiedi a un agente di sistemare un bug specifico, stai facendo prompt engineering. Se gli dai anche accesso al repository, ai log degli errori e alla documentazione interna, stai facendo context engineering. Se costruisci un sistema che ogni mattina controlla da solo i log della notte, individua i bug ricorrenti, li assegna a un agente, verifica la correzione con un secondo agente e aggiorna una board condivisa senza che tu debba aprire la chat, quello è un loop.

3. Le sei componenti di un loop, spiegate senza fuffa

Secondo l’anatomia proposta da Osmani, un loop ha bisogno di cinque elementi attivi più un sesto elemento di memoria che li tiene insieme. Vediamoli uno per uno, con un esempio minimo per ciascuno.

• Automazioni: le automazioni che si attivano da sole, su un intervallo di tempo o su un evento, ed eseguono discovery e triage senza intervento umano. Esempio: uno script pianificato che ogni notte controlla i test falliti in CI e apre un ticket automaticamente.
• Worktree: gli ambienti isolati (worktree) che permettono a più agenti di lavorare in parallelo sullo stesso progetto senza sovrascriversi a vicenda, esattamente come due sviluppatori che lavorano su branch diversi. Esempio: due agenti che sistemano bug diversi nello stesso repository, ciascuno nella propria copia di lavoro.
• Skill: la conoscenza di progetto scritta una volta in un file (comunemente chiamato SKILL.md) invece di essere rispiegata ogni sessione. Esempio: le convenzioni di stile del codice, i comandi di build, le regole di sicurezza interne, scritte in un file che l’agente legge automaticamente prima di iniziare.
• Connettori e plugin : i collegamenti (basati sul protocollo MCP, Model Context Protocol) che permettono all’agente di leggere il gestionale dei ticket, interrogare un database o scrivere su una chat aziendale invece di restare confinato al solo codice. Esempio: un connettore che permette al loop di aprire direttamente una pull request e avvisare il canale giusto quando i test passano.
• Subagent: un secondo agente, con istruzioni diverse e a volte un modello diverso, che verifica il lavoro del primo invece di lasciare che l’agente giudichi da solo il proprio compito. Esempio: un agente scrive la correzione di un bug, un secondo agente la confronta con i test esistenti prima di approvarla.

Il sesto elemento, quello che tiene insieme tutti gli altri, è lo stato esterno: un file Markdown, una board di progetto o qualunque cosa viva fuori dalla singola conversazione e ricordi cosa è stato fatto e cosa resta da fare. Il modello dimentica tutto tra un’esecuzione e l’altra: se la memoria resta solo nella conversazione, il loop riparte da zero ogni volta. Se invece la memoria è scritta su disco, il loop costruisce sul lavoro già fatto.

4. Esempio pratico: un loop che lavora mentre il team dorme

Mettiamo insieme i sei pezzi con uno scenario concreto, ispirato a quello descritto dallo stesso Osmani nel suo saggio. Immaginiamo un piccolo team di sviluppo, chiamiamolo Team Nordest, che gestisce un’applicazione interna.

Ogni mattina alle 6, un’automazione si attiva sul repository. Il suo compito è richiamare una skill di triage che legge i test falliti della notte, i ticket aperti e i commit recenti, e scrive i risultati in un file di stato condiviso. Per ogni problema che vale la pena affrontare, il sistema apre un ambiente isolato (worktree) e invia un subagent a scrivere una proposta di correzione. Un secondo subagent verifica quella proposta confrontandola con le skill di progetto e con i test esistenti. Se tutto torna, un connettore apre automaticamente la pull request e aggiorna il ticket collegato; se qualcosa non è chiaro, il caso finisce in una casella di revisione per un umano.

Quando il team arriva in ufficio alle 9, non trova una lista di cose da fare: trova un piccolo numero di pull request già pronte da revisionare, e uno stato che gli dice esattamente cosa è stato tentato, cosa ha funzionato e cosa resta aperto. Il punto non è che l’agente sia diventato più intelligente: è che nessuno ha dovuto scrivere un prompt per far succedere tutto questo. Il sistema è stato progettato una volta sola.

5. Claude Code vs Codex: stessa idea, strumenti diversi

Una notizia rassicurante per chi inizia ora: le sei componenti del Loop Engineering non richiedono più di costruire infrastrutture artigianali da zero. Sia Claude Code (Anthropic) sia l’app Codex (OpenAI) offrono ormai tutti e cinque i building block nativamente, con nomi leggermente diversi ma capacità equivalenti.

In Claude Code, le automazioni si costruiscono con comandi ricorrenti pianificabili, cron job e hook che eseguono comandi in punti precisi del ciclo di vita dell’agente, oppure spingendo l’intero flusso su GitHub Actions per farlo girare anche a computer spento. Nell’app Codex, esiste una scheda Automations dedicata dove si sceglie progetto, prompt e frequenza, con i risultati che atterrano in una casella di triage.

Entrambi gli strumenti offrono inoltre un comando che fa proseguire il lavoro attraverso più turni finché una condizione di arresto verificabile non risulta vera — per esempio ‘tutti i test del modulo di autenticazione passano ed il linting è pulito’ — con un modello separato che, a ogni turno, controlla se il compito è davvero concluso invece di fidarsi della parola dell’agente che ha scritto il codice. Per un ingegnere alle prime armi, il messaggio pratico è: prima impara a usare bene questi comandi nel tool che già usi in azienda, poi preoccupati dell’infrastruttura personalizzata.

6. Esempio pratico: triage automatico dei bug per un piccolo team IT

Vediamo un caso ancora più semplice, pensato per chi si affaccia ora al Loop Engineering in un contesto aziendale italiano. Un’azienda di software gestionale, chiamiamola SoftPuglia Srl, ha un team di 5 sviluppatori e riceve ogni giorno una decina di segnalazioni di bug dai clienti.

Passo 1: scrivono una skill che descrive come classificare un bug (gravità, modulo coinvolto, cliente interessato). Passo 2: collegano un connettore MCP al proprio sistema di ticketing, così l’agente può leggere le nuove segnalazioni senza che qualcuno le incolli a mano. Passo 3: impostano un’automazione che ogni mattina alle 7 legge i nuovi ticket, applica la skill di classificazione e propone una priorità. Passo 4: per i bug a priorità alta, un subagent prova a scrivere una correzione in un ambiente isolato; un secondo subagent la verifica contro i test automatici esistenti prima di proporla al team umano. Passo 5: tutto lo stato del lavoro — cosa è stato tentato, cosa ha funzionato — resta scritto in un file condiviso, non nella testa di una sola persona.

Il risultato non è un’azienda che licenzia gli sviluppatori: è un team di 5 persone che passa la mattina a revisionare proposte già pronte invece che a scrivere manualmente ogni singola istruzione all’agente, uno alla volta, per ogni singolo ticket.

7. Quello che il loop non farà mai al posto tuo

Qui arriva la parte che nessun post entusiasta scrive volentieri, ma che lo stesso Osmani mette nero su bianco nel suo saggio: il loop cambia il lavoro, non ti toglie dal lavoro. Anzi, tre problemi diventano più acuti proprio quando il loop funziona meglio.

Il primo è la verifica: un loop che gira senza supervisione è anche un loop che sbaglia senza supervisione. Separare l’agente che verifica da quello che scrive serve proprio a dare un significato reale al concetto di ‘lavoro concluso’ — che resta comunque un’affermazione, non una prova matematica.

Il secondo è quello che Osmani chiama debito di comprensione: più il loop produce codice che tu non hai scritto, più cresce la distanza tra quello che esiste nel progetto e quello che tu capisci davvero di quel progetto. Il terzo rischio è la tentazione di smettere di avere un’opinione e accettare qualunque cosa il loop restituisca — un atteggiamento che porta a una perdita progressiva di competenza tecnica nel team. Progettare il loop è la cura quando lo fai con criterio, ma diventa un acceleratore del problema quando lo usi per evitare di pensare.

8. Conclusioni: la velocità è la competenza che conta davvero

Il fatto che tre voci di riferimento del settore abbiano formalizzato lo stesso concetto nel giro di due giorni, a giugno 2026, non è un dettaglio da poco: racconta quanto velocemente si stia muovendo oggi il settore dell’intelligenza artificiale applicata allo sviluppo software. Il prompt engineering, che sembrava una competenza stabile fino a poche settimane prima, è già diventato un solo tassello di una disciplina più ampia. Chi lavora nell’IT lo sa bene: l’AI cambia alla velocità della luce, e le competenze che sembravano avanzate sei mesi fa oggi sono già il punto di partenza, non il traguardo.

In questo scenario, le aziende che riusciranno a primeggiare sul mercato non saranno necessariamente quelle con il budget più grande, ma quelle che sapranno formare per tempo i propri ingegneri su queste nuove pratiche, capire come si progetta un loop, come si scrive una skill, come si struttura un sistema di agenti che verificano il proprio lavoro, prima che diventino lo standard del settore e non più un vantaggio competitivo.

È esattamente per rispondere a questa esigenza che Innovaformazione propone il Corso sviluppo applicazioni LLM, pensato per aziende IT che vogliono portare i propri ingegneri informatici e AI Engineer, anche alle prime armi, dal prompt engineering di base fino alla progettazione di sistemi agentici moderni, comprese le pratiche di Loop Engineering illustrate in questo articolo. Il corso si svolge online in modalità classe virtuale, con calendario da concordare in base alle esigenze del team.

Contatti

Per informazioni e per richiedere un preventivo personalizzato:

• info@innovaformazione.net — tel. 347 101 2275 — Dario Carrassi.

Scopri il Corso sviluppo applicazioni LLM su Innovaformazione.net

(fonte) (fonte) (fonte)