Finalmente è arrivato quello che volevate! Ralph TUI, visualizzazione del Ralph Loop

In precedenza ho scritto un tutorial su ralph-loop, e molti amici, dopo averlo eseguito, hanno dato un feedback abbastanza coerente: È fantastico, Claude Code finalmente può essere eseguito a lungo. Ma a volte, osservandolo, sembra immobile, e inevitabilmente ti chiedi: "Sta davvero avanzando o sta girando a vuoto?"

Questo è il motivo per cui mi sono dedicato di recente a ralph-tui.

ralph-tui non vincola forzatamente a Claude Code, eredita e sviluppa l'essenza di ralph loop, e visualizza l'esecuzione e il processo delle attività, riducendo notevolmente la barriera per far lavorare a lungo i modelli di grandi dimensioni. Puoi collegare completamente altri agent, altri modelli, quelli nazionali, economici, quelli che puoi permetterti di eseguire a lungo. Con ralph-tui, per noi persone comuni, il significato non è inferiore al passaggio da un cambio manuale a un cambio automatico con cruise control.

Cos'è esattamente?

Puoi considerare ralph-tui come un "orchestratore di loop per AI coding agent", solo che non si accontenta di "poter funzionare", ma si preoccupa di più di "poter vedere, controllare, ripristinare".

Il suo modo di lavorare di base è molto semplice:

• Gli dai un mucchio di compiti (che provengano da un PRD o da un altro sistema di task)
• Sceglie quello con la priorità più alta
• Assembla il prompt
• Avvia l'agent per eseguirlo
• Giudica se questo compito è considerato completato
• Scrive lo stato
• Continua con il ciclo successivo

Il punto è: puoi vedere tutto questo nel terminale e puoi fermarlo e riprenderlo in qualsiasi momento. Anche la sua posizione ufficiale è scritta in modo molto esplicito: un orchestratore di loop agent con TUI interattivo, che supporta anche TUI / headless / remote.

Perché dico che è più adatto per "l'esecuzione a lungo termine"?

Il problema più grande con l'esecuzione di script in loop non è che non si avviano, ma che non sai a che punto sono arrivati.

Vedi i log che scorrono velocemente, la ventola che gira felicemente, ma non sei sicuro:

• Sta ripetutamente correggendo lo stesso bug?
• Sta continuamente modificando lo stesso codice e poi riportandolo indietro?
• È già stato completato, ma non è uscito?
• È bloccato in un ciclo infinito su un determinato test?

La soluzione di ralph-tui è molto "ingegneristica":

• Ha un concetto di sessione, lo stato viene salvato su disco (.ralph-tui/session.json)
• Può essere ripreso dopo un crash (crash recovery)
• Ha un meccanismo di blocco per evitare che l'apertura di più istanze trasformi la directory in un pasticcio
• Può anche essere eseguito in modalità headless su CI, o persino aprire un listener in remoto e connettere il TUI locale

In una parola: è più come "stai gestendo un operaio che sa scrivere codice", piuttosto che "stai osservando uno script che impazzisce".

Come installare

ralph-tui è un ecosistema Bun/TypeScript, quindi l'installazione è abbastanza semplice. L'ufficiale ha anche fornito una pagina di installazione.

Prima conferma di avere bun sulla tua macchina:

bun --version Quindi installa ralph-tui (qui fornisco un metodo di installazione tipico, fai riferimento alla pagina di installazione ufficiale per i dettagli):

bun add -g ralph-tui Dopo l'installazione, verifica:

ralph-tui --help Se sei un fan di Node e non vuoi usare bun, va bene lo stesso:

npm i -g ralph-tui

Non fare subito grandi cose, esegui un ciclo chiuso minimo

Suggerisco che la prima volta che lo usi, non iniziare subito a fare qualcosa come "ristrutturare l'intero repo". Fai solo una cosa: fai in modo che esegua un piccolo compito accettabile.

Inizializzazione

Apri una directory a caso:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setup Questo entrerà nel processo di guida interattiva, in poche parole significa "installare ralph-tui in questo repository", farà:

• Rileva automaticamente quali agenti sono installati sulla tua macchina (come Claude Code, OpenCode, ecc.)
• Genera un file di configurazione nel progetto: .ralph-tui/config.toml
• Installa automaticamente le skills relative alla generazione di PRD/conversione di task (in modo da non doverle configurare manualmente in seguito)

Il mio consiglio personale: non essere pigro la prima volta, esegui sempre il setup.

Generare il PRD del progetto

Una volta completato il setup, il passo successivo è la parte più importante del tutorial ufficiale, e anche la più adatta per essere scritta come demo per un account pubblico: create-prd.

Il comando ralph-tui create-prd --chat avvierà un processo di dialogo, in cui ti interrogherà come un product manager sugli obiettivi, i vincoli e i criteri di accettazione dei requisiti. Dopo aver terminato le domande, genererà direttamente due elementi nel progetto (questo è il punto chiave):

• Un file markdown del PRD: ./tasks/prd-feature.md
• Un file di task eseguibile direttamente: ./prd.json

A questo punto, sei veramente entrato nel "ciclo standard" di ralph-tui:

Requisiti (PRD) → Task (prd.json) → Esecuzione (run)

Avviare l'esecuzione

Con prd.json, l'esecuzione diventa naturale:

ralph-tui run --prd ./prd.json Vedrai l'interfaccia TUI avviarsi e iniziare il loop: selezione del task → esecuzione → valutazione del completamento → scrittura dello stato → fine o round successivo.

La prima volta che lo esegui, consiglio vivamente di aggiungere un limite di iterazioni, per tenerlo sotto controllo:

ralph-tui run --prd ./prd.json --iterations 5 Dopo l'esecuzione, controlla le modifiche, esegui i test e verifica se il PRD e i task soddisfano le aspettative. Una volta confermato che il flusso funziona, puoi aumentare le iterazioni e passare a headless/remote, questo è il ritmo giusto.

A questo punto, puoi sostanzialmente confermare: questo loop funziona davvero.

Come scegliere il modello/Agent? Dobbiamo essere onesti sul risparmio di denaro

So che molti sono più interessati a: "Posso evitare di usare Claude Code? Posso usare modelli più economici?"

La risposta è: Sì.

ralph-tui ti consente di specificare l'agente e il modello (ci sono esempi nella documentazione ufficiale di run).

Ad esempio, usando Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Ma onestamente, io stesso non userei Opus per attività come "aggiungere test, correggere lint", è troppo costoso. La mia abitudine è stratificare:

• Modelli economici: per eseguire un sacco di lavoro ripetitivo (aggiungere test, aggiungere commenti, correggere la formattazione, aggiungere limiti)
• Modelli costosi: solo per i nodi critici (adeguamenti dell'architettura, bug difficili, logica centrale)

Se sei uno sviluppatore normale, questo approccio è ancora più importante. Perché non hai il budget di una grande azienda, devi rendere i costi controllabili per poter andare avanti a lungo.

Vuoi divertirti di più? Affida anche la "scrittura del PRD" all'agente

ralph-tui ha un design che mi piace molto: supporta le skills (in pratica, sono comandi aggiuntivi per l'agente).

Il modo ufficiale per installarle è usare add-skill:

bunx add-skill subsy/ralph-tui --all Oppure installarle su un agente specifico, ad esempio claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Dopo l'installazione, puoi usare slash command nella sessione dell'agente:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads È come aver installato un plugin nell'IDE, solo che questo plugin è per l'agente. Il suo significato è ridurre il tempo di "trasporto manuale dei requisiti", rendendo i requisiti → task → esecuzione più simili a una linea di produzione.

Quando dovresti usarlo? Quando non dovresti usarlo?Non mi piace molto la narrativa del tipo "si può fare tutto con l'AI", è facile che porti fuori strada. Uno strumento è uno strumento, vale solo se adatto allo scenario.

Scenari adatti per l'uso di ralph-tui

Hai un sacco di lavoro di questo tipo:

• Aggiungere test (soprattutto per progetti vecchi)
• Correggere lint / format
• Refactoring a piccoli passi (convergere codice duplicato)
• Aggiungere tipi in batch, correggere i limiti
• Suddividere i requisiti e spingerli lentamente in base alla coda di attività

Questo tipo di lavoro ha un punto in comune: molte attività, alta ripetitività, accettabile, può essere promosso iterativamente.

Scenari in cui non forzare ralph-tui

Devi fare questo:

• Grande refactoring una tantum, criteri di accettazione non chiari
• I requisiti stessi sono vaghi, basati sulla tua conoscenza implicita
• Richiede molta comunicazione/conferma tra team
• Richiede che tu prenda decisioni sul prodotto

In questo tipo di attività, l'agent loop non farà altro che amplificare la confusione.

Qual è la differenza tra ralph-loop (ralph-claude-code) e questo?

ralph-claude-code è più simile a un "plugin di guida autonoma per Claude Code": lo script lo avvia, esegue il loop, il rilevamento dell'uscita, la limitazione della velocità e l'interruttore automatico ti coprono le spalle. Se vuoi che sia "veloce", lo sarà.

ralph-tui è più simile a una "console di controllo ingegneristico per l'agent loop": non salda un determinato modello, né salda un determinato sistema di attività. Ciò che vuole risolvere sono i problemi ingegneristici di "esecuzione a lungo termine, osservabile, controllabile, ripristinabile, remoto".

Quindi mi chiedi come scegliere?

• Sei un utente di Claude Code e vuoi farlo funzionare rapidamente → ralph-claude-code
• Vuoi connettere modelli diversi, vuoi risparmiare denaro, vuoi gestire il loop come un servizio → ralph-tui

Infine: non lasciare che trasformi il tuo repository in un laboratorio

Ho alcune regole ferree per l'esecuzione dell'agent loop, le scrivo qui e tu le segui, la probabilità di fallimento sarà molto inferiore:

• Esegui su un branch, non fare pazzie sulla main.
• La prima volta che esegui, aggiungi sempre --iterations, prima conferma a piccoli passi che non impazzirà.
• L'attività deve essere accettabile: o può eseguire test, o può eseguire lint, o può confrontare i file di output.
• Devi imparare a fermarti: quando vedi che inizia a girare in tondo, è più intelligente mettere in pausa che continuare a bruciare soldi.
• Modelli economici per lavori sporchi, modelli costosi per lavori critici: il costo è gestito, non pregato.Indirizzo del progetto: https://github.com/subsy/ralph-tui