00:00:00Ralph Wiggum geht gerade absolut durch die Decke. Wir haben letztes Jahr ein Video darüber gemacht und
00:00:04seitdem wird auf Twitter über nichts anderes mehr gesprochen. Matt Pocock hat etliche Videos
00:00:09dazu erstellt, Ryan Carson hat einen sehr populären Artikel geschrieben und Razmike hat darauf mit
00:00:13seinem Ralphie-Bash-Script aufgebaut. Aber machen es alle falsch? Der Schöpfer meinte bereits,
00:00:19dass einige Implementierungen fehlerhaft sind.
00:00:21Was ist also der richtige Weg? Und warum ist Ralph derzeit die beste Methode, um Software
00:00:26mit KI zu entwickeln? Abonniert den Kanal und legen wir direkt los.
00:00:30Der Ralph-Loop wurde von Jeff Huntley erfunden und bereits im Juni letzten Jahres beschrieben.
00:00:35Im Grunde ist es ein Bash-Loop, der einem KI-Agenten immer wieder exakt denselben Prompt
00:00:40gibt. Das ist auf so vielen Ebenen genial, weil der KI-Agent so in seinem smartesten
00:00:46Modus arbeiten kann – nämlich dann, wenn er so wenig Kontext wie möglich hat. Schaut euch das an.
00:00:51Stellen wir uns vor, das hier ist das gesamte Kontextfenster für einen Agenten. Von 0 bis etwa 30 %
00:00:57liegt die sogenannte "Smart Zone", in der der Agent die beste Leistung erbringt. Von etwa
00:01:0130 bis 60 % ist die Leistung immer noch sehr gut. Ab 60 % aufwärts – also 60, 70, 80, 90 –
00:01:08beginnt die Qualität nachzulassen. Wir nennen das die "Dumb Zone". Diese Zahlen sind nicht
00:01:12in Stein gemeißelt und variieren je nach Modell. Die Smart Zone könnte bei manchen Modellen
00:01:1640 oder 50 % betragen, aber meist beginnt ab 80 % des Kontextfensters die Phase der "Dummheit".
00:01:21Bei Claude Sonnet oder Opus umfasst ein typisches Kontextfenster 200.000 Token. Man kann also sagen,
00:01:28dass die ersten 60k die Smart Zone sind. Die nächsten 60k sind noch okay, aber nicht so gut wie die ersten.
00:01:33Und bei den letzten 80k scheint die Leistung spürbar abzufallen. Das ist meine persönliche
00:01:38Erfahrung mit diesem Modell; eure Erfahrungen mögen anders sein. Der Grund dafür
00:01:43ist, dass das Modell autoregressiv ist. Das heißt, es muss die vorherigen Token betrachten,
00:01:47um das nächste vorherzusagen. Bei Unmengen an Token muss es sich durch extrem viel Material
00:01:52arbeiten, um die relevanten Informationen für die aktuelle Aufgabe zu finden. Schauen wir uns die ersten 30 % an.
00:01:56Noch bevor ihr euren ersten Prompt schreibt, werden automatisch Dinge zum Kontextfenster hinzugefügt.
00:02:01Zuerst der System-Prompt und dann die System-Tools. Bei einem typischen Claude-Modell
00:02:06belegen diese 8,3 % bzw. 1,4 % des Kontexts. Also fast 10 % dieser ersten 30 %.
00:02:12Hinzu kommen eventuelle Skills und auch
00:02:16eigene MCP-Tools. Schließlich wird auch eine agent.md-Datei hinzugefügt, falls vorhanden.
00:02:21Und je größer diese Elemente sind – also etwa die MD-Datei –, desto mehr
00:02:25Token verbrauchen sie. All das passiert, bevor ihr überhaupt euren eigenen Prompt eingefügt habt.
00:02:30Generell ist es also am besten, diesen Bereich so klein wie möglich zu halten. Weniger Tools,
00:02:35weniger Skills und weniger Inhalt in der agent.md, damit das Modell in seinem optimalen
00:02:40Kontext arbeitet. Um ein Gefühl für 60.000 Token zu bekommen: Das gesamte Skript von
00:02:44"Star Wars: Eine neue Hoffnung" entspricht in GPT-5 etwa 54.000 Token. Also ungefähr dieser Menge.
00:02:51Vielleicht fragt ihr euch jetzt: Was ist mit Compaction? Kann das hierbei helfen?
00:02:56Darauf kommen wir später zurück. Schauen wir uns nun an, wie Ralph hierbei konkret hilft.
00:03:00Der Vorteil von Ralph ist, dass man sich auf ein Ziel pro Kontextfenster konzentriert.
00:03:05Das gesamte 200k-Kontextfenster wird einer einzigen Aufgabe gewidmet. Das funktioniert so,
00:03:10dass wir einen Prompt schreiben, der zuerst die plan.md-Datei prüft. Darin stehen
00:03:15die zu erledigenden Aufgaben. Zum Beispiel: Frontend erstellen, Backend bauen, Datenbank einrichten
00:03:19und so weiter. Das ist ein sehr grobes Beispiel. In der Praxis wäre man mit Ralph viel detaillierter
00:03:23und granularer, aber für den Moment bleiben wir dabei. Dieser Prompt weist den Agenten an,
00:03:28die wichtigste Aufgabe zu wählen und die Änderungen umzusetzen. Danach werden die Änderungen
00:03:33ausgeführt, per Push übertragen, committet und Tests durchgeführt.
00:03:38Sobald die Tests bestanden sind, wird die Aufgabe in der plan.md abgehakt und der Prozess
00:03:42beginnt von vorn. Der Agent sucht immer wieder nach der wichtigsten Aufgabe, bis alles erledigt ist.
00:03:46Wobei ich das eigentlich zurücknehmen muss, denn man kann den Ralph-Loop auch einfach
00:03:52immer weiterlaufen lassen, selbst wenn alle Aufgaben erledigt sind.
00:03:57Das hat den Vorteil, dass er vielleicht noch Fehler findet oder Funktionen ergänzt,
00:04:02die gar nicht in der plan.md standen. Falls er doch mal abdriftet, bietet Ralph den Vorteil,
00:04:08dass man den Prozess jederzeit stoppen, die prompt.md anpassen und alles neu starten kann.
00:04:12Ralph macht das so einfach, weil der gesamte Prozess in einer einzigen Bash-While-Schleife läuft.
00:04:16Hier wird einfach die prompt.md per "cat" an den Agenten ausgegeben und dann Claude
00:04:22im "YOLO-Modus" gestartet. Das Flag heißt natürlich nicht wirklich YOLO, sondern
00:04:26"dangerously skip permissions", aber aus Platzgründen habe ich es abgekürzt.
00:04:31Das Besondere an Ralph ist, dass es außerhalb der Kontrolle des Modells liegt.
00:04:36Das Modell kann Ralph nicht stoppen; es läuft einfach weiter. So wird sichergestellt,
00:04:41dass bei jeder neuen Aufgabe oder jedem neuen Prompt der Kontext so sauber ist,
00:04:46als hätte man den Agenten gerade erst geöffnet. Alles ist frisch. Keine Compaction,
00:04:50kein Ballast. Jede neue Aufgabe erhält den maximalen Kontext und nutzt das Modell
00:04:55in seinem intelligentesten Zustand. Bei der Compaction schaut sich der Agent
00:05:01alle bisherigen Token im Kontextfenster an und filtert das Wichtigste für den nächsten Prompt heraus.
00:05:05Er wählt also aus, was er für wichtig hält – aber er weiß nicht unbedingt, was wirklich
00:05:11entscheidend ist. Daher können bei der Compaction kritische Informationen verloren gehen,
00:05:16sodass das Projekt nicht wie erwartet funktioniert. Nachdem wir nun die kanonische
00:05:21Ralph-Loop-Implementierung gesehen haben, verstehen wir auch, warum andere Ansätze abweichen.
00:05:27Schauen wir uns die Anthropic-Variante an: Sie nutzt einen Slash-Befehl innerhalb des Claude-Codes,
00:05:33arbeitet mit maximalen Iterationen und einem "Completion Promise".
00:05:38Das Problem bei diesem speziellen Ralph-Wiggum-Plugin ist die Tatsache, dass es die
00:05:43Informationen beim Übergang zur nächsten Aufgabe kompaktiert. Wenn also eine Aufgabe
00:05:48beendet ist und der Prompt neu startet, wird der Kontext nicht komplett zurückgesetzt,
00:05:54sondern das Vorherige zusammengefasst, was zu Informationsverlust führen kann. Auch die
00:05:59maximalen Iterationen sind ein kleiner Nachteil, da es manchmal gut ist, Ralph einfach
00:06:04laufen zu lassen. Er findet oft interessante Fehler, an die man selbst nie gedacht hätte.
00:06:08Wenn man als Mensch den Prozess beobachtet, erkennt man Muster – gute wie schlechte –
00:06:14die man dann im ursprünglichen Prompt optimieren kann.
00:06:19Betrachten wir Ryan Carsons Ansatz des Ralph-Loops, sehen wir, dass er nicht ganz
00:06:24kanonisch ist, weil er bei jedem Durchlauf die agent.md-Datei anpassen oder
00:06:29ergänzen kann. Je nach System-Prompt oder den eigenen Vorgaben neigen Modelle
00:06:33meiner Erfahrung nach standardmäßig dazu, sehr wortreich zu sein. Wenn man also bei jeder
00:06:39Iteration die agent.md-Datei erweitert, die ja zu Beginn jedes User-Prompts in den Kontext
00:06:44geladen wird, füllt man das Kontextfenster immer weiter mit Token. Das drängt das Modell
00:06:48schneller in den Bereich, in dem es unpräzise Ergebnisse liefert. Dass so viele Leute
00:06:53eigene Scripte basierend auf dem einfachen Ralph-Bash-Script erstellen, beweist,
00:06:57wie simpel und verständlich das Konzept ist. Auch wenn es eine kanonische Methode gibt,
00:07:03ist es völlig okay, wenn Entwickler und Firmen sie an ihre speziellen Bedürfnisse anpassen.
00:07:08Ich finde es zum Beispiel klasse, dass man in Raz Mikes Ralphie-Script parallele
00:07:13Ralphs laufen lassen und das Browser-Tool für Tests direkt aus der Shell nutzen kann.
00:07:18Ebenso gefällt mir Matt Pococks Version, in der er Aufgaben als GitHub-Issues
00:07:23anlegt. Der Ralph-Loop pickt sich das wichtigste Issue heraus, arbeitet es ab und
00:07:28markiert es als erledigt, bevor er zum nächsten übergeht. Das ist wirklich clever.
00:07:32Die Stärke und Einfachheit von Ralph sorgen sicher dafür, dass uns das Konzept noch lange erhalten bleibt.
00:07:37Wir werden sicherlich noch viele Iterationen und Verbesserungen davon sehen.
00:07:42Spannend finde ich Jeffreys Weg mit seinem "Loom and Weaver"-Projekt, das Software
00:07:47autonom und fehlerfrei erstellen soll. Wenn all diese Ralphs autonom Software bauen,
00:07:52braucht man eine Möglichkeit, Fehler zu finden und zu beheben. Hier kommt Better Stack
00:07:56ins Spiel. Es kann Logs einlesen und Fehler herausfiltern, bietet aber auch
00:08:01Error-Tracking für das Frontend an.
00:08:06Mit diesem MCP-Server kann man den Agenten gezielt Fehler aus dem Frontend oder Backend
00:08:11heraussuchen lassen, statt das ganze Log zu lesen, was wiederum das Kontextfenster schont.
00:08:16Schaut euch also Better Flux mal an und schreibt mir eure Meinung in die Kommentare.
00:08:17So go and check out Better Flux, and let me know what you think in the comments.