Per due anni, ottenere di più da un agente AI significava scrivere un prompt migliore.
Quell'era sta finendo in silenzio. I migliori ingegneri del mondo hanno smesso di scrivere prompt tempo fa e hanno iniziato a scrivere loop: sistemi che istruiscono l'agente, controllano il risultato e continuano a funzionare finché il lavoro non è terminato.
Lo script notturno di Karpathy ha trovato 20 ottimizzazioni che lui aveva mancato in due decenni di regolazioni manuali. Boris Cherny, che ha costruito Claude Code, non ha scritto una riga di codice quest'anno. Gli ingegneri di Anthropic ora uniscono quasi 8 volte più codice al giorno rispetto al 2024.
Nessuno di loro ha digitato qualcosa di più intelligente. Hanno smesso del tutto di digitare.
Ecco cos'è realmente un loop, quando ti serve, quando no, e come costruire il tuo primo.
700 esperimenti mentre l'umano dormiva
Marzo 2026. Andrej Karpathy carica tre file su GitHub. Circa 630 righe di codice.
Un file conteneva il modello. Uno lo valutava. Uno diceva all'agente cosa esplorare e cosa lasciare stare. L'agente poteva toccare solo il file di training. Nient'altro.
Il ciclo era noioso di proposito. Leggi il codice, proponi una modifica, addestra per cinque minuti, controlla se il punteggio migliora, mantieni la modifica se lo fa, annulla se non lo fa, poi ricomincia.
Lo ha puntato su un modello che aveva già ottimizzato a mano per due decenni. Lo ha lasciato girare per due giorni.
Ha eseguito 700 esperimenti. Ha trovato 20 miglioramenti. Uno di questi era un moltiplicatore scalare mancante nel meccanismo di attenzione, sottile, non il tipo di bug che un linter possa mai cogliere, ma esattamente il tipo di cosa che un ingegnere attento avrebbe potuto trovare e non ha mai fatto.
Il CEO di Shopify ha usato lo stesso trucco durante la notte su un modello interno. Si è svegliato con un miglioramento della qualità del 19% su un modello grande la metà del precedente.
L'intuizione non è "l'AI è più intelligente". Gli umani si stancano dopo l'esperimento numero dodici. I loop non si stancano affatto.
Un loop non è un prompt programmato
La maggior parte delle persone sente "loop" e pensa a cron. Questo manca completamente il punto.
Un prompt è una singola istruzione. Un loop è un obiettivo verso cui l'AI continua a lavorare finché non lo raggiunge, senza nessuno sulla sedia. Pianifica, esegue, verifica il proprio risultato, reimmetti il risultato e ripete.
Cinque fasi: scopri, pianifica, esegui, verifica, itera. Tre di queste fanno il lavoro vero.
Il verificatore è il cuore del loop. Senza un vero gate sull'output, non hai un loop, hai l'agente che si auto-valuta all'infinito. Un gate è un test che passa o fallisce, un build che compila o crasha, un linter che restituisce zero o non-zero. Non un secondo agente con un'opinione.
Lo stato è ciò che fa imparare il loop. Un file a parte, un Linear board, un log di progetto, un posto fuori dalla conversazione che registra cosa è stato provato e cosa è fallito. La corsa di domani riprende invece di ricominciare da zero.
Una condizione di arresto è ciò che lo mantiene sano. Ogni vero loop ha due uscite: l'obiettivo è raggiunto o scatta un limite massimo. Salta questo e hai costruito una macchina che gira tutta la notte per niente.
Se manca uno qualsiasi di questi tre, non hai costruito un loop. Hai costruito uno script costoso.
Le quattro condizioni prima di costruirne uno
I loop ripagano il loro costo solo quando quattro cose sono vere contemporaneamente. Se ne manca una, la configurazione richiede più di quanto restituisce.
- Il compito si ripete almeno settimanalmente. Meno di così e il costo di setup non si ammortizza mai.
- Qualcosa può automaticamente bocciare il lavoro. Un test, un type check, un linter, un build.
- Il tuo budget di token può assorbire lo spreco. I loop rileggono il contesto, riprovano, esplorano.
- L'agente ha strumenti da ingegnere senior. Log, ambiente di riproduzione, capacità di eseguire il codice che scrive e vedere cosa si rompe.
La versione onesta, la parte che nessuno che vende loop ti dirà: la maggior parte delle persone non ha ancora bisogno della versione pesante. Se sei su un piano consumer e provi a eseguire loop di verifica notturni su lavoro serio, il conto dei token arriva prima del guadagno di produttività.
I buoni primi loop sono quelli noiosi. Triage CI. Aggiornamenti di dipendenze. Passaggi lint-and-fix. Riproduzione di test instabili. Bozze da issue a PR su un codebase con test già solidi.
I cattivi primi loop sono quelli interessanti. Riscritture di architettura. Codice di autenticazione. Pagamenti. Tutto ciò in cui "fatto" è un giudizio e un umano deve ancora esprimersi.
I cinque blocchi che rendono reale un loop
Ogni vero loop è assemblato dagli stessi cinque pezzi. Claude Code e Codex li includono tutti ora.
Il primo è l'automazione. Il battito cardiaco. Qualcosa che attiva il loop su un programma o un evento. /loop gira su una cadenza. /goal continua finché una condizione che hai definito non è effettivamente vera. Senza un battito cardiaco, il loop è uno script che hai eseguito una volta e dimenticato.
Il secondo è una skill. Conoscenza del progetto salvata come file claude-md che l'agente legge a ogni esecuzione. Senza, il loop re-deriva il tuo contesto da zero a ogni ciclo. Con esso, l'intento si accumula. Il loop conosce le tue convenzioni, i tuoi passaggi di build, la cosa che non fai mai a causa di quell'incidente di tre mesi fa.
Il terzo sono i sub-agenti. Il creatore e il controllore non possono essere lo stesso modello. Quello che ha scritto il codice è troppo generoso nel valutare il proprio lavoro. Quello che ha scritto l'articolo non vede le proprie sezioni deboli. Scrittore veloce ed economico. Revisore lento e severo. Questa separazione è la maggior parte della qualità.
Il quarto sono i connettori. Il loop apre la pull request, chiude il ticket, invia un messaggio sul canale quando la CI diventa verde. Questa è la differenza tra un agente che dice "ecco una soluzione suggerita" e un report che ti aspetta al mattino dicendo che la PR è già stata unita.
Il quinto è il verificatore. Il test, il type check o il build che boccia automaticamente il lavoro scadente. Tutto il resto è infrastruttura. Questo è il blocco che decide se il loop ti aiuta o si limita a spendere i tuoi soldi.
Mettili insieme e ottieni ciò che i team seri ora eseguono su larga scala. Dozzine di loop, ognuno con un compito ristretto, che girano fianco a fianco mentre tutti dormono. Un ingegnere ha usato un loop di flotta come questo per riscrivere un intero codebase da un linguaggio all'altro in circa sei giorni, un lavoro che a mano avrebbe richiesto quasi un anno.
Dove i loop falliscono in silenzio
I loop non crashano. Ti fatturano in silenzio. Due modalità di fallimento che vale la pena nominare, entrambe peggiorano man mano che il loop migliora, non diventa più facile.
Il primo è il loop di Ralph Wiggum. L'ingegnere Geoffrey Huntley lo ha documentato. L'agente decide di aver finito troppo presto, emette il segnale di completamento su un lavoro a metà, e il loop esce soddisfatto. Senza un gate obiettivo e duro, il loop continua a girare la notte successiva, continua a spendere, continua a produrre lavoro che nessuno accetterà.
La soluzione non è un agente più intelligente. È un gate più stupido. Un test che passa o fallisce. Un build che compila o no. Qualcosa senza opinioni.
Il secondo è più sottile. Debito di comprensione. Più velocemente il loop produce codice che non hai scritto, maggiore è il divario tra ciò che il tuo repository contiene e ciò che realmente capisci. Un loop che funziona senza intoppi addebita interessi composti su quel divario. Il giorno in cui devi fare debug di un sistema che nessuno del team ha mai letto costa più di quanto abbiano mai fatto i token.
Con questo arriva la resa cognitiva. Quando il loop si auto-gestisce, è tentante smettere di formarsi un'opinione e accettare qualunque cosa ritorni. Progettare il loop è la cura quando lo fai con giudizio. È l'acceleratore quando lo fai per evitare di pensare. Stessa azione, risultato opposto.
Due persone possono costruire esattamente lo stesso loop e finire in posti opposti. Uno lo usa per muoversi più velocemente su un lavoro che capisce profondamente. L'altro lo usa per evitare di capire il lavoro del tutto. Il loop non conosce la differenza. Tu sì.
Inizia con un loop, non con dieci
L'errore che tutti fanno è cercare di costruire l'intero sistema il primo giorno. Dieci loop, un cruscotto, una flotta. Crolla entro il fine settimana perché non sai dire quale loop ha fatto cosa.
Inizia con uno. Scegli il compito ricorrente più fastidioso che hai, la cosa che controlli ogni mattina per abitudine, e trasforma quel singolo lavoro in un loop. Lascialo girare per qualche giorno. Osserva dove esagera. Osserva dove manca. Stringi. Poi aggiungi il secondo.
L'ordine conta più degli strumenti. Prima rendi affidabile una singola esecuzione manuale, non veloce, affidabile. Trasforma quell'esecuzione in una skill claude-md. Avvolgi la skill in un loop con un gate obiettivo e una condizione di arresto rigida. E solo allora, mettila in programma. Saltare avanti, pianificare qualcosa che non hai reso affidabile a mano, è esattamente come i loop esplodono mentre dormi.
La metrica che decide se il loop funziona non sono i token spesi o i compiti tentati o le PR aperte. È il costo per modifica accettata. Se il tuo tasso di modifica accettata è sotto il 50%, stai facendo il lavoro di revisione che il loop avrebbe dovuto rimuovere, e il loop sta perdendo.
Karpathy ha smesso di scrivere codice di training. Cherny ha smesso di scrivere prompt. Nessuno dei due ha smesso di pensare. Se prendi una cosa da questo, prendi questa. Il loop è un sistema che fa il noioso 95% mentre tu tieni la piena attenzione sul 5% che realmente porta rischio.
Stai pagando per una flotta di agenti e usando una singola finestra di chat.
Seguimi e iscriviti al mio canale Telegram: https://t.me/+75nMf005jRpjMDU1
