Eindelijk is het er! Ralph TUI, visualisatie van Ralph Loop

Ik heb eerder een tutorial geschreven over ralph-loop, en veel vrienden die het hebben uitgevoerd, gaven consistente feedback: Het is geweldig, Claude Code kan eindelijk lang draaien. Maar soms zie je dat het stilstaat, en je vraagt je af: "Is het aan het vooruitgaan, of draait het in cirkels?"

Dit is de reden waarom ik de laatste tijd met ralph-tui aan het knutselen ben.

ralph-tui dwingt geen binding met Claude Code af, het erft en ontwikkelt de essentie van ralph loop, en visualiseert de taakuitvoering en het proces, waardoor de drempel voor het langdurig laten werken van grote modellen aanzienlijk wordt verlaagd. Je kunt volledig andere agents en andere modellen aansluiten, binnenlandse, goedkope, die je je op lange termijn kunt veroorloven. Met ralph-tui is de betekenis voor ons gewone mensen niet minder dan het overschakelen van een handgeschakelde versnellingsbak naar een automatische met cruise control.

Wat is het eigenlijk?

Je kunt ralph-tui zien als een "loop orchestrator voor AI coding agents", maar het is niet tevreden met "kunnen draaien", het geeft meer om "je kunt het zien, je kunt het controleren, je kunt het herstellen".

De basiswerkwijze is heel eenvoudig:

• Je geeft het een stapel taken (van PRD of van een ander taaksysteem)
• Het kiest de taak met de hoogste prioriteit
• Het stelt een prompt samen
• Het start de agent om uit te voeren
• Het beoordeelt of deze taak is voltooid
• Het schrijft de status weg
• De volgende ronde gaat verder

Het belangrijkste is: je kunt dit allemaal in de terminal zien, en je kunt het op elk moment stoppen en overnemen. De officiële positionering is ook heel direct: een agent loop orchestrator met een interactieve TUI, en ondersteunt TUI / headless / remote.

Waarom zeg ik dat het meer geschikt is om "langdurig te draaien"?

Het grootste probleem met het draaien van een loop in een script is niet dat het niet kan draaien, maar dat je niet weet waar het is gebleven.

Je ziet de logs snel voorbij flitsen, en de ventilator draait vrolijk, maar je bent er niet zeker van:

• Is het dezelfde bug aan het herhalen?
• Is het dezelfde code aan het wijzigen en vervolgens weer terug aan het wijzigen?
• Is het al klaar, maar is het niet afgesloten?
• Zit het vast in een bepaalde test in een oneindige lus?

De oplossing van ralph-tui is heel "technisch":

• Er is een sessieconcept, de status wordt opgeslagen (.ralph-tui/session.json)
• Het kan worden hersteld na een crash (crash recovery)
• Er is een vergrendelingsmechanisme om te voorkomen dat je meerdere instanties opent en de directory in een puinhoop verandert
• Het kan zelfs headless in CI worden uitgevoerd, of zelfs remote een listener openen op afstand, en de lokale TUI verbindt ermee

In één zin: Het is meer alsof "je een code schrijvende werknemer beheert", in plaats van "je naar een script te kijken dat flipt".

Hoe te installeren

ralph-tui is een Bun/TypeScript ecosysteem, dus het is vrij eenvoudig te installeren. De officiële website heeft ook een installatiepagina.

Controleer eerst of je bun op je machine hebt staan:

bun --versionInstalleer vervolgens ralph-tui (ik geef hier een typische installatie, specifiek afhankelijk van de officiële installatiepagina):

bun add -g ralph-tuiControleer na de installatie:

ralph-tui --helpAls je een Node-partij bent en bun niet wilt aanraken, kan dat ook:

npm i -g ralph-tui

Doe nog geen grote dingen, draai een minimale gesloten lus

Ik raad aan om bij het eerste gebruik niet meteen iets te doen als "de hele repo herstructureren". Doe gewoon één ding: Laat het een kleine, aanvaardbare taak doorlopen.

Initialisatie

Open een willekeurige directory:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupDit gaat naar een interactieve wizard, wat in feite betekent "ralph-tui in deze repository installeren", het zal:

• Automatisch detecteren welke agents op je machine zijn geïnstalleerd (zoals Claude Code, OpenCode, enz.)
• Genereer een configuratiebestand in het project: .ralph-tui/config.toml
• Installeer de skills die relevant zijn voor PRD-generatie/taakconversie (zodat je dit later niet handmatig hoeft te doen)

Mijn persoonlijke aanbeveling: wees niet lui bij de eerste keer, voer de setup zeker uit.

Genereer project PRD

Na het uitvoeren van de setup is de volgende stap de meest cruciale in de officiële tutorial, en ook het meest geschikt om er een demo voor een openbaar account van te maken: create-prd.

Het commando ralph-tui create-prd --chat start een interactief proces. Het zal je als een productmanager vragen naar je doelstellingen, randvoorwaarden en acceptatiecriteria. Na het stellen van deze vragen, zal het direct twee dingen in het project genereren (dit is het belangrijkste):

• Een PRD markdown-bestand: ./tasks/prd-feature.md
• Een direct uitvoerbaar takenbestand: ./prd.json

Pas op dit punt betreed je de "standaard gesloten lus" van ralph-tui:

Vereisten (PRD) → Taken (prd.json) → Uitvoering (run)

Runnen

Met prd.json is het runnen logisch:

ralph-tui run --prd ./prd.json Je ziet de TUI opstarten en beginnen met loopen: taak selecteren → uitvoeren → voltooing beoordelen → status schrijven → beëindigen of volgende ronde.

De eerste keer dat je het uitvoert, raad ik ten zeerste aan om een iteratielimiet toe te voegen, om het eerst in een kooi te stoppen:

ralph-tui run --prd ./prd.json --iterations 5 Na het uitvoeren, bekijk je de wijzigingen, voer je tests uit en controleer je of de PRD en taken aan de verwachtingen voldoen. Zodra je hebt bevestigd dat deze keten werkt, kun je de iteraties loslaten en overschakelen naar headless/remote. Dit is de juiste aanpak.

Op dit punt kun je in principe bevestigen: deze loop draait echt.

Hoe modellen/Agents te selecteren? Eerlijkheid over geld besparen

Ik weet dat veel mensen zich het meest zorgen maken over: "Kan ik Claude Code vermijden? Kan ik goedkopere modellen gebruiken?"

Het antwoord is: Ja.

ralph-tui zelf ondersteunt het specificeren van agent en model (er zijn voorbeelden in de officiële run-documentatie).

Bijvoorbeeld, met Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Maar eerlijk gezegd zou ik Opus zelf niet gebruiken voor "tests aanvullen, lint repareren", het is te duur. Mijn gewoonte is om het te verdelen:

• Goedkope modellen: voer veel repetitief werk uit (tests aanvullen, annotaties aanvullen, format repareren, grenzen toevoegen)
• Dure modellen: alleen in belangrijke knooppunten (architectuuraanpassingen, moeilijke bugs, kernlogica)

Als je een gewone ontwikkelaar bent, is deze aanpak nog belangrijker. Omdat je geen groot budget hebt, moet je de kosten beheersbaar houden om het lang vol te houden.

Wil je het nog leuker maken? Laat de agent ook "PRD schrijven"

ralph-tui heeft een ontwerp dat ik erg leuk vind: het ondersteunt skills (in feite een set plug-in commando's voor de agent).

De officiële manier om te installeren is met add-skill:

bunx add-skill subsy/ralph-tui --all Of installeer het op een specifieke agent, zoals claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Na installatie kun je slash commando's gebruiken in de agent sessie:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Dit is alsof je plug-ins in je IDE hebt geïnstalleerd, alleen zijn deze plug-ins voor de agent. Het doel is om de tijd te verminderen die nodig is voor "handmatig vereisten overbrengen", waardoor vereisten → taken → uitvoering meer op een lopende band lijken.

Wanneer moet je het gebruiken? Wanneer niet?Ik ben niet zo'n fan van het narratief dat 'alles met AI kan worden opgelost', omdat het gemakkelijk misleidend is. Een tool is slechts een tool, en is alleen waardevol in de juiste context.

Geschikte scenario's voor ralph-tui

Je hebt een hoop van dit soort werk:

• Tests aanvullen (vooral bij oude projecten)
• Linting / formatting repareren
• Kleine refactorings (het samenvoegen van herhaalde code)
• Batchgewijs types toevoegen, randgevallen aanvullen
• Vereisten opsplitsen en langzaam pushen via een takenwachtrij

Dit soort werk heeft één ding gemeen: veel taken, hoge mate van herhaling, kan worden geaccepteerd, kan iteratief worden gepusht.

Scenario's waarin het niet geschikt is om ralph-tui te forceren

Je bent bezig met dit:

• Eenmalige grote refactoring, onduidelijke acceptatiecriteria
• De vereisten zelf zijn vaag, afhankelijk van impliciete kennis in je hoofd
• Vereist veel teamoverschrijdende communicatie/bevestiging
• Vereist dat je productbeslissingen neemt

Bij dit soort taken zal de agent loop alleen maar de chaos vergroten.

Wat is het verschil met ralph-loop (ralph-claude-code)?

ralph-claude-code is meer als een 'autonome rij-add-on voor Claude Code': het script start het op, voert de loop uit, en exitdetectie, throttling en stroomonderbrekers zijn allemaal gedekt. Je wilt 'snelheid', en het is erg snel.

ralph-tui is meer als een 'engineeringconsole voor een agent loop': het is niet vastgelijmd aan een bepaald model, noch aan een bepaald taaksysteem. Het probeert engineeringproblemen op te lossen zoals 'langdurig draaien, observeerbaar, controleerbaar, herstelbaar, op afstand'.

Dus je vraagt me hoe je moet kiezen?

• Je bent een Claude Code-gebruiker en wilt het snel laten draaien → ralph-claude-code
• Je wilt verschillende modellen aansluiten, geld besparen, de loop als een service beheren → ralph-tui

Tot slot: laat het je repository niet als een laboratorium gebruiken

Ik heb een paar ijzeren regels voor het draaien van een agent loop, schrijf ze hier op en volg ze, de kans op een crash is veel kleiner:

• Draai op een branch, ga niet op de main branch tekeer.
• Voeg bij de eerste run zeker --iterations toe, bevestig eerst in kleine stappen dat het niet gek wordt.
• De taak moet acceptabel zijn: ofwel kan het tests uitvoeren, ofwel kan het linten, ofwel kan het uitvoerbestanden vergelijken.
• Je moet leren stoppen: als je ziet dat het in cirkels begint te draaien, is pauzeren slimmer dan doorgaan met geld verbranden.
• Gebruik goedkope modellen voor het grove werk, dure modellen voor het cruciale werk: kosten worden beheerd, niet afgesmeekt.Projectadres: https://github.com/subsy/ralph-tui