Il Ciclo Ralph Wiggum, Dai Primi Principi

Se hai utilizzato un agente di codifica IA per più di qualche ora, conosci il “muro”: l’agente compie progressi visibili, poi si blocca — e finisci per dover correggere e completare il lavoro da solo.

Come spesso accade agli ingegneri IA, è emerso un modello per risolvere quel problema: basta far iterare l’agente con controlli esterni finché il lavoro non viene effettivamente superato.

L’approccio ha preso piede così tanto che ha ricevuto un nome — Ralph Wiggum.

E il meme ha preso piede perché il modello funziona. Entro la fine del 2025, Anthropic aveva formalizzato il tutto in un plugin ufficiale di Claude Code.

Ralph rappresenta un cambiamento nel modo in cui gli sviluppatori utilizzano gli strumenti esistenti. Invece di trattare i sistemi IA come assistenti interattivi, vengono eseguiti come processi a lunga durata, guidati da test, linters e condizioni di arresto esplicite.

Quindi questa breve guida è la versione pratica. Vedremo cos’è realmente Ralph, perché funziona, come si è diffuso, e cosa è cambiato quando è stato commercializzato.

Cos’è Veramente “Ralph”?

Alla sua base, questo è ciò che Ralph rappresenta: eseguire un agente in un ciclo, verificare l’output contro qualcosa che non può mentire come un test, un linter, un controllo dei tipi; e continuare a ciclare fino a quando non supera.

Ecco fatto.

L’esempio originale che Geoffrey Huntley ha condiviso nel luglio 2025 era intenzionalmente diretto:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude le varianti di codice seguono la stessa forma, solo con più protezioni. Ma il principio non cambia: inserisci un prompt fissato nell’agente ripetutamente finché la realtà esterna non dice che hai finito.

Il ciclo in sé è quasi irrilevante, e ciò che conta è il contratto:

• Lo stato vive nel repository: File, differenze, log, cronologia git; tutto ciò che è durevole va qui.
• Il completamento vive al di fuori del modello: Test, linter, verificatori di tipo; l’agente non decide quando ha finito; lo fa l’infrastruttura.
• L’agente è sostituibile: È un lavoratore invocato ripetutamente fino a quando il controllo non viene superato; se oggi è lento o stupido, sostituiscilo domani con qualcosa di più veloce.

Visto in questo modo, Ralph diventa un principio di design: smetti di chiedere al modello di sapere quando ha finito. Smetti di aspettarti che ricordi le restrizioni dopo i reset di contesto.

Invece, costruisci il sistema in modo che il modello non possa fallire in quei modi.

Perché Il Ciclo Resiste?

Alcuni motivi:

1. Le Finestre di Contesto si Comportano Come Buffer

Huntley inquadra spesso le finestre di contesto in termini di basso livello:

“Pensa come un ingegnere C o C++. Le finestre di contesto sono array.”

Hanno una dimensione fissa; scorrono; sovrascrivono; dimenticano.

Le sessioni di lunga durata presuppongono una continuità che non esiste, quindi trattare il buffer come memoria duratura porta a deviazioni, vincoli mancati e comportamenti incoerenti.

Ralph si immerge nella realtà del sistema. Piuttosto che fingere che la finestra di contesto sia stabile, la tratta come se fosse usa e getta.

Lo spazio di lavoro temporaneo dell’agente viene resettato tra un’iterazione e l’altra, mentre lo stato persistente rimane su disco. Il repository accumula verità attraverso le esecuzioni. Questo rende la riattivazione dell’agente una routine piuttosto che uno spreco; ogni ciclo inizia da zero ma si basa su ciò che è effettivamente persistito.

2. I Controlli Esterni Superano Il Ragionamento Interno

Molti framework di agenti rispondono al fallimento aggiungendo struttura all’interno del modello: pianificatori, riassunti, stato interno e cicli di riflessione.

Ralph mantiene l’intelligenza fuori dall’agente. Si basa su:

• Una specifica fissata che non si sposta
• Prove concrete dall’ultimo esecuzione
• Un cancello deterministico che valuta il successo

L’agente non decide quando il lavoro è finito – lo fa l’arnese.

Ecco perché Ralph eccelle nel lavoro meccanico: refactoring, migrazioni, pulizia, compiti di conformità… Ovunque il successo possa essere misurato da uno script piuttosto che dal giudizio, l’iterazione diventa affidabile.

Il modello non può sottrarsi ai requisiti perché i requisiti esistono esternamente al suo ragionamento.

3. La Compattazione Erode i Vincoli

Una critica ricorrente di Huntley prende di mira la sintesi e la compattazione.

Quando un sistema chiede al modello di decidere cosa è abbastanza importante da conservare, si perdono informazioni — le restrizioni si attenuano, i casi limite scompaiono e i perni cadono.

Ralph elude questo mantenendo gli input letterali:

• Le specifiche rimangono verbatim invece di essere riassunte, 
• L’output di errore rimane grezzo e non filtrato; e 
• La cura della memoria non passa mai nel modello.

Il sistema mantiene la fedeltà; l’agente opera all’interno di esso, limitato da ciò che è effettivamente presente piuttosto che da ciò che il modello pensa dovrebbe esserci.

Quindi, Come Si È Diffusa L’Idea?

La tempistica è piuttosto compressa.

• 19 Giugno 2025: Durante un incontro a San Francisco di circa 15 ingegneri che discutono di codifica agente, Huntley presenta Ralph, Cursed (il linguaggio di programmazione creato da Ralph) e trasmette in diretta la codifica autonoma durante la notte mentre dorme in Australia. La stanza ha una conversazione inquietante su quanto sia facile copiare l’80%-90% di un SaaS e su quanti tipi di lavoro stanno per scomparire completamente.
• Luglio 2025: Huntley pubblica il post originale sul blog con la struttura base del loop bash. L’articolo include un esempio di prompt leggero e una richiesta: “potresti probabilmente trovare il repo di cursed lang su github se lo cercassi, ma per favore non condividerlo ancora.”
• Agosto 2025: Si svolge l’hackathon degli agenti di YC — i team eseguono Claude Code in loop continui. Il risultato è 6 repository realizzati in una notte. Dexter Horthy esegue un loop sperimentale di Ralph su un refactoring di codice React. In oltre 6 ore, sviluppa un completo piano di refactoring ed esegue l’implementazione.
• Settembre 2025: Huntley lancia ufficialmente Cursed Lang, il linguaggio di programmazione che Ralph ha creato. Esiste in tre implementazioni (C, Rust, Zig), ha una libreria standard e un compilatore di secondo livello scritto in Cursed stesso.
• Ottobre 2025: Dexter presenta Ralph a Claude Code Anonymous a San Francisco. La domanda del pubblico: “Quindi lo consigli?” La sua risposta: “Le cose stupide possono funzionare sorprendentemente bene. Cosa potremmo aspettarci da una versione intelligente?”
• Dicembre 2025: Anthropic lancia un plugin ufficiale di Ralph Wiggum. Il plugin prende il loop bash di Huntley e lo formalizza con Stop Hooks e dati strutturati di fallimento.
• Gennaio 2026: Huntley e Horthy fanno un’analisi approfondita su YouTube confrontando l’implementazione originale del loop bash di Ralph con l’implementazione degli stop-hook di Anthropic.

Bash-loop Ralph vs. Plugin Ralph

L’originale Ralph è un ciclo bash di 5 righe. Fai un cat di un file di prompt, lo invii a Claude, controlli se l’output supera il tuo test e continui fino a quando non lo fa. Tutto è memorizzato su disco, tutto è visibile. Se qualcosa si rompe, puoi vedere esattamente perché.

Il plugin Antropico inverte quel modello, quindi invece di eseguire il ciclo dall’esterno, installa un Stop Hook all’interno della tua sessione Claude. Quando Claude tenta di uscire, il gancio lo intercetta, verifica le tue condizioni di completamento e reinserisce lo stesso prompt se rimane del lavoro. I file modificati da Claude sono ancora lì.

La cronologia di git è ancora presente, ma i meccanismi del harness sono ora opachi — nascosti in un file di stato markdown, sensibili ai permessi, facili da danneggiare se non sai cosa stai facendo.

Questo è il classico compromesso dell’astrazione.

Il plugin riduce il costo di adozione. Non devi scrivere bash e non devi pensare ai cicli. Ma mentre il meccanismo si nasconde, l’intuizione originale diventa più facile da trascurare.

La versione bash-loop ti obbliga a progettare il sistema di supporto. La versione del plugin ti permette di saltare quel passaggio, il che va bene fino a quando non incontri un caso limite e non riesci a vedere cosa sta effettivamente succedendo.

Dexter Horthy lo ha testato e ha scoperto che si blocca in modi criptici a meno che non si usi “–dangerously-skip-permissions.” Il plugin installa hook in posti strani, utilizza file di stato opachi e se cancelli il file markdown prima di fermarlo, rompi Claude in quel repository finché non disabiliti completamente il plugin.

Allora, qual è la lezione? Entrambi funzionano, ma funzionano per motivi diversi. Il ciclo bash funziona perché è semplice e trasparente. Il plugin funziona quando l’astrazione non nasconde qualcosa di critico.

Cosa Apprendi Dal Gestirlo?

Ralph presuppone una distanza tra l’umano e l’agente. Non ti siedi nella sessione e lo guidi. Invece, lo avvii, ti allontani, ispezioni i manufatti quando finisce e aggiusti i vincoli per la prossima iterazione.

L’interazione avviene a livello di harness — il prompt, i test, le condizioni di arresto — non all’interno della conversazione.

Con il tempo, emerge un modello: la maggior parte dei fallimenti non sono fallimenti del modello; sono fallimenti del sistema.

Le specifiche erano vaghe, il test era troppo generico, o la condizione di completamento non descriveva realmente cosa significa “completato”.

Una volta che lo vedi qualche volta, il tuo istinto cambia. Smetti di chiederti “come posso rendere Claude più intelligente?” e inizi a chiederti “come posso rendere i vincoli più stretti?”

Qui le specifiche diventano fondamentali.

Specifiche Come Superfici Di Controllo

Huntley ridefinisce le specifiche non come documentazione ma come input di controllo fissi. Le produci attraverso una conversazione con Claude, le modifichi deliberatamente fino a quando non sono precise e poi le fissi. Una volta fissate, non cambiano per l’intero ciclo.

Questo è importante perché le specifiche fanno tre cose contemporaneamente:

1. Limitano ciò che l’agente può inventare: Senza una specifica precisa, Claude aggiungerà strati di protezione, astrazioni o funzionalità che non hai mai richiesto, espandendo l’ambito con ogni iterazione. 
2. Stabiliscono ricerca e recupero: Così l’agente non allucina nuovi requisiti.
3. Stabilizzano il comportamento attraverso le iterazioni: Ogni iterazione risolve lo stesso problema, non una interpretazione leggermente diversa di esso.

Se la tua specifica è vaga riguardo al significato di “fatto”, l’agente lo interpreterà diversamente ad ogni ciclo. Finirai per avere una deriva, espansione degli obiettivi e iterazioni che si contraddicono a vicenda.

Come Gestisci Il Ciclo Responsabilmente?

Una configurazione minima di Ralph spesso appare come:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

La meccanica del ciclo conta molto meno delle regole che lo circondano:

• Mantieni la specifica immutabile; non modificarla a metà ciclo basandoti su quello che fa Claude. 
• Codifica il completamento come controlli eseguibili.
• Impone limiti di iterazione e limiti di tempo in modo che il ciclo non possa durare per sempre e consumare il tuo budget di token. 
• Conserva i log e le differenze in modo che tu possa ispezionare cosa è andato storto se succede. 

Inoltre, la pratica operativa ha rivelato alcune euristiche importanti:

• Preferisci piccole, regolari modifiche piuttosto che grandi ristrutturazioni, perché i grandi cambiamenti accumulano errori e sono più difficili da debuggare.
• Riesegui sul main attuale piuttosto che fare rebase, perché i conflitti di merge sprecano iterazioni.
• Evita di usare Ralph per lavori esplorativi, perché se non hai test di accettazione chiari, otterrai solo un ciclo caotico che inventa cose che non hai chiesto.

Il vincolo è la funzionalità.

Il Loop È la Lezione

Mentre Ralph guadagnava terreno, sono emerse variazioni. Alcuni team hanno costruito cicli esterni strutturati intorno agli agenti che utilizzano gli strumenti. Altri hanno aggiunto componenti verificatori separati: un modello diverso che esamina l’output del lavoratore prima che il ciclo decida di terminare. Queste estensioni funzionano, sì, ma solo se rispettano l’intuizione originale.

La regola è semplice: la verifica deve rimanere deterministica, e i riassunti non devono mai sostituire gli input primari.

• Se aggiungi un verificatore, dovrebbe controllare cose concrete: i test passano, il linter termina correttamente, il git diff corrisponde alle aspettative. 
• Se aggiungi cicli esterni strutturati, dovrebbero comunque vedere l’output grezzo e i log grezzi, non un riassunto pulito di ciò che è andato storto. 

L’argomento principale di Huntley è che lo sviluppo di software come professione è effettivamente morto, ma l’ingegneria del software — la pratica di costruire sistemi bene — è più viva che mai.