Loop engineering: come i pro usano Claude Code nel 2026

Chi ha costruito Claude Code ha smesso di scrivere prompt. Boris Cherny, il responsabile dello strumento di Anthropic per scrivere software con l'AI, lo ha messo in una frase asciutta: non chiede più niente al modello a mano, ha dei cicli che girano e che fanno il lavoro di chiedere al posto suo. Il suo mestiere, adesso, è scrivere quei cicli.

Detta così sembra una battuta da addetti ai lavori. Sotto c'è un cambio di mestiere che riguarda chiunque usi l'AI per lavorare, non solo chi programma. Perché il punto non è la sintassi del codice. È chi tiene in mano il ciclo di lavoro: tu che chiedi una cosa alla volta, o un sistema che le chiede da solo finché il risultato non è pronto.

Dal prompt al loop: cosa cambia davvero

Il prompting lo conosci già, anche se non lo chiami così. Apri la chat, fai una domanda, leggi la risposta, correggi, richiedi. Sei tu il ciclo. Ogni passaggio passa dalle tue mani e dalla tua attenzione. Funziona, ma si ferma nel momento in cui ti alzi dalla scrivania.

Il loop engineering sposta il lavoro di un gradino sopra. Invece di scrivere la richiesta, scrivi una volta sola il ciclo che la ripete: condizione di partenza, cosa controllare a ogni giro, quando fermarsi. Poi lo lasci andare. Il prompt diventa una riga dentro un programma più grande, non più la cosa che batti a mano cinquanta volte al giorno.

La competenza che conta si sposta di conseguenza. Prima era saper formulare bene la domanda. Adesso è saper disegnare il giro: che cosa vuol dire "finito", come si verifica che il pezzo prodotto sia buono, dove mettere il freno prima che il sistema vada per conto suo nella direzione sbagliata. Chi sa fare questo lavora mentre dorme. Chi sa solo chiedere, lavora finché è sveglio.

I quattro loop che fanno il lavoro

Non esiste un loop unico. Ne girano di tipi diversi, a seconda di cosa deve far scattare il ciclo. Quattro forme coprono quasi tutto.

Tre di questi nomi vengono dal modo in cui i computer lavorano da sempre. Un cron è un'attività schedulata, esiste da decenni. Un hook è un aggancio che fa partire qualcosa al verificarsi di un evento. La novità è che dentro non c'è uno script rigido, c'è un modello che ragiona. Quindi il loop non esegue solo passi fissi, decide.

Il quarto, il goal-based, è quello che cambia di più le carte. Gli dai un obiettivo, non una lista di passi. Il sistema apre sotto-agenti, ognuno con il suo pezzo di lavoro e la sua memoria separata, e continua a generarne finché la cosa non è fatta. È qui che il loop smette di essere un automatismo e inizia a somigliare a un piccolo team che si organizza da solo. Claude Code questi cicli ormai li tratta come funzioni native, non più come trucchi messi insieme a mano dagli utenti più smaliziati.

Firefox: cosa trova un loop che 15 anni di controlli non avevano trovato

Il caso che toglie ogni astrazione arriva da Mozilla. Ad aprile 2026 il team di Firefox ha messo al lavoro una pipeline di sicurezza agentica, costruita attorno a un modello Claude della classe Mythos, lasciandola scorrere sul codice del browser. Il risultato si misura con un numero secco: 423 bug di sicurezza chiusi in un mese, contro una media di circa 21 al mese nel 2025.

Di quei 423, 271 sono stati attribuiti direttamente al modello. Tra questi, il pezzo che fa effetto: un difetto annidato nell'elemento <legend> del browser, rimasto lì per quindici anni. Aveva attraversato indenne anni di test automatici, controlli manuali e ricerche di sicurezza. Il loop lo ha tirato fuori in pochi giorni.

Il motivo per cui era sfuggito spiega tutto il resto. I test automatici classici, i cosiddetti fuzzer, sparano migliaia di input a caso e guardano se qualcosa si rompe. Quel bug però scattava solo se tre comportamenti diversi del browser si incastravano nello stesso istante, una combinazione che a caso non capita quasi mai. Il modello, invece, ha letto il codice, ha ipotizzato che quei tre comportamenti potessero collidere, e ha costruito la sequenza precisa per provocare il guasto.

Ma il dettaglio che lo rende un caso di loop engineering, e non solo una storia di AI brava, è un altro. La pipeline non si limitava a segnalare codice sospetto. Per ogni potenziale bug costruiva e faceva girare un test riproducibile, e scartava da sola tutto quello che non riusciva a confermare. Il ciclo verificava se stesso. È questa la parte che conta: un loop che produce e basta è solo rumore più veloce, un loop che produce e si controlla è lavoro vero.

I numeri di chi già lavora così

Torniamo a Cherny, perché i suoi numeri dicono dove sta andando la cosa. In trenta giorni ha aperto 259 richieste di modifica al codice di Claude Code, e la totalità di quei contributi è stata scritta dal modello, non a mano. Dieci, anche trenta interventi al giorno. A suo dire non tocca una riga di codice a mano da mesi. Il suo ruolo si è ridotto, o meglio, si è spostato: definire i cicli, guardare cosa producono, correggere il tiro.

Una cosa del genere regge solo se il motore dentro al loop è abbastanza affidabile da poterlo lasciare andare senza guardarlo ogni minuto. Ed è esattamente quello che è cambiato negli ultimi mesi.

Un modello che chiude otto problemi reali su dieci lo guardi a vista. Uno che ne chiude più di nove su dieci lo puoi lasciare girare in un loop per un'ora senza tornare a controllare a ogni passo. Il salto di qualità dei modelli è la condizione che rende sensato il loop engineering, non un dettaglio tecnico a parte. Questa stessa partita, vista dal lato di chi compra gli strumenti, l'abbiamo raccontata quando SpaceX ha pagato Cursor 60 miliardi di dollari: chi controlla il modo in cui si scrive il software controlla tutto il resto.

Dove il loop si rompe

Non è gratis e non è automatico nel senso di "lo accendi e funziona". Un ciclo che gira da solo amplifica quello che gli metti dentro, nel bene e nel male. Se la condizione di stop è scritta male, il sistema non produce un errore, ne produce mille, in fretta, e te li trovi tutti insieme.

Ci sono almeno due conti da fare prima di entusiasmarsi. Il primo è la spesa: un loop heartbeat o un cron che girano davvero 24 ore su 24 consumano token e calcolo anche mentre dormi, e quei costi vanno previsti, non scoperti a fine mese. Il secondo è il controllo. Chi rivede quello che il loop ha prodotto di notte? Il caso Firefox ha funzionato proprio perché la verifica era dentro il ciclo, non appiccicata dopo. Senza quel passo, un loop è solo una macchina per generare lavoro non controllato a velocità più alta.

C'è anche un tema di competenze che le aziende italiane farebbero bene a guardare adesso. Chi sa solo dare ordini all'AI un colpo alla volta vale sempre meno. Chi sa progettare il ciclo, le sue condizioni, i suoi controlli, vale molto di più. La stessa dinamica che avevamo visto quando Microsoft ha frenato sulle assunzioni di ingegneri perché l'AI scrive ormai gran parte del codice.

Cosa farne se guidi un'azienda in Italia

Non serve che tu scriva loop da domani mattina. Serve che tu capisca dove si è spostato il collo di bottiglia, perché lì si gioca la produttività dei prossimi anni.

Tre cose pratiche, valide anche se nella tua azienda non si scrive una riga di codice.

Il valore si sposta dal "fare" al "definire e verificare". Qualunque processo ripetitivo con un traguardo chiaro è un candidato per un loop: il report del lunedì, il controllo di una lista di pratiche, il monitoraggio di un sistema, la pulizia di un archivio dati. La domanda non è più "chi lo fa", è "come scrivo le regole perché si faccia da solo, e come controllo che sia fatto bene".

Le persone giuste cambiano. Ti serve chi sa leggere un processo dall'alto e disegnarne il ciclo, più di chi esegue lo stesso passo mille volte. È un profilo diverso, e in Italia per ora scarseggia. Su come costruirlo in casa abbiamo scritto una mappa per diventare il riferimento AI dentro l'azienda.

Il vantaggio non è più l'accesso al modello. Quello ce l'hanno tutti, a prezzi simili. La differenza la fa la qualità dei loop che costruisci attorno, e i controlli che ci metti dentro. Chi vuole capire quali processi convenga affidare a un ciclo automatico e quali no può partire da una automazione dei processi aziendali pensata sul caso concreto, invece di comprare l'ennesimo strumento alla moda.

La frase di Cherny, "il mio lavoro è scrivere loop", oggi suona da nerd. Tra un paio d'anni sarà la descrizione di mezzo lavoro d'ufficio. Conviene arrivarci avendo già capito di cosa si tratta, non rincorrendolo dopo.