Ralph Wiggum Coding: Il Loop È Facile. I Prompt Sono Tutto.

Se recentemente è stato vicino al mondo dello sviluppo AI su Twitter, l’avrà visto: l’approccio Ralph Wiggum al coding.

Chiamato così dal personaggio dei Simpson che non smette mai di provare nonostante i continui fallimenti, la tecnica è disarmante nella sua semplicità. Si esegue un agente di AI coding in loop. Lo si lascia fallire. Lo si lascia riprovare. Si continua fino al successo o fino al raggiungimento di un limite.

I risultati sono stati sorprendenti. Geoffrey Huntley, che ha sviluppato l’approccio, ha consegnato un contratto da $50.000 per $297 di costi API. Boris Cherny, che ha creato Claude Code, ha ottenuto 259 PR in 30 giorni, ogni riga scritta dall’IA. Anthropic ha rilasciato un plugin ufficiale.

I post virali si concentrano sul loop. Sullo script bash. Sull’automazione notturna.

Stanno perdendo il punto.

Il loop è banale

Ecco l’intera tecnica:

while :; do cat PROMPT.md | claude ; done

Questo è tutto. La può scrivere in trenta secondi.

Allora perché alcuni sviluppatori ottengono risultati trasformativi mentre altri bruciano crediti API guardando un agente girare in circolo?

La risposta non è il loop. È quello che gli si dà in pasto.

La qualità dei prompt è la vera chiave

La documentazione ufficiale lo dice direttamente: “Il successo con Ralph dipende dallo scrivere buoni prompt, non solo dall’avere un buon modello.”

La maggior parte della copertura si ferma a “essere specifici” e “includere criteri di completamento.” Questo è il minimo sindacale. Gli sviluppatori che ottengono risultati seri operano a un livello diverso.

Consideri:

Un prompt che fallirà:

Costruisci una API per todo e rendila buona.

Un prompt che funziona:

/ralph-wiggum:ralph-loop "Implementa API REST per elementi todo.

Requisiti:
- Endpoint CRUD per todos
- Validazione input su tutti i campi  
- Gestione errori con codici di stato HTTP appropriati

Criteri di successo:
- Tutti gli endpoint rispondono correttamente
- Test superati con >80% di copertura  

Dopo 15 iterazioni se non completato:
- Documenta problemi bloccanti
- Elenca approcci tentati

Output <promise>COMPLETE</promise> quando fatto." --max-iterations 30

Il secondo prompt fa tre cose che il primo non fa: definisce chiaramente il successo, dice all’agente come verificare il suo lavoro, e include istruzioni su come fallire utilmente.

Quest’ultima parte è ciò che separa i buoni prompt da quelli eccellenti.

La gerarchia della qualità dei prompt

Dopo aver eseguito questi loop su più progetti, penso alla qualità dei prompt in tre livelli:

Livello 1: Criteri di completamento. L’agente sa quando fermarsi. La maggior parte delle persone arriva qui.

Livello 2: Auto-verifica. L’agente può controllare il proprio lavoro. Boris Cherny la chiama “probabilmente la cosa più importante.” Si dia a Claude un modo per verificare il suo output, e la qualità raddoppia.

Livello 3: Recupero da fallimento. Il prompt include cosa fare quando si blocca. Non solo “riprova,” ma passi diagnostici, approcci alternativi, e degradazione controllata. È qui che risiede la vera leva, e quasi nessuno ne parla.

La maggior parte dei fallimenti avviene perché i prompt funzionano per il percorso felice ma non hanno strategia di recupero. L’agente si blocca, gira per 50 iterazioni, e non produce nulla di utile.

Un prompt ben progettato tratta il fallimento come informazione. Invece di perdere due ore, si perdono due ore con qualcosa da mostrare.

La verità controintuitiva

Ecco cosa i post virali non menzionano: stipare più dettagli nel proprio prompt spesso peggiora le cose.

La ricerca suggerisce che l’utilizzo ottimale del contesto è 40-60%. Si spinga oltre, e le prestazioni del modello si degradano su tutto, non solo sulle nuove istruzioni.

I professionisti che ottengono risultati consistenti mantengono i loro prompt snelli. Dicono a Claude come trovare le informazioni piuttosto che stipare tutto in anticipo. Spezzano compiti grandi in loop più piccoli.

Più dettagli sembrano più controllo. Con gli LLM, c’è un punto dove più dettagli diventano meno capacità.

Verso dove si sta dirigendo

Ecco cosa credo: siamo all’inizio della comprensione di come lavorare con questi sistemi.

Attualmente, la maggior parte delle persone pensa che il collo di bottiglia sia la capacità del modello. Non lo è. Il collo di bottiglia è la nostra capacità di comunicare l’intento abbastanza chiaramente che una macchina possa agire autonomamente. È un’abilità. E come ogni abilità, le persone che la sviluppano presto avranno un vantaggio enorme.

La tecnica Ralph Wiggum è una finestra su quel futuro. Non perché il loop sia intelligente, ma perché espone, spietatamente, se i suoi prompt sono davvero buoni. Ogni iterazione fallita è feedback. Ogni esecuzione riuscita è evidenza che ha imparato a pensare in modo che le macchine possano eseguire.

Gli sviluppatori che trattano questo come un trucco con script bash stanno perdendo il cambiamento più grande. Quelli che lo trattano come una nuova disciplina per la collaborazione uomo-macchina costruiranno cose che il resto di noi non può ancora immaginare.

Il loop è facile. I prompt sono tutto.

---

Stiamo usando queste tecniche per accelerare lo sviluppo su più progetti. Se sta affrontando sfide simili, ci contatti.