Gauntlet Loop: il prompt che lavora per ore (e quando è troppo)

Qualche giorno fa ho scritto un solo prompt, l'ho mandato, e ho lasciato lavorare Claude per ore.

Non su un'app o su un videogioco. Su una cosa molto meno spettacolare: una serie di email automatiche per i miei e-commerce. Condizioni di uscita, una guida in PDF allegata, attese diverse tra un invio e l'altro, quattro lingue. Tutto in un colpo.

Il prompt seguiva una tecnica che in queste settimane gira ovunque: il Gauntlet Loop. Il risultato è stato buono. Ma la cosa che mi porto a casa è un'altra, e con il prompt c'entra poco.

Ti racconto tutte e due. E ti racconto anche il rovescio della medaglia, perché c'è e ha un nome: over-prompting.

Tre paragrafi e uno sparatutto

Il 25 luglio Matt Shumer, imprenditore americano del mondo AI e fondatore di HyperWrite, ha pubblicato Claude of Duty: uno sparatutto in prima persona che gira nel browser, costruito da Claude Opus 5 a partire da un prompt di tre paragrafi. Secondo Decrypt parliamo di circa 55.000 righe di codice divise in undici sottosistemi, con texture, modelli 3D, animazioni e suoni generati direttamente nel browser.

Il prompt non entrava nei dettagli. Niente meccaniche di gioco, nessuna definizione di cosa volesse dire "qualità da tripla A". Chiedeva tre cose: dividere il lavoro tra più sub-agenti, far passare ogni pezzo da un critico separato e severo, confrontare il risultato fianco a fianco con i veri Call of Duty. E andare avanti finché ogni critico non fosse rimasto a bocca aperta.

Nei giorni successivi Shumer ha dato un nome al metodo. In inglese "run the gauntlet" vuol dire passare in mezzo a due file di persone che ti mettono alla prova. L'idea è proprio quella: ogni pezzo di lavoro attraversa il corridoio, e se non convince torna indietro.

Io l'ho scoperto grazie alla newsletter di Jacopo Perfetti, che lo spiega molto bene e mette in guardia sul rischio opposto. Se non la conosci, vale l'iscrizione.

Come funziona, in quattro mosse

Si dice in fretta: dividi, costruisci, giudica, ripeti.

1. Un agente principale riceve l'obiettivo e lo spezza nei pezzi più piccoli che si possano valutare da soli.
2. Su ogni pezzo lavora un costruttore.
3. Un critico diverso, con il contesto pulito, mette il risultato accanto a un riferimento reale, senza sapere quale sia quale, e dice quale dei due è migliore.
4. Se il nostro perde, il critico indica il divario più grande e il pezzo torna al costruttore. Si ripete finché vince, o finché qualcuno dice basta.

Detta così sembra una catena di montaggio. Dentro però ci sono due idee che fanno tutta la differenza.

Il riferimento è una cosa, non un aggettivo

"Fallo bellissimo" non è un criterio. È un desiderio.

Il critico ha bisogno di qualcosa da aprire e confrontare: uno screenshot, una pagina pubblicata, un test che passa o fallisce, un testo scritto bene da qualcun altro. Nel progetto open source che ha trasformato il metodo in una skill per agenti, la regola sta in tre parole: il riferimento deve avere un nome, deve essere raggiungibile dal critico e deve poter stare accanto al nostro risultato.

Senza un riferimento, il critico si inventa uno standard. E uno standard inventato da chi giudica, prima o poi, risulta sempre raggiunto.

Chi costruisce non si giudica

È lo stesso motivo per cui un contratto importante non lo rilegge solo chi l'ha scritto. Chi ha fatto una scelta tende a difenderla. Un agente che rilegge il proprio lavoro con tutto il ragionamento ancora in testa troverà ottimi motivi per cui va bene così.

Il critico invece arriva fresco. Non ha visto il ragionamento: vede solo il risultato e il riferimento. E non dà un voto da uno a dieci, che giro dopo giro tende a salire per inerzia. Sceglie: questo o quello.

Niente di nuovo, e va bene così

Se lavori con gli agenti da un po', riconosci i pezzi. Anthropic descriveva già a fine 2024 lo schema evaluator-optimizer: un modello genera, un altro valuta e dà un riscontro, in ciclo. Con due segnali per capire se fa al caso tuo: il risultato migliora quando una persona spiega cosa non va, e il modello è in grado di dare da solo quel tipo di riscontro.

C'è anche un antenato più rozzo, il Ralph loop di Geoffrey Huntley: un ciclo infinito che ridà all'agente lo stesso prompt finché il lavoro non è finito. Forza bruta e ottimismo.

Il Gauntlet Loop mette insieme le due cose e aggiunge l'ingrediente che mancava: un metro esterno. Non "migliora finché ti sembra buono", ma "migliora finché non batti questa cosa qui".

La mia prova: niente codice, una serie di email

Io l'ho applicato a un lavoro che di tecnico ha poco, almeno in superficie.

Una sequenza di email che parte quando il cliente riceve il pacco. Ogni email ha il suo giorno. Alcune partono solo se nel frattempo la persona non ha ricomprato. Una porta con sé una guida in PDF. Tutto in quattro lingue, con i link giusti per ogni negozio.

Nel prompt ho chiesto le cose del metodo: fare le verifiche, trovare benchmark veri, ricavarne i criteri, costruire, far giudicare, ripetere.

Due cose mi hanno colpito.

La prima: lavora per parecchio tempo. Non minuti. E per un bel pezzo non vedi uscire niente di finito, perché sta ancora smontando il problema e studiando i riferimenti.

La seconda: non sparisce. Prima di partire fa un piano, e il piano lo puoi seguire. Sai a che punto è, cosa ha deciso e perché, cosa aspetta da te.

È da qui che è nata la parte che mi ha cambiato davvero il modo di lavorare.

La scoperta vera: il piano vivo

Gli ho chiesto di non tenere il piano in un file Markdown da aprire in VS Code, ma di pubblicarlo come artifact: una pagina web privata che resta aperta in una scheda del browser e si aggiorna da sola ogni volta che Claude la ripubblica.

Dentro c'è tutto quello che serve per lavorare in due:

• l'elenco delle attività, una riga ciascuna, con il suo stato
• per le cose che toccano a me, le istruzioni pronte da copiare e incollare
• in cima, un riquadro datato "dove siamo", che cambia a ogni passaggio importante
• le decisioni prese, con il perché, così non si ridiscutono ogni volta

La parte bella è che la pagina si scrive a quattro mani. Se sta lavorando Claude, aggiorna lui lo stato delle righe. Se tocca a me, metto io "fatto" o "approvato" direttamente sulla pagina, dal menù della riga. Nella mia versione un'email non va in produzione finché sulla sua riga non c'è il mio ok.

Finito il lavoro, la pagina la butti. E passi all'attività successiva, con una pagina nuova.

Perché rende più di quanto sembri

Mi sono chiesto perché una cosa così semplice funzionasse così bene. Le risposte che mi sono dato sono tre.

Il piano fuori dalla conversazione non si perde. Una sessione lunga prima o poi si riempie, si riassume, perde dettagli per strada. Anthropic, raccontando come fa lavorare i suoi agenti su compiti di più giorni, usa un'immagine precisa: ingegneri che lavorano a turni, dove ognuno arriva senza memoria del turno precedente. La soluzione è lasciare tracce: un file di avanzamento, un elenco strutturato di cosa è fatto e cosa no. Notano anche che il modello tende a stravolgere meno un elenco strutturato rispetto a un testo libero. Il piano vivo è la stessa cosa, ma leggibile da una persona.

Lo stato è condiviso. Io e l'agente guardiamo la stessa pagina. Non devo chiedergli a che punto è, e lui non deve chiedermi se ho fatto la mia parte. È scritto lì.

I punti di controllo si vedono. L'autonomia va bene finché sai dove si ferma. Sulla pagina lo vedi a colpo d'occhio: queste righe le chiude lui, queste le chiudo io.

E soprattutto: non ho costruito niente. Nessun sistema, nessuna dashboard, nessuna integrazione. È lavoro agentico con zero infrastruttura. Per me è la scoperta più utile degli ultimi mesi, e credo che la userò quasi ogni giorno.

Se non usi Claude Code, la stessa idea funziona con un artifact nella chat di Claude, o anche con un documento condiviso. Meno comodo, stesso principio: il piano sta fuori dalla testa dell'agente e ci guardate in due.

Il rovescio: over-prompting

Adesso la parte che nei video virali non c'è.

Perfetti la chiama over-prompting: usare processi molto complessi per attività che non li richiedono. Non si sposta una riunione con un esercito di agenti, per capirci.

I sintomi sono tre. I primi due li descrive lui, il terzo è quello che incontro più spesso nelle aziende.

Il costo senza uscita

Un ciclo senza condizioni di uscita non converge verso la qualità: consuma finché qualcuno non lo ferma. James Altucher, rifacendo l'esperimento di Shumer, ha riportato poco più di dieci ore di lavoro e circa 1,3 milioni di token.

In abbonamento, dieci ore si mangiano i tuoi limiti di utilizzo. Con l'API a consumo, sono soldi veri. Io una regola me la sono data dopo un conto da 428 dollari in una settimana che non mi aspettavo: il lavoro in sessione sta sull'abbonamento, e tutto quello che gira da solo ha un tetto di spesa che lo blocca. Non un avviso che me lo racconta il giorno dopo: un tetto.

La direzione sbagliata, eseguita benissimo

Se l'obiettivo è vago o il riferimento è quello sbagliato, il ciclo non corregge la rotta: la percorre con più convinzione. Ore di lavoro ben fatto sulla cosa sbagliata.

C'è anche un limite meno ovvio. La stessa Decrypt fa notare che uno sparatutto in Three.js è un territorio che il modello ha visto migliaia di volte durante l'addestramento: una parte del risultato viene da lì, non dal ciclo. Su un problema davvero nuovo, senza esempi confrontabili, il critico non ha niente con cui misurare, e il metodo perde gran parte della sua forza.

Dire le cose tre volte

Sono i prompt pieni di "IMPORTANTISSIMO", "DEVI ASSOLUTAMENTE", "ricontrolla tutto due volte". Avevano senso con i modelli di un paio di anni fa, che se non alzavi la voce si distraevano.

Con quelli di oggi fanno l'effetto contrario. Anthropic lo scrive nero su bianco nella sua guida al prompting: i modelli recenti sono molto più sensibili alle istruzioni, e il linguaggio aggressivo li porta a esagerare nell'altra direzione. Il consiglio è tornare a un tono normale: "usa questo strumento quando serve", non "DEVI usarlo".

Per Opus 5 la guida dedicata è ancora più diretta. Il modello verifica il proprio lavoro senza che glielo chieda, e le istruzioni esplicite di verifica, compreso "usa un sub-agente per controllare", producono verifiche in eccesso: più token, più attesa, nessun guadagno di qualità. Stesso discorso per i sub-agenti: Opus 5 delega più volentieri dei modelli precedenti, e sui compiti piccoli questo moltiplica costi e tempi.

E poi c'è un limite fisico. Una ricerca di Chroma su 18 modelli di punta ha mostrato che le prestazioni calano man mano che l'input si allunga, anche su compiti semplici. Un prompt di tre pagine per un lavoro da tre righe non è prudenza. È rumore.

Allora il critico del Gauntlet è over-prompting?

Me lo sono chiesto anch'io, visto che sembra in contraddizione con quello che ho appena scritto.

La differenza, secondo me, è questa. "Ricontrolla" non aggiunge informazione: il modello rilegge con gli stessi occhi e gli stessi criteri. Il critico del Gauntlet porta due cose che prima non c'erano: un riferimento esterno e uno sguardo che non ha visto il ragionamento. Togli il riferimento e torna a essere un "ricontrolla" travestito. Che costa di più.

Il test dei trenta secondi

Prima di lanciare un Gauntlet mi faccio quattro domande. Se anche una sola risposta è no, scrivo un prompt normale, chiaro, e basta.

1. Esiste un riferimento che il critico può aprire? Un esempio vero, un test, uno standard scritto. Non un aggettivo.
2. Il risultato vale ore di lavoro della macchina? Un sito, una sequenza di email che girerà per mesi, un'analisi su cui si prende una decisione importante: sì. Una email singola, un riassunto, una riunione da spostare: no.
3. Il risultato si può osservare? Una pagina che si apre, un'email che arriva in casella, un test che passa. Se il critico può solo rileggere e immaginare l'effetto, giudica al buio.
4. So quando fermarlo? Un numero massimo di giri, un tetto di tempo o di spesa, e i punti in cui decido io.

C'è un modo più formale di dire la stessa cosa, che trovo utile: ogni ciclo ha bisogno di un obiettivo, una metrica e un confine. Se ne manca uno, non è un ciclo. È una speranza.

Prompt da provare

Qui sotto trovi cinque prompt nati dalla mia prova. Non sono formule magiche: sono punti di partenza da adattare. Le parti tra parentesi quadre vanno sostituite con le tue.

Li ho scritti pensando a Claude Code, che può lanciare sub-agenti e pubblicare pagine. Funzionano anche in chat: la differenza è che i giri li farai partire tu.

1. Il triage: prima di scegliere il processo

Il più sottovalutato. Serve a evitare l'over-prompting prima ancora di cominciare.

Prima di iniziare non eseguire niente: voglio capire che processo merita questo lavoro.

Il lavoro: [descrivilo in 3-4 righe, con lo scopo e chi userà il risultato].

Rispondimi in breve:
1. Quanto è grande: minuti, ore o giorni di lavoro tuo.
2. Esiste un riferimento concreto con cui confrontare il risultato? Proponine due o tre, con il link, e dimmi se riesci ad aprirli.
3. Il risultato si può verificare guardandolo (una pagina, un test, un'email in casella) o solo rileggendolo?
4. Il processo più semplice che porta a un buon risultato. Se basta un passaggio unico, dillo senza giri di parole.
5. Solo se serve davvero: in quali pezzi divideresti il lavoro, quanti giri di revisione ti aspetti e quanto tempo.

Poi aspetta che scelga io.

2. Il metro: il riferimento prima di tutto il resto

Il passaggio che quasi tutti saltano, ed è quello che decide la qualità. Due dettagli che fanno la differenza: un esempio mediocre accanto a quelli eccellenti, perché i criteri escono dal confronto, e la prova che gli esempi sono stati letti davvero.

Devo far costruire [cosa: una sequenza di email dopo l'acquisto, una landing page, un documento per il consiglio di amministrazione] per [chi lo userà].

Prima di costruire, cerca tre esempi eccellenti e uno mediocre dello stesso tipo, pubblici e recenti, nel settore [settore]. Per ognuno dammi il link e un dettaglio che si vede solo aprendolo, così so che l'hai letto davvero.

Poi trasforma la differenza tra gli eccellenti e il mediocre in criteri. Ogni criterio deve diventare una domanda a cui si risponde sì o no guardando il risultato finito. Per esempio: "Il pulsante principale si vede senza scorrere, da telefono?". Se un criterio non diventa una domanda sì o no, scartalo.

Mettili in ordine di importanza e dimmi quali tre decidono davvero la qualità.

Non costruire niente finché non ti dico quali criteri tengo.

3. Il Gauntlet leggero, per lavori che non sono codice

La versione che uso per email, documenti, presentazioni, analisi. Il critico risponde sempre nello stesso formato, giudica il risultato come lo vedrà chi lo riceve, e il budget è scritto prima di partire.

Obiettivo: [il risultato finale in 2-3 righe: cosa, per chi, a cosa serve].
Metro: i criteri che ho scelto [incollali o indica dove sono].
Vincoli fissi: [tono, lingue, dati che non vanno inventati].
Decisioni che restano mie: [per esempio sconti, promesse ai clienti, frasi che toccano salute o soldi].

Procedi così.

Dividi il lavoro in pezzi che si possano giudicare da soli e scrivili sul piano. Lavora tu sui pezzi; usa un sub-agente solo quando un pezzo è grande e non dipende dagli altri.

Per ogni pezzo, dopo la prima versione, chiama un critico che parte da zero: non ha letto questa conversazione, riceve solo il pezzo, l'esempio migliore del metro e i criteri, in ordine casuale come A e B. Il critico risponde sempre così:
VERDETTO: A o B
DIVARIO: la differenza che conta di più, in una frase
PROVA: il punto preciso che lo dimostra
Correggi solo quel divario, poi di nuovo il critico.

Quando il risultato si può vedere, il critico giudica quello e non il sorgente: per un'email la copia arrivata a [indirizzo di prova], per una pagina lo screenshot da telefono.

Budget: al massimo [3] giri per pezzo e [2 ore] in tutto. Se un pezzo esaurisce i giri, segnalo come bloccato sul piano con il divario che resta e passa al successivo. Quando arrivi a una decisione che resta mia, fermati e chiedi.

Alla fine rileggi tutto come lo vivrà chi lo riceve, nell'ordine e nei tempi reali, e sistema quello che stona tra un pezzo e l'altro.

4. Il piano vivo

Quello che ha cambiato il mio modo di lavorare. Funziona anche da solo, senza Gauntlet: ogni volta che un lavoro dura più di un'ora.

Tieni il piano di questo lavoro in un artifact: una pagina web che resto a guardare mentre lavori. Pubblicala adesso e poi aggiornala sempre allo stesso indirizzo, senza crearne di nuove.

Nella pagina:
- In cima "Dove siamo": data e ora, cosa è cambiato dall'ultimo aggiornamento, e l'unica cosa che ti serve da me in questo momento, se c'è.
- Le attività, una riga ciascuna: cosa, chi la fa (tu o io), stato (da fare, in corso, da vedere, approvato, fatto, bloccato) e una nota di una riga.
- Per ogni attività che tocca a me: i passaggi e i testi o i comandi pronti da copiare.
- Le decisioni prese, ognuna con il perché in una frase, così non le ridiscutiamo.

Regole:
- Le tue righe le aggiorni tu mentre lavori. Le mie le segno io sulla pagina: prima di ogni passaggio rileggila e riparti da lì.
- "Approvato" lo metto solo io, e quello che aspetta la mia approvazione non va avanti.
- Le righe chiuse non si cancellano: vanno in fondo, così resta la storia.
- Sulla pagina niente password, chiavi o dati personali dei clienti.

E quando riprendi il giorno dopo, in una sessione nuova, basta questo:

Leggi la pagina del piano [link]. Dimmi in tre righe dove siamo, cosa ho cambiato io dall'ultima volta e qual è il prossimo passo. Poi riparti da lì.

5. Il critico a contesto pulito, fatto a mano

Per chi non usa agenti, o vuole capire il meccanismo prima di automatizzarlo. Servono due chat separate: in una costruisci, nell'altra, nuova, giudichi. La seconda non deve sapere niente della prima.

Ti do due versioni dello stesso [tipo di contenuto], A e B. Non ti dico da dove vengono.

Lo scopo: [a cosa serve e per chi, in una riga].

A:
[incolla qui]

B:
[incolla qui]

Dimmi quale delle due funziona meglio per quello scopo, con una lettera sola: A o B.
Poi, per quella che perde, indica il divario più importante rispetto all'altra, con un esempio preciso preso dal testo. Uno solo. Non riscrivere niente.

Metti in una delle due posizioni l'esempio eccellente trovato con il prompt 2, e tra un giro e l'altro scambia A e B. È documentato che i modelli usati come giudici tendono a favorire una delle due posizioni, a prescindere dal contenuto.

Cosa non trovi in questi prompt, di proposito

Niente maiuscole, niente "è fondamentale", niente "ricontrolla tutto". Nessun "non fermarti finché non è perfetto" senza un tetto. Nessun sub-agente per i lavori piccoli.

Non è pigrizia: è il punto dell'articolo.

Cosa resta a noi

A lavoro finito, la sensazione più strana è stata questa: la macchina aveva lavorato tantissimo, ma i momenti che contavano erano pochi, ed erano miei.

Scegliere il riferimento. Approvare il metro. Dire sì o no su una promessa fatta ai clienti. Decidere che un pezzo era abbastanza buono e che il quarto giro non serviva.

Perfetti chiude la sua newsletter dicendo che scegliere il riferimento è un atto di gusto e decidere quando fermarsi è un atto di giudizio. Sono d'accordo, e aggiungo una cosa sola: gusto e giudizio hanno bisogno di vedere cosa sta succedendo. Per questo, prima ancora del Gauntlet, mi tengo il piano vivo.

La mia regola, da qui in avanti:

• un prompt chiaro per quasi tutto
• il piano vivo per ogni lavoro che dura più di un'ora
• il Gauntlet per le poche cose che valgono ore di lavoro e hanno un riferimento vero

E tu, quale lavoro lasceresti girare per una notte intera? E quale, invece, stai complicando senza bisogno?