# La prompt engineering è morta. Lunga vita alla loop engineering. *Perché il responsabile di Claude Code in Anthropic ha appena segnalato la fine dell'era del "sussurratore di IA" — e cosa viene dopo.* > Boris Cherny, che guida Claude Code in Anthropic, dice di non scrivere più prompt per Claude — scrive loop. Dentro la morte della prompt engineering e la nascita della loop engineering: flussi di lavoro agentici, agenti autonomi che si autocorreggono, perché il verificatore conta più del prompt, e come lo stesso loop sia collegato a uno spazio di lavoro che possiedi — verifiche automatiche nel repository, memoria che sopravvive alla sessione, e un pannello di controllo che costruisce e sa ripristinare. — Fractera, 2026-06-14 ## La citazione che ha infranto l'illusione Pochi giorni fa, una singola citazione di **Boris Cherny** — l'ingegnere che guida lo sviluppo di **Claude Code** presso **Anthropic** — ha silenziosamente scosso la comunità del software. In un panel pubblico, Cherny ha svelato come lavorano davvero con i propri modelli le persone che costruiscono l'IA di programmazione più sofisticata al mondo. Quello che ha detto non si è limitato a sfidare lo status quo — ha dichiarato obsoleta un'intera disciplina emergente: > Non scrivo più prompt per Claude. Ho dei loop in esecuzione che interrogano Claude e decidono cosa fare. Il mio lavoro è scrivere loop. > > — Boris Cherny · Claude Code, Anthropic Lascia che questo si sedimenti. L'uomo con entrambe le mani sul volante del miglior modello per sviluppatori al mondo ti sta dicendo che ha tolto le mani dal volante. Non siede in una finestra di chat a rifinire il paragrafo perfetto di istruzioni. Scrive codice che costringe l'IA a parlare con se stessa, giudicare i propri errori e correggerli dentro un circuito autonomo e chiuso. Costruisce la macchina che guida il modello — e poi la lascia guidare. Se stai ancora passando le giornate a rifinire prompt per estorcere all'LLM il blocco di codice giusto, il suo messaggio è brutalmente chiaro: **stai ottimizzando un mondo che è già scomparso.** ## Il cambio di paradigma: dal micromanagement all'architettura di sistema Per capire perché questo è un cambiamento tettonico, guarda come si è evoluto il nostro rapporto con l'IA generativa in appena un paio d'anni. ### Fase 1 — Il prompt lineare (il collo di bottiglia umano) Fino a poco tempo fa, l'intero settore era ossessionato dalla **prompt engineering**. Trattavamo gli LLM come junior brillanti ma facilmente distraibili. Il flusso di lavoro era lineare, fragile e interamente manuale: ``` scrivi un prompt ─▶ l'IA scrive codice ─▶ trovi il bug ─▶ correggi il prompt ─┐ ▲ │ └───────────────────────── di nuovo a mano ◀─────────────────────────────┘ ``` In questo paradigma, **il collo di bottiglia è l'essere umano.** Scrivi un prompt, leggi il risultato, individui un errore di sintassi, lo incolli di nuovo in chat e speri che il modello non abbia dimenticato il contesto cinque passaggi dopo. Sembra produttivo. È un micromanagement estenuante e non scalabile — e di certo non funziona mentre dormi. ### Fase 2 — La loop engineering (il circuito autonomo) Quello che Cherny descrive è la **loop engineering** — flussi di lavoro agentici in cui l'essere umano esce completamente dal ciclo di esecuzione. Smetti di guidare l'auto. Costruisci la pista e lasci che la macchina percorra i giri. Invece di scrivere un prompt per risolvere un problema, scrivi un **loop** programmatico che incorpora l'IA in un ciclo automatico di esecuzione e verifica: 1. **L'obiettivo.** Un essere umano fissa un unico obiettivo di alto livello — "costruisci questo endpoint API e raggiungi il 98% di copertura dei test". 2. **L'azione.** L'IA genera una prima bozza del codice. 3. **La verifica.** Un ambiente automatico — compilatori, linter, test unitari, la tua CI — esegue il codice e individua ogni errore. 4. **L'autocorrezione.** In caso di fallimento, il sistema cattura lo stack trace, lo restituisce all'IA come nuova istruzione e le ordina di riprovare. ``` definisci l'obiettivo │ ▼ l'IA scrive codice ─▶ la CI esegue ogni controllo ─▶ verde? ─▶ ✦ pubblicato ▲ │ │ ▼ (rosso) └── l'IA legge i log e si dà da sola un nuovo prompt ``` Il loop corre a velocità di macchina, macinando decine di iterazioni, autocorreggendosi e autoguarendosi finché i criteri di verifica non sono soddisfatti. Non hai digitato un solo follow-up. Non hai scritto i prompt — hai costruito la pista, e il modello ha percorso ogni giro da solo. ## La vera competenza non è scrivere codice. È scrivere il giudice. Ecco la parte che quasi tutti si perdono — ed è l'intera posta in gioco. La parte difficile di un loop **non** è generare il codice. I modelli sono già spaventosamente bravi in questo. La parte difficile è **ciò che decide se il codice è valido.** Dai al loop un verificatore forte e spietato — test veri, analisi statica, un compilatore che si rifiuta di mentire — e converge verso qualcosa che funziona davvero. Dagliene uno debole, e quello stesso loop produrrà allegramente un fiume infinito di spazzatura sicura e formattata alla perfezione, allucinando la strada verso un segno di spunta verde che non significa nulla. Quindi la competenza del prossimo decennio non è l'arte del prompt. È **progettare la verifica** — i sistemi di validazione a prova di proiettile che permettono a un'IA di parlare con se stessa in sicurezza senza precipitare da un dirupo. È un tipo di ingegneria più difficile, più raro e molto più prezioso che trovare le parole giuste. ## Dalla filosofia alla produzione: come abbiamo progettato il loop Mentre il resto del mondo tech smonta la citazione di Cherny sui social, la vera sfida non ha nulla di glamour: **come costruisci un'infrastruttura di loop engineering che funzioni davvero in produzione — fuori dai laboratori interni di Anthropic?** Chiudi un loop attorno a un singolo modello e sbatti subito contro i muri del mondo reale: degrado della finestra di contesto, spirali allucinatorie mortali e nessuna memoria lungo il progetto. Su [%SITE%](/it) abbiamo passato l'ultimo anno a trattare la filosofia di Cherny non come una previsione ma come un **progetto architettonico** — e abbiamo costruito il loop su cui gira questo spazio di lavoro. ![Il ciclo di sviluppo: il proprietario fissa un obiettivo, l'agente modifica il repository, verifiche automatiche lo controllano, i fallimenti tornano all'agente come nuove istruzioni, e il pannello di controllo costruisce, registra e può ripristinare](media:development-loop-2026.jpg) *Il loop così com'è davvero collegato: un agente nel tuo repository, verifiche che non sanno mentire, e un pannello che chiude il circuito.* ### L'anatomia di un loop di livello produttivo Per rendere i loop percorribili per software reale, bisogna smettere di ammirare il modello e iniziare a costruire le tre cose senza glamour attorno ad esso — il giudice, la memoria e la mano che consegna: - **Un verificatore che non si lascia convincere con le buone maniere.** Il giudice non è un secondo modello con un'opinione; è un insieme di script che fanno fallire la build. Esistono i segnali di lingua su ogni pagina pubblica? Ogni articolo ha il gemello markdown di cui ha bisogno un lettore IA? Viene referenziata un'immagine che nessuno ha caricato? Ogni controllo esiste perché quel difetto esatto è già arrivato in produzione una volta, e ciascuno risponde con un codice di uscita, non con un paragrafo. - **Memoria che sopravvive alla sessione.** L'effetto amnesia è reale: quindici giri attorno a un bug ostinato e l'agente perde di vista l'architettura. Qui la memoria non è un servizio che può andare offline — sono file accanto al codice che viaggiano con il repository: l'istruzione di lavoro, le lezioni aggiunte nel momento in cui il proprietario corregge qualcosa, l'elenco degli antipattern, i casi utente confermati. Una nuova sessione inizia leggendoli, così la quindicesima iterazione sa ciò che la prima ha imparato. - **Un atto finale che non appartiene all'agente.** Il loop si conclude nel pannello di controllo: costruisce il progetto, tiene un registro dei deployment e può tornare all'ultima build funzionante. Impostazioni, testi e immagini cambiano lì senza alcuna ricostruzione — così al loop non viene mai chiesto di risolvere ciò che non è mai stato un problema di codice. Nota cosa **non** c'è in quella lista: uno sciame di modelli che si supervisionano a vicenda. Quella era la nostra prima architettura, e l'abbiamo rimossa. L'orchestrazione è la parte più eccitante di un diagramma agentico e la parte meno portante di uno che funziona — un giudice debole non si aggiusta aggiungendo una seconda opinione, e uno forte raramente ne ha bisogno. ## La nuova descrizione del lavoro dell'ingegnere software Ci stiamo allontanando dallo scrivere codice, oltre lo scrivere prompt, e dritti verso **costruire pipeline cognitive.** Il mestiere non è più l'istruzione — è il sistema dentro cui gira l'istruzione. E non è gratis. Con i loop arrivano due nuovi costi. **Debito di comprensione:** quando un agente scrive e riscrive un file trecento volte dietro le quinte, la tua padronanza del tuo stesso codice si erode silenziosamente — funziona, semplicemente non sei più sicuro del perché. E **calcolo puro:** un loop può bruciare soldi veri in token inseguendo un bug attraverso cento tentativi silenziosi. Gli ingegneri che vincono in questa era trattano il rapporto costo-qualità come una decisione di progettazione deliberata, non come una sorpresa in fattura. Questo sito è uno di quei loop: le pagine che stai leggendo sono file statici che una verifica ha rifiutato di pubblicare finché non hanno portato con sé i loro segnali di lingua, il loro gemello markdown e il loro posto nella mappa del sito. — [Guarda lo spazio di lavoro su cui gira](/it) L'era della prompt engineering è ufficialmente alle spalle. Resta solo la domanda a cui Cherny ha già risposto per se stesso: **stai ancora cercando di parlare con la tua IA — o stai già costruendo i loop che la lasciano correre?** Fonte: un post su LinkedIn ampiamente condiviso di Guillermo Flor che ha portato alla luce le parole di Boris Cherny. La citazione è riprodotta così come è circolata; l'architettura e l'analisi sono nostre. ## FAQ ### Cos'è la "loop engineering" e perché sta sostituendo la prompt engineering? La loop engineering significa scrivere flussi di lavoro automatizzati che interrogano l'IA, fanno passare il suo output attraverso un verificatore (test, CI, un compilatore), restituiscono i fallimenti come nuove istruzioni e ripetono — finché il risultato non è corretto. Boris Cherny, che guida Claude Code in Anthropic, ha detto che non scrive più prompt a mano: scrive i loop che lo fanno per lui. L'intuizione chiave è che il collo di bottiglia non è mai stato il prompt — era l'essere umano nel ciclo di feedback. ### Come è collegato qui, in produzione, il ciclo di sviluppo? Un agente di codice lavora dentro il tuo stesso repository, sulla tua macchina, con l'istruzione di lavoro del progetto accanto al codice. Il verificatore è un insieme di controlli che girano a ogni build e la fanno fallire: segnali di lingua su ogni pagina pubblica, un gemello markdown per ogni pagina pubblicata, nessuna immagine referenziata che non sia mai stata caricata, nessun dizionario privo di una chiave. Un fallimento torna all'agente come nuova istruzione, e il ciclo si ripete. Il pannello di controllo chiude il circuito — costruisce il progetto, registra ogni deployment e può tornare all'ultima build funzionante. ### Devo scrivere codice per far girare questo loop? Non per la maggior parte di ciò che un sito cambia davvero. Il nome, la descrizione, le immagini, le lingue, l'analitica e i testi delle impostazioni vivono nel pannello di controllo e si applicano senza alcuna ricostruzione — sono dati, non codice. I cambiamenti di codice sono ciò che fa l'agente nel tuo repository; tu li leggi e li approvi, e il pannello costruisce il risultato. Il confine onesto è questo: nessuno promette che non guarderai mai un diff — ti viene promesso che non dovrai mai eseguire la build a mano, e che una build rotta può essere ripristinata con un clic.