Wreszcie jest! Ralph TUI, wizualizacja Ralph Loop

Wcześniej napisałem tutorial o ralph-loop, a wielu znajomych po jego uruchomieniu wyrażało podobne opinie: Super, Claude Code wreszcie może działać przez dłuższy czas. Ale czasami, obserwując go, wydaje się, że stoi w miejscu, a w głowie pojawia się pytanie: "Czy on w ogóle coś robi, czy kręci się w kółko?"

To właśnie dlatego ostatnio zajmowałem się ralph-tui.

ralph-tui nie jest obowiązkowo powiązany z Claude Code, dziedziczy i rozwija esencję ralph loop, a także wizualizuje wykonywanie zadań i proces, znacznie obniżając próg długotrwałej pracy z dużymi modelami. Możesz podłączyć dowolnego agenta, dowolny model, krajowy, tani, taki, który możesz uruchamiać przez długi czas. Z ralph-tui, dla zwykłych ludzi, to jak przesiadka z manualnej skrzyni biegów na automatyczną z tempomatem.

Co to właściwie jest?

Możesz traktować ralph-tui jako "cykliczny aranżer agenta kodowania AI", tylko że nie zadowala się tym, że "działa", bardziej zależy mu na tym, żebyś "widział, kontrolował i mógł wznowić".

Jego podstawowy sposób działania jest bardzo prosty:

• Dajesz mu stertę zadań (z PRD lub z innego systemu zadań)
• Wybiera zadanie o najwyższym priorytecie
• Składa prompt
• Uruchamia agenta do wykonania
• Ocenia, czy zadanie jest ukończone
• Zapisuje stan
• W następnej rundzie kontynuuje

Najważniejsze jest to, że wszystko to możesz zobaczyć w terminalu i możesz w każdej chwili zatrzymać i przejąć kontrolę. Oficjalnie też definiuje się go bardzo prosto: interaktywny orchestrator pętli agenta z TUI, który obsługuje TUI / headless / remote.

Dlaczego uważam, że lepiej nadaje się do "długotrwałego działania"?

Największym problemem z uruchamianiem pętli za pomocą skryptu nie jest to, że nie działa, ale to, że nie wiesz, gdzie się znajduje.

Widzisz, że logi przewijają się bardzo szybko, a wentylator kręci się radośnie, ale nie jesteś pewien:

• Czy powtarza naprawę tego samego błędu?
• Czy ciągle zmienia ten sam fragment kodu, a potem go przywraca?
• Czy już skończył, tylko się nie wyłączył?
• Czy utknął w jakiejś pętli testowej?

Rozwiązanie ralph-tui jest bardzo "inżynieryjne":

• Ma koncepcję sesji, stan jest zapisywany na dysku (.ralph-tui/session.json)
• Można wznowić działanie po awarii (crash recovery)
• Ma mechanizm blokowania, aby uniknąć uruchamiania kilku instancji, które zniszczą katalog
• Może być również uruchamiany headless w CI, a nawet zdalnie otwierać listener, a lokalne TUI łączy się z nim

Jednym słowem: bardziej przypomina to "zarządzanie pracownikiem, który potrafi pisać kod", niż "obserwowanie szalejącego skryptu".

Jak zainstalować

ralph-tui to ekosystem Bun/TypeScript, więc instalacja jest dość prosta. Oficjalna strona również zawiera instrukcje instalacji.

Najpierw upewnij się, że masz bun na swoim komputerze:

bun --versionNastępnie zainstaluj ralph-tui (tutaj podaję typową metodę instalacji, szczegóły znajdują się na oficjalnej stronie instalacji):

bun add -g ralph-tuiPo instalacji sprawdź:

ralph-tui --helpJeśli jesteś fanem Node i nie chcesz dotykać bun, też możesz:

npm i -g ralph-tui

Najpierw uruchom minimalną pętlę, zanim zaczniesz robić coś dużego

Sugeruję, abyś za pierwszym razem nie robił od razu czegoś w stylu "refaktoryzacji całego repozytorium". Zrób tylko jedną rzecz: spraw, aby uruchomił się mały, akceptowalny task.

Inicjalizacja

Otwórz dowolny katalog:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupTo spowoduje przejście do interaktywnego kreatora, który w zasadzie "instaluje ralph-tui w twoim repozytorium", zrobi to:

• Automatyczne wykrywanie, które agenty masz zainstalowane na swoim komputerze (np. Claude Code, OpenCode itp.)
• Generowanie pliku konfiguracyjnego w projekcie: .ralph-tui/config.toml
• Przy okazji instalowanie skills związanych z generowaniem PRD/konwersją zadań (żebyś nie musiał się z tym samemu męczyć później)

Osobiście polecam: za pierwszym razem nie idź na łatwiznę, setup musi być uruchomiony przynajmniej raz.

Generowanie PRD projektu

Po uruchomieniu setupu, następnym krokiem jest najbardziej kluczowy element z oficjalnego tutoriala, który idealnie nadaje się na demo w artykule: create-prd.

ralph-tui create-prd --chat to polecenie uruchomi interaktywny proces, który będzie zadawał pytania jak product manager o cel, warunki brzegowe i kryteria akceptacji. Po zadaniu pytań, wygeneruje w projekcie dwie rzeczy (i to jest najważniejsze):

• Plik markdown z PRD: ./tasks/prd-feature.md
• Plik z zadaniami gotowy do wykonania: ./prd.json

W tym momencie wchodzisz w "standardową pętlę" ralph-tui:

Wymagania (PRD) → Zadania (prd.json) → Wykonanie (run)

Uruchomienie (run)

Mając prd.json, uruchomienie jest naturalną konsekwencją:

ralph-tui run --prd ./prd.json zobaczysz uruchomione TUI, które zacznie pętlę: wybieranie zadania → wykonanie → ocena ukończenia → zapisywanie stanu → zakończenie lub kolejna runda.

Przy pierwszym uruchomieniu gorąco polecam dodać limit iteracji, żeby zamknąć to w klatce:

ralph-tui run --prd ./prd.json --iterations 5 Po uruchomieniu sprawdź zmiany, uruchom testy, zobacz czy PRD i zadania są zgodne z oczekiwaniami. Upewnij się, że ta ścieżka działa, a potem zwiększ liczbę iteracji, przejdź na headless/remote, to jest rozsądne podejście.

W tym momencie możesz w zasadzie potwierdzić: ta pętla naprawdę działa.

Jak wybrać model/Agenta? O oszczędzaniu trzeba mówić szczerze

Wiem, że wiele osób najbardziej interesuje się tym: "Czy mogę nie używać Claude Code? Czy mogę użyć tańszego modelu?"

Odpowiedź brzmi: tak.

ralph-tui sam w sobie pozwala na określenie agenta i modelu (oficjalna dokumentacja run zawiera przykłady).

Na przykład użycie Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Ale szczerze mówiąc, sam nie używałbym Opus do "uzupełniania testów, naprawiania lint" - to zbyt drogie. Moja zasada to podział na warstwy:

• Tanie modele: do wykonywania dużej ilości powtarzalnej pracy (uzupełnianie testów, uzupełnianie komentarzy, naprawianie formatowania, dodawanie warunków brzegowych)
• Drogie modele: tylko w kluczowych momentach (dostosowanie architektury, trudne błędy, kluczowa logika)

Jeśli jesteś zwykłym programistą, to takie podejście jest jeszcze ważniejsze. Ponieważ nie masz budżetu dużej firmy, musisz kontrolować koszty, żeby móc działać długo.

Chcesz jeszcze lepiej? Powierz "pisanie PRD" agentowi

ralph-tui ma fajny design: obsługuje skills (czyli w zasadzie zestaw poleceń jako dodatek do agenta).

Oficjalny sposób instalacji to użycie add-skill:

bunx add-skill subsy/ralph-tui --all lub instalacja do konkretnego agenta, np. claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Po instalacji, w sesji agenta możesz używać slash command:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads To tak, jakbyś zainstalował w IDE wtyczkę, tylko że ta wtyczka jest dla agenta. Jej celem jest skrócenie czasu "ręcznego przenoszenia wymagań", dzięki czemu wymagania → zadania → wykonanie bardziej przypominają linię produkcyjną.

Kiedy warto go używać? Kiedy nie?

Nie przepadam za narracją w stylu "wszystko da się zrobić za pomocą AI", bo łatwo wprowadza w błąd. Narzędzie to narzędzie, liczy się dopasowanie do scenariusza.

Scenariusze, w których ralph-tui się sprawdzi

Masz do wykonania zadania tego typu:

• Uzupełnianie testów (szczególnie w starych projektach)
• Naprawa lint / formatowanie
• Małe refaktoryzacje (zbieranie powtarzającego się kodu)
• Masowe dodawanie typów, uzupełnianie warunków brzegowych
• Rozbijanie wymagań na mniejsze zadania i stopniowe ich realizowanie

Te zadania mają jedną cechę wspólną: dużo zadań, wysoki stopień powtarzalności, możliwość weryfikacji, możliwość iteracyjnego postępu.

Scenariusze, w których nie warto na siłę używać ralph-tui

Chcesz zrobić coś takiego:

• Jednorazowa, duża refaktoryzacja, brak jasnych kryteriów akceptacji
• Wymagania są niejasne, opierasz się na ukrytej wiedzy w swojej głowie
• Wymaga dużej ilości komunikacji/potwierdzeń między zespołami
• Wymaga podjęcia decyzji produktowych

W takich zadaniach agent loop tylko spotęguje chaos.

Czym różni się od ralph-loop (ralph-claude-code)?

ralph-claude-code bardziej przypomina "autopilota dla Claude Code": skrypt go uruchamia, pętla działa, wykrywanie błędów, ograniczanie przepustowości, wyłączniki awaryjne są zapewnione. Chcesz, żeby było "szybko", to będzie szybko.

ralph-tui bardziej przypomina "konsolę inżynieryjną dla agent loop": nie jest na stałe związany z konkretnym modelem ani systemem zadań. Chce rozwiązać problemy inżynieryjne takie jak "długotrwałe działanie, obserwowalność, sterowalność, możliwość odzyskiwania, zdalne sterowanie".

Więc pytasz, co wybrać?

• Jesteś użytkownikiem Claude Code i chcesz go szybko uruchomić → ralph-claude-code
• Chcesz podłączyć różne modele, chcesz oszczędzić pieniądze, chcesz zarządzać loopem jako usługą → ralph-tui

Na koniec: nie pozwól, żeby zamienił Twoje repozytorium w laboratorium

Sam stosuję kilka żelaznych zasad podczas uruchamiania agent loop, zapiszę je tutaj, żebyś mógł się nimi kierować, a prawdopodobieństwo katastrofy będzie znacznie mniejsze:

• Uruchamiaj na gałęzi, nie szalej na main.
• Przy pierwszym uruchomieniu zawsze dodaj --iterations, najpierw małymi krokami upewnij się, że nie zwariuje.
• Zadanie musi być weryfikowalne: albo da się uruchomić testy, albo da się uruchomić lint, albo da się porównać pliki wyjściowe.
• Musisz umieć się zatrzymać: jeśli widzisz, że zaczyna kręcić się w kółko, lepiej zatrzymać niż dalej przepalać pieniądze.
• Tanie modele do ciężkiej pracy, drogie modele do kluczowych zadań: koszty się optymalizuje, a nie o nie modli. Adres projektu: https://github.com/subsy/ralph-tui