1. Introduzione: il tramonto dell'era dei prompt manuali
Il “babysitting” dei prompt è ufficialmente diventato il collo di bottiglia della produttività moderna. Se passi ancora ore a rifinire istruzioni, correggere output e guidare manualmente l’IA passo dopo passo, stai utilizzando una tecnologia d’avanguardia con una mentalità obsoleta.
Il Prompt Engineering, per come lo conosciamo, sta tramontando.
La visione di leader tecnologici come Boris Cerni, creatore di Claude Code, e Peter Steinberger è netta: non è più l’essere umano a dover scrivere prompt per l’IA, ma è l’IA che deve generare prompt per se stessa all’interno di cicli autonomi.
Benvenuti nell’era del Loop Engineering, dove il ruolo dello specialista evolve da scrittore di comandi ad architetto di sistemi.
2. L’evoluzione: da “scrivere comandi” a “disegnare sistemi”
La transizione verso l’autonomia degli agenti ha seguito un percorso logico di astrazione:
- Prompt Engineering: definizione di identità e istruzioni tramite il system prompt.
- Context Engineering: gestione della memoria a breve termine attraverso la context window.
- Harness Engineering: progettazione di un’impalcatura esterna e persistente.
- Loop Engineering: esecuzione ricorsiva di loop sopra harness, memoria e strumenti.
Mentre il prompt è un’istruzione isolata, l’harness è l’infrastruttura che permette all’agente di operare.
Come ha dichiarato provocatoriamente Peter Steinberger:
Ti ricordo che non dovresti più fare prompting agli agenti. Dovresti progettare i loop che interrogano automaticamente il tuo agente.
3. Il problema invisibile: il “Context Rot” e il limite dei 200.000 token
L’illusione delle finestre di contesto da milioni di token si scontra con una realtà tecnica brutale: il Context Rot.
Superati i 200.000 token, le performance dei modelli possono degradare drasticamente: l’IA inizia a confondersi, perde dettagli rilevanti e fallisce più facilmente nel ragionamento logico.
Il Context Engineering tradizionale ha tentato di arginare il problema attraverso la compaction, ovvero la compattazione e il riassunto dei dati. Ma ogni sintesi comporta inevitabilmente una perdita di informazione.
Per un’automazione di alto livello, la compattazione non è sufficiente. Serve un cambio di paradigma architettonico che sposti la memoria fuori dalla sessione attiva.
4. Harness Engineering: il file system come memoria esterna persistente
L’Harness Engineering risolve la saturazione del contesto trasformando il file system locale in un’estensione della memoria dell’agente.
Invece di mantenere l’intero storico nella finestra di conversazione, l’agente utilizza file Markdown (.md) per garantire la persistenza senza “sporcare” il contesto operativo.
Attraverso strumenti come il Model Context Protocol (MCP), l’agente può interagire con il file system ed eseguire un vero e proprio flush della memoria:
- scrive ciò che ha appreso;
- svuota o rinnova la sessione;
- riparte leggendo soltanto i dati necessari;
- recupera le informazioni tramite ricerca semantica o lettura diretta.
I pilastri di questo sistema sono:
- Long-term memory (
memory.md): contiene fatti duraturi, preferenze tecniche e decisioni architetturali. - Journaling e task log: file strutturati per data e ora che tracciano l’avanzamento dei sottotask.
dreams.md: un “diario dei sogni” nel quale l’agente elabora strategie, riflessioni e pianificazioni di alto livello prima di agire.
5. Loop Engineering: l’IA che interroga se stessa
Il Loop Engineering può essere descritto come un loop sopra un harness sopra un loop di strumenti.
In questo modello, l’utente smette di essere l’operatore e diventa un Trigger Architect.
Non si scrive più:
Migliora questo codice.
Si definiscono invece:
- un obiettivo finale;
- una condizione di successo;
- un trigger di attivazione;
- un sistema di verifica;
- una condizione di arresto.
I trigger possono essere:
- eventi esterni, come news via API, commit su GitHub o apertura di una issue;
- eventi temporali, attraverso comandi come
sloopper esecuzioni a intervalli regolari.
Un esempio significativo è il progetto Auto Research di Andrej Karpathy, nel quale l’agente esegue esperimenti sul codice in loop fino al raggiungimento di una condizione prefissata.
In questo scenario si utilizzano comandi specifici come:
sloop: avvia cicli basati sul tempo, per esempio “ogni lunedì alle 9:00”.slg(Slash Goal): definisce un obiettivo qualitativo o quantitativo.
Per evitare il token burn, cioè cicli infiniti che consumano risorse senza produrre risultati, il Loop Engineering introduce condizioni di terminazione rigorose, come:
- un massimo di 100 tentativi;
- un limite temporale di 8 ore;
- una soglia minima di qualità;
- un budget massimo di token o di costo;
- l’intervento obbligatorio di un essere umano.
6. Il verificatore: i cinque livelli di controllo del loop
Il cuore del sistema non è l’azione, ma la verifica.
L’agente deve essere in grado di auto-valutarsi attraverso cinque livelli di feedback.
1. Verifica deterministica
Controllo binario true/false.
Esempio:
Il codice compila correttamente?
2. Regole e vincoli
Verifica basata su parametri numerici rigidi.
Esempi:
- velocità di caricamento inferiore a 100 ms;
- accuratezza superiore al 90%;
- consumo di memoria inferiore a una soglia stabilita.
3. Verità ritardata
Il risultato arriva dal mondo reale e richiede tempo per essere misurato.
Esempio:
Analizza l’engagement del post LinkedIn dopo 24 ore. Se non ha raggiunto 300 reazioni, ottimizza il contenuto successivo.
4. LLM come giudice
Un modello linguistico valuta la produzione su parametri estetici, qualitativi o soggettivi.
Un caso d’uso tipico è il clonaggio di una UI:
- l’agente genera il codice;
- esegue l’applicazione;
- scatta uno screenshot;
- confronta il risultato con un’immagine di riferimento;
- assegna un punteggio di somiglianza;
- continua il loop fino al raggiungimento della soglia desiderata.
Per esempio, il punteggio può passare da 0,30 a 0,90 attraverso iterazioni successive.
5. Checkpoint umano
Validazione manuale nei punti critici nei quali l’automazione totale non è sicura o desiderabile.
Il checkpoint umano rimane fondamentale quando sono coinvolti:
- decisioni strategiche;
- pubblicazione di contenuti;
- modifiche infrastrutturali;
- dati sensibili;
- impatti economici, legali o reputazionali.
7. Caso di studio: ottimizzazione algoritmica 320 volte più veloce
L’efficacia del Loop Engineering emerge chiaramente nell’ottimizzazione del calcolo del prodotto tra matrici in Python.
Invece di richiedere singoli miglioramenti, è stato impostato un comando slg con un limite di dieci tentativi autonomi.
Il loop ha seguito una progressione logica senza input umano:
- partenza da uno script base in
Float64; - passaggio a NumPy per migliorare la gestione della memoria;
- migrazione a PyTorch su CPU;
- implementazione CUDA per sfruttare la GPU;
- ottimizzazione finale tramite Tensor Core e precisione ridotta
Float16.
Il risultato è stato un incremento prestazionale di 320 volte, ottenuto in autonomia e con ogni passaggio documentato dall’agente nel proprio file di log.
8. Conclusione: verso un’IA che non ha più bisogno di noi, almeno per i prompt
Il passaggio al Loop Engineering segna una linea di demarcazione netta.
Il valore non risiede più soltanto nel saper “parlare” all’IA, ma nel saper progettare l’infrastruttura nella quale essa opera.
Dobbiamo smettere di chiederci esclusivamente come l’IA debba eseguire un compito e iniziare a definire con precisione cosa costituisce il successo di quel compito.
Mentre l’IA impara ad auto-correggersi e a gestire una memoria persistente, il ruolo dell’essere umano si sposta verso:
- la definizione degli obiettivi;
- la progettazione dei vincoli;
- il controllo della qualità;
- la supervisione etica;
- le decisioni strategiche.
La tua attuale infrastruttura IA è ancora ferma al babysitting manuale oppure sei pronto a progettare sistemi capaci di auto-migliorarsi in loop?