Ralph Loop: quando il tuo assistente AI smette di dire “ho finito” e inizia davvero a finire

Mani avanti: questo non è l’ennesimo post su come l’AI ti cambierà la vita. È un tutorial pratico su come farla smettere di prenderti in giro.

Se hai mai usato Claude Code, Copilot o qualsiasi altro assistente AI per scrivere codice, conosci questa scena: gli chiedi di implementare una feature, AI parte a razzo, scrive codice che sembra sensato, poi ti dice “Ecco fatto!” con la soddisfazione di un bambino che ha apparecchiato la tavola dimenticando i bicchieri.

Tu guardi. Manca metà della roba. I test non passano. Quella dipendenza che doveva aggiornare? Dimenticata.

Il problema non è che l’AI sia stupida. Il problema è che non sa quando ha finito. O meglio: sa benissimo quando pensa di aver finito, ma quel momento non coincide quasi mai con quando ha veramente finito.

Ralph Loop risolve esattamente questo.

Cos’è Ralph Loop

Qualcuno l’ha definito “the biggest name in AI right now”. Un personaggio dei Simpson che mangia la colla è diventato il volto del coding autonomo. Questo un po’ mi spaventa…

Il pattern si chiama così perché l’AI fa esattamente come Ralph: dichiara “Ho finito!” con la stessa sicurezza con cui Ralph Wiggum annuncia le sue perle di saggezza, ovvero senza la minima consapevolezza che stia dicendo una cazzata.

La storia inizia nel maggio 2025 con Geoffrey Huntley, uno sviluppatore australiano ritiratosi in campagna ad allevare capre. Frustrato dal collo di bottiglia del “human-in-the-loop”, che di fatto lo obbligava a ri-promptare (😁) manualmente ogni errore, ha creato uno script bash di 5 righe. L’ha chiamato Ralph Wiggum e come ogni scherzo che abbia un senso, è diventato virale.

“Ralph is a Bash loop”. questa frase è diventata un mantra. Boris Cherny, Head of Claude Code in Anthropic, ha poi formalizzato il metodo come plugin ufficiale a fine 2025. Ryan Carson l’ha implementato in un repo che ha già fatto 10.7K+ stelline.

L’idea è disarmante nella sua semplicità:

while :; do 
  cat PROMPT.md | claude-code --continue 
done

Un loop infinito che continua a far girare l’AI finché non soddisfa criteri oggettivi di completamento. Non “mi sembra di aver finito”. Solo se proprio “tutti i test passano, tutti gli acceptance criteria sono verificati, allora posso andare a casa”.

La magia sta in come l’AI mantiene la memoria tra un’iterazione e l’altra, visto che ogni volta parte con il contesto pulito.

La filosofia: naive persistence

Quello che rende Ralph diverso da altri approcci è la sua filosofia brutale: naive persistence.

Il feedback non viene sanitizzato. L’output del modello (errori, stack trace, allucinazioni e tutto il resto) viene ripompato nell’input dell’iterazione successiva. Huntley lo chiama “contextual pressure cooker” (una pentola a pressione contestuale).

Il LLM non viene schermato dai propri errori, anzi deve mangiarsi tutto compreso lo stack trace, le allucinazioni, il codice non funzionante o rotto. Viene costretto a confrontarsi con i propri errori, iterazione dopo iterazione, finché non trova la soluzione corretta.

Come ha scritto Huntley: “Building software with Ralph requires a great deal of faith and a belief in eventual consistency. Ralph will test you. Every time Ralph has taken a wrong direction, I haven’t blamed the tools; instead, I’ve looked inside. Each time Ralph does something bad, Ralph gets tuned — like a guitar.”

“Costruire software con Ralph richiede un atto di fede e la fiducia che, prima o poi, i pezzi andranno a posto. Ralph ti mette alla prova. Ogni volta che ha preso una strada sbagliata, non me la sono presa con gli strumenti, mi sono fatto un esame di coscienza. E ogni volta che Ralph sbaglia, lo si accorda, come si fa con una chitarra.“

Insomma è un mix di brute force e persistenza, dal design inefficiente e che proprio nei task complessi, ha rivelato che la testardaggine è una qualità preziosa.

Il problema che risolve Ralph

Ho identificato quattro problemi (le vuoi chiamare frustrazioni??) ricorrenti che probabilmente hai ben note se sei un vibecoder:

1. Uscita prematura. L’AI si ferma quando ritiene di aver fatto “abbastanza”. Un po’ come il collega che manda la mail con il report “quasi finito” venerdì alle 17:58.

2. Fragilità del singolo prompt. Task complessi non si completano con un prompt. Richiedono tre, cinque, dieci interventi. Ogni volta devi rispiegare il contesto.

3. Rottura del contesto. Dopo un restart, ti tocca ricominciare da zero per buona pace dei 200.000 token della finestra di contesto. “Come ti chiami? Cosa stiamo facendo? Perché esisto?”

4. Costo del re-prompting. Ogni redirect manuale ti costa tempo. E pazienza. E capelli (chissà perchè cito questo aspetto?).

Il problema di fondo?

Il meccanismo di auto-valutazione degli LLM è fondamentalmente inaffidabile. I Large Language Model escono quando soggettivamente pensano di aver completato. Non quando soddisfano standard oggettivamente verificabili.

Ralph Loop sposta la verifica dal “penso di aver finito” al “i test sono passati”.

Due metodi di implementazione

Esistono due modi per far girare Ralph:

1. Il plugin ufficiale Anthropic

Usa uno stop hook che intercetta quando Claude prova a uscire e re-inietta il prompt. Tutto gira nella stessa context window.

/ralph-loop "Il tuo task" --max-iterations 20 --completion-promise "COMPLETE"

Pro: comodo, integrato, facile da usare.

Contro: dopo 15-20 iterazioni il contesto si gonfia, il modello inizia a “dimenticare” le cose vecchie, e le allucinazioni aumentano. È il problema del context bloat.

2. Il bash loop originale (metodo Huntley)

Ogni iterazione genera (anche se i dev fighi su Linkedin avrebbero detto spawna) una nuova context window pulita. La memoria persiste solo via file (git, progress.txt, prd.json).

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

Pro: zero bagaglio dalle iterazioni precedenti, ideale per task lunghi.

Contro: setup più manuale.

La regola pratica:

• Task brevi (< 15 iterazioni) → plugin
• Task lunghi (overnight, refactoring massivi) → bash loop

Per i loop notturni che devono girare per ore, il bash loop è l’unica scelta sensata.

Come funziona il Ralph Loop

Ogni volta che il loop gira, parte una nuova sessione di Claude (o Amp o altro su una CLI) pulita che non si ricorda niente di quello che ha fatto prima.

A prima vista sembra uno svantaggio enorme, ma non è così: se l’iterazione 3 è andata a rotoli, l’iterazione 4 non si porta dietro tutto il casino. Parte fresca, legge i file, capisce a che punto è il lavoro, e riprende da lì.

In pratica è come avere un collega con l’Alzheimer selettivo: dimentica gli errori, ma legge gli appunti.

La memoria persiste via file

Ralph usa tre file persistenti:

• git history: i commit delle iterazioni precedenti
• progress.txt: appunti e pattern scoperti dall’AI
• prd.json: lo stato dei task (fatto/non fatto)

L’AI legge questi file, capisce a che punto è il lavoro, prende il prossimo task con passes: false, lo implementa, verifica che i test passino, committa, aggiorna lo stato.

Ripete finché tutto ha passes: true.

Quando tutte le story sono complete, emette un segnale specifico:

<promise>COMPLETE</promise>

E il loop si ferma.
In pratica è come avere un collega con l’Alzheimer selettivo che dimentica gli errori, ma legge gli appunti.

Compatibilità tool

Ralph Loop è agnostico rispetto al tool. Funziona con qualsiasi AI coding assistant che possa scrivere file, fare commit git, e accettare input da riga di comando:

Tool	Funziona	Note
Claude Code	✅Si	Supportato nativamente nel repo ufficiale
Amp	✅Si	È il default nel repo snarktank/ralph
GitHub Copilot CLI	✅Si	Devi adattare lo script
Codex CLI	✅Si	OpenAI ha una CLI, funziona
Aider	✅Si	Molto usato, si integra bene
Cursor	⚠️Parziale	Non ha una vera CLI, devi usare workaround
ChatGPT web	❌No	Non ha accesso al filesystem

La struttura del prd.json

Il cuore di tutto è un file JSON che descrive cosa deve essere fatto. Niente di esoterico:

{
  "name": "Task Priority System",
  "branchName": "ralph/task-priority",
  "description": "Add priority levels to tasks",
  "userStories": [
    {
      "id": "US-001",
      "title": "Add priority field to database",
      "description": "As a developer, I need to store task priority.",
      "acceptanceCriteria": [
        "Add priority column: 'high' | 'medium' | 'low' (default 'medium')",
        "Generate and run migration successfully",
        "Typecheck passes"
      ],
      "priority": 1,
      "passes": false,
      "notes": "",
      "dependsOn": []
    },
    {
      "id": "US-002",
      "title": "Display priority badge on task cards",
      "description": "As a user, I want to see task priority at a glance.",
      "acceptanceCriteria": [
        "Badge shows colored indicator (red=high, yellow=medium, gray=low)",
        "Badge visible without hovering",
        "Typecheck passes",
        "Verify in browser"
      ],
      "priority": 2,
      "passes": false,
      "notes": "",
      "dependsOn": ["US-001"]
    }
  ]
}

I campi importanti:

Campo	Cosa fa
passes	`false` = da fare, `true` = completato e verificato
dependsOn	Story che devono essere completate prima
acceptanceCriteria	Criteri verificabili — l’AI deve poter dire sì/no
notes	Appunti aggiunti dall’AI durante l’esecuzione

Setup e configurazione

Bando alle chiacchiere. Ecco come farlo funzionare.

Prerequisiti

• Claude Code (npm install -g @anthropic-ai/claude-code) oppure Amp
• jq (brew install jq su macOS, apt install jq su Linux)
• Un repository git (sì, serve git)

Nota per Windows: il plugin richiede jq che su Windows/Git Bash non è installato di default. Usa WSL oppure installa jq separatamente.

Installazione

# Dalla root del tuo progetto
mkdir -p scripts/ralph

# Scarica i file da github.com/snarktank/ralph
# oppure copia manualmente ralph.sh e CLAUDE.md

chmod +x scripts/ralph/ralph.sh

Esecuzione

# Default: 10 iterazioni con Claude Code
./scripts/ralph/ralph.sh --tool claude

# 25 iterazioni (per feature più complesse)
./scripts/ralph/ralph.sh --tool claude 25

# Con Amp invece di Claude
./scripts/ralph/ralph.sh 25

Sandbox per lavorare in sicurezza

Ralph gira in autonomia e può fare commit, modificare file, eseguire comandi. Se qualcosa va storto, può fare danni. Gli esperti di sicurezza consigliano sempre di eseguire le sessioni Ralph in ambienti sandboxed (come VM cloud usa e getta) per evitare che l’AI cancelli accidentalmente file locali.

Regola aurea: per i loop AFK (quelli che lanci e vai a dormire), usa sempre una sandbox.

# Lancia Claude Code in sandbox
/sandbox

# Oppure in un container Docker
docker run -it --rm -v $(pwd):/workspace claude-code

Dentro la sandbox, Ralph può modificare solo i file del progetto. Non tocca la tua home directory, le chiavi SSH, o i file di sistema.

Configura i permessi in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read files in /workspace",
      "Write files in /workspace", 
      "Execute npm commands",
      "Execute git commands"
    ],
    "deny": [
      "Network requests to external URLs",
      "Access to ~/.ssh",
      "Access to ~/.aws"
    ]
  }
}

Per i loop Human-in-the-Loop (quelli dove un umano guarda cosa fa la IA) la sandbox è opzionale. Per quelli AFK è assolutamente obbligatoria.

Controllo costi: il max-iterations è il tuo salvagente

Ralph può girare all’infinito se non lo fermi. E “infinito” significa bollette a tre zeri.

Imposta sempre un limite di iterazioni:

# 10-20 iterazioni per iniziare (consigliato)
./ralph.sh --tool claude 15

# Mai più di 50 senza un buon motivo

Il --max-iterations è il tuo meccanismo di sicurezza primario. Il --completion-promise (il segnale di stop tipo <promise>COMPLETE</promise>) usa matching esatto di stringa — se il modello scrive “COMPLETED” invece di “COMPLETE”, non si ferma.

Regola pratica: guarda le prime 2-3 iterazioni per verificare che tutto funzioni, poi lascialo andare.

Cinque regole d’oro

Dopo aver fatto girare Ralph su diversi progetti, ho capito che funziona bene solo se rispetti alcune regole. Non sono suggerimenti. Sono requisiti.

1. Story piccole

Ogni story deve essere completabile in una singola context window. Se è troppo grande, l’LLM esaurisce il contesto prima di finire e produce codice rotto.

Dimensioni giuste:

• Aggiungere una colonna al database + migration
• Aggiungere un componente UI a una pagina esistente
• Aggiornare una server action
• Aggiungere un filtro dropdown

Troppo grandi (spezza in più story):

• “Build the entire dashboard”
• “Add authentication”
• “Refactor the API”

Regola pratica: se non riesci a descrivere il cambiamento in 2-3 frasi, è troppo grande.

2. Acceptance criteria verificabili

L’AI deve poter rispondere sì/no. Mai criteri vaghi.

Buoni:

• “Add status column to tasks table with default ‘open'”
• “Filter dropdown has options: All, Open, Closed”
• “Clicking delete shows confirmation dialog”
• “Typecheck passes”

Pessimi:

• “Works correctly”
• “User can do X easily”
• “Good UX”
• “Handles edge cases”

Questi ultimi sono criteri per umani, non per macchine.

3. Feedback loops obbligatori

Ralph funziona solo se ci sono verifiche automatiche:

• Typecheck cattura errori di tipo
• Test verificano il comportamento
• Lint mantiene la qualità
• CI deve restare verde

Se non hai test, Ralph non può sapere se ha rotto qualcosa. E romperà qualcosa.

4. progress.txt è la memoria

Dopo ogni iterazione, Ralph aggiorna un file di testo con:

• Pattern scoperti (“this codebase uses X for Y”)
• Trappole (“do not forget to update Z when changing W”)
• Contesto utile (“the settings panel is in component X”)

Questo file viene committato e letto dalle iterazioni successive. È la memoria a lungo termine del sistema.

Non tenerlo per sempre. Una volta finito lo sprint, cancellalo. È specifico della sessione, non documentazione permanente.

5. Auto-validazione: dota la IA di occhi per vedere cosa fa

Il modello può scrivere codice, ma come fa a sapere se l’UI funziona davvero? Dagli la possibilità di verificare il suo lavoro.

Opzione A: Claude for Chrome (per loop interattivi) Permette all’agente di aprire il browser, navigare, prendere screenshot, controllare la console.

Opzione B: Playwright MCP (per loop headless) Per i bash loop notturni che girano senza display:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--headless"]
    }
  }
}

Con questo setup, Ralph può lanciare il browser in headless, navigare alle pagine che ha modificato, fare screenshot per verificare il layout, controllare i log della console per errori JS.

Senza questa capacità di auto-validazione, Ralph implementa feature “alla cieca” e le dichiara complete basandosi solo sui test — che potrebbero non coprire l’UI.

I due rischi: overcooking e undercooking

Come per la cottura, anche con Ralph puoi sbagliare in due direzioni:

Overcooking: lasci il loop troppo a lungo. L’AI inizia ad aggiungere feature che nessuno ha chiesto, a fare refactoring di codice che andava bene, a scrivere documentazione per il gusto di farlo. Quando torni hai un progetto irriconoscibile.

Undercooking: premi Ctrl+C troppo presto. Ti ritrovi con feature a metà, codice che non compila, test che falliscono.

La soluzione? --max-iterations ragionevole + prime 2-3 iterazioni monitorate + criteri di completamento chiari.

Quando qualcosa non va (e qualcosa non andrà):

# Vedere quali story sono completate
cat prd.json | jq '.userStories[] | {id, title, passes}'

# Leggere i learnings delle iterazioni precedenti
cat progress.txt

# Controllare la git history
git log --oneline -10

Modalità: AFK vs Human-in-the-Loop

Human-in-the-Loop (HITL)

Guardi ogni iterazione, intervieni se serve. È pair programming con un collega instancabile.

# Script che fa una sola iterazione
./ralph-once.sh
# Guardi l'output, decidi se continuare
./ralph-once.sh

Usa HITL quando:

• Stai imparando come funziona Ralph
• Il task richiede decisioni creative
• Non ti fidi ancora del prompt

AFK (Away From Keyboard)

Lanci e vai a fare altro. O a dormire.

# Lancia in background con log
nohup ./ralph.sh 50 > ralph.log 2>&1 &

# Controlla dopo
tail -100 ralph.log

Usa AFK quando:

• Il prompt è già testato e funziona
• Il task è meccanico e ripetitivo
• Hai sandbox e max-iterations configurati

Pro tip: alcuni sviluppatori si sono fatti un bot che li notifica su WhatsApp/Telegram quando Ralph finisce. Così possono dedicarsi ad altro senza controllare ogni 5 minuti.

Quando ha senso usare Ralph (e quando no)

Ralph funziona meglio quando sai già cosa vuoi costruire. Non è uno strumento per esplorare idee o fare brainstorming. È un operaio instancabile che esegue un piano.

Usa Ralph per:

• Large refactoring: migrazioni di framework, upgrade dipendenze, cambi API su centinaia di file
• Batch operations: triage ticket, generazione documentazione, standardizzazione codice
• Test coverage: “aggiungi test per tutte le funzioni scoperte in src/”
• Greenfield overnight: scaffold di progetti con raffinamento iterativo
• Task meccanici con criteri chiari: se puoi descrivere “fatto” in modo preciso, Ralph ci arriva

Non usare Ralph per:

• Prototipazione esplorativa: se non sai cosa vuoi, Ralph girerà a vuoto
• Decisioni architetturali: quelle richiedono giudizio umano
• Codebase senza test/typecheck: mancano i feedback loop, Ralph non sa se rompe qualcosa
• Task vaghi: “migliora la UX” non è un acceptance criteria

Risultati reali

Ecco cosa sta succedendo nel mondo reale:

Y Combinator Hackathon: un team ha fatto shipping di 6 repository completi in una notte con un costo API di $297. Il valore del lavoro? Stimato in $50.000.

Il progetto Cursed: Geoffrey Huntley ha fatto girare un Ralph loop per 3 mesi consecutivi con un singolo prompt: “Crea un linguaggio di programmazione come Golang ma con keyword Gen Z.” Il risultato: un compilatore funzionante con due modalità di esecuzione, compilazione LLVM a binari nativi, standard library, e supporto parziale per editor. Keywords incluse: slay (function), sus (variable), based (true).

Sostituire l’outsourcing: secondo Huntley, Ralph può rimpiazzare la maggior parte dell’outsourcing per progetti greenfield. Ha difetti, ma sono identificabili e risolvibili attraverso diversi stili di prompt.

Greenfield = progetto partito da zero, su un “campo verde” dove non c’è niente.

Viene dall’edilizia: costruire su un terreno vergine (greenfield) vs ristrutturare un edificio esistente (brownfield).

Nel software:

• Greenfield: crei un’app nuova, nessun codice legacy, nessun vincolo ereditato
• Brownfield: lavori su codice esistente, con tutte le sue magagne

Un esempio concreto

Diciamo che devi aggiungere un sistema di priorità ai task della tua app.

Senza Ralph:

1. Chiedi all’AI di aggiungere la colonna al DB
2. Lo fa, dice “fatto”
3. Chiedi di aggiungere il badge UI
4. Si dimentica che doveva anche aggiornare il form
5. Chiedi di sistemare il form
6. I test falliscono, non se n’è accorto
7. Glieli fai notare
8. Li sistema, rompe qualcos’altro
9. Ti arrabbi
10. Finisci a mano

Con Ralph:

1. Scrivi il prd.json con le 4 story necessarie
2. Lanci ./ralph.sh 25
3. Vai a farti un caffè
4. Torni con 4 commit puliti, test passati, feature completa

---

FAQ

Ralph Loop funziona con GPT/Copilot/altri LLM?

Sì. Il pattern è agnostico rispetto al modello. Ti serve un tool che giri in terminale e possa leggere/scrivere file. Claude Code, Copilot CLI, Codex CLI, Aider: tutti vanno bene. ChatGPT web no, perché non ha accesso al filesystem.

Quanto costa far girare Ralph tutta la notte?

Dipende dalle iterazioni e dalla lunghezza dei prompt. 50 iterazioni su un progetto medio consumano circa 100-200k token. Con Claude Code in abbonamento hai un limite mensile. Monitora l’usage e imposta sempre --max-iterations come salvagente. Come riferimento: il team YC ha speso $297 per $50k di lavoro equivalente.

Cosa succede se il modello si blocca su un bug?

Il progress.txt registra tutti i tentativi. Se Ralph fallisce più volte sullo stesso task, troverai le note con i tentativi fatti. Il flag passes resta false finché non risolvi manualmente o il modello trova la soluzione.

È sicuro far fare commit automatici all’AI?

Con le giuste precauzioni sì. Lavora sempre su un branch separato, mai su main. Imposta branch protection su GitHub. Usa CI che blocca push se i test falliscono. Fai review del codice prima di merge. E per i loop AFK, usa sempre la sandbox perchè gli esperti di sicurezza lo raccomandano esplicitamente.

Plugin Anthropic o bash loop?

Per task brevi (< 15 iterazioni): il plugin è più comodo. Per task lunghi (overnight, refactoring massivi): il bash loop. Il plugin accumula tutto nella stessa context window e dopo un po’ il modello inizia a “dimenticare” e allucinare.

Posso usare Ralph per costruire un’intera app da zero?

Sì, ma con aspettative realistiche. Ralph è per proof of concept, non per applicazioni production-ready. Definisci la versione minima della tua idea, fai girare Ralph, poi itera manualmente sulle parti che richiedono giudizio.

Quanto deve essere dettagliato il PRD?

Più è dettagliato, migliori i risultati. Ogni task deve avere: titolo chiaro, descrizione del comportamento atteso, acceptance criteria verificabili (cose a cui il modello può rispondere sì/no). Criteri vaghi tipo “buona UX” non funzionano. Come dice Huntley: non pianifica lui, chiede al modello di generare il TODO list e poi lo fa eseguire.

Il plugin ha dipendenze nascoste?

Sì, richiede jq che su Windows/Git Bash non è installato di default. Installa jq prima o usa WSL. Su Mac: brew install jq. Su Linux: apt install jq.

Ralph può validare l’UI o solo il codice?

Con Playwright MCP o Claude for Chrome, Ralph può aprire il browser, navigare, prendere screenshot e verificare che l’UI funzioni. Senza questi tool, valida solo tramite test — che potrebbero non coprire l’interfaccia grafica.

Cosa faccio se Ralph va in loop infinito?

Ecco perché --max-iterations è obbligatorio. Se non l’hai impostato e Ralph gira da ore: Ctrl+C per killare il processo, poi controlla progress.txt e la git history per capire dove si è bloccato.

Quali sono i 5 requisiti per il successo?

Indipendentemente dal metodo scelto: (1) meccanismo di sicurezza (sandbox), (2) piano dettagliato (PRD), (3) capacità di validare il lavoro, (4) limiti di iterazione, (5) criteri di completamento chiari. Questi principi valgono per qualsiasi agente autonomo long-running.

Cos’è questa storia del memecoin $RALPH?

Dopo che VentureBeat ha definito Ralph Wiggum “the biggest name in AI”, la community ha creato un memecoin ($RALPH) per celebrare la metodologia. Huntley non ha controllo sullo smart contract ma ha accettato il modello come forma alternativa di finanziamento per l’open source. Non è consiglio finanziario, le crypto sono volatili. Insomma lascia perdere.

---

Risorse

• Repository ufficiale: github.com/snarktank/ralph
• Pattern originale: ghuntley.com/ralph
• Plugin Anthropic: github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
• Guida avanzata: aihero.dev/tips-for-ai-coding-with-ralph-wiggum
• Articolo VentureBeat: How Ralph Wiggum went from The Simpsons to the biggest name in AI
• Thread di Ryan Carson: x.com/ryancarson

---

Conclusione

Ralph Loop è concettualmente banale, un ciclo while con stato persistito su file che risolve il problema degli LLM che non sanno quando hanno veramente finito.

La filosofia è controintuitiva: invece di cercare la perfezione al primo colpo, accetti che il modello fallisca. E lo fai fallire ripetutamente finché non riesce.

It’s better to fail predictably than succeed unpredictably

Inutile lottare con i limiti della context window in una singola sessione. Molto meglio accettare che ogni iterazione parta da zero, ma con la capacità di leggere lo stato di quella precedente.

Il risultato è un’attività che si completa in totale autonomia, senza che la qualità degradi col passare del tempo. E intanto tu puoi fare altro, mentre la macchina lavora. In fondo, forse, è proprio questo il cuore dell’automazione e della filosofia dietro l’intelligenza sintetica: la risposta alla domanda fondamentale sulla vita, l’universo e tutto quanto (cit.) e la liberazione definitiva da tutte quelle cose che a noi umani annoiano a morte.

Spero che questo post ti sia utile. Se hai provato a far apparecchiare la tavola a Ralph fammi sapere come è andata.