Ein Team hat beim Y Combinator Agents Hackathon vor Kurzem ein Experiment gemacht. Es startete ein paar GCP-Instanzen, ließ Claude Code in Endlosschleifen laufen und ging nach 2 Uhr früh schlafen. Beim Aufwachen hatten die Leute über 1.100 Commits in sechs Repositories, darunter eine fast vollständige Portierung von Browser Use von Python nach TypeScript. Gesamtkosten: knapp unter 800 Dollar. Etwa 10,50 Dollar pro Stunde und Agent.
Die Technik
Ein Ralph Loop (benannt nach der Simpsons-Figur, weil man es manchmal einfach krachen lassen muss) ist eine Technik, die der Entwickler Geoffrey Huntley erfunden hat. In ihrer reinsten Form:
while :; do cat PROMPT.md | claude-code; done
Einen KI-Coding-Agenten starten, ihn fertig werden lassen, ihn mit frischem Kontext wieder starten. Wiederholen, bis die Arbeit erledigt ist. Huntley sagt es so: „Ralph kann bei Greenfield-Projekten in den meisten Unternehmen den Großteil des Outsourcings ersetzen. Es hat Mängel, aber die lassen sich erkennen und mit verschiedenen Arten von Prompts beheben.“ Oder, provokanter: „Das ist das Schöne an Ralph: Die Technik ist deterministisch schlecht in einer undeterministischen Welt.“
Ein Ingenieur, dem Huntley die Technik beigebracht hat, lieferte einen Auftrag über 50.000 Dollar als getestetes MVP für 297 Dollar an Rechenkosten ab. Diese Zahl lässt aber mit ziemlicher Sicherheit die Prompt-Iterationen, die Debugging-Runden, die menschliche Prüfung und die Architekturentscheidungen weg, die vor dem Loop gefallen sind. Die Rechenleistung wurde billiger. Die Anforderung ans Können hat sich verschoben, verschwunden ist sie nicht.
Warum frischer Kontext zählt
Wenn Sie mit einem KI-Coding-Werkzeug arbeiten, hängt jeder Austausch etwas an eine wachsende Token-Folge an. Das Modell verarbeitet Ihren gesamten Verlauf, nicht nur die letzte Nachricht. Mit wachsendem Kontext verteilt sich die Aufmerksamkeit auf immer mehr Information. Irgendwann stoßen Sie an Grenzen, und die übliche Lösung, das Gespräch zusammenzufassen und so zu komprimieren, ist verlustbehaftet. Wichtige Anweisungen gehen in der Abstraktion unter. Der Bezugsrahmen des Modells verschlechtert sich Schritt für Schritt. Huntley nennt das: „the pin“ verlieren.
Theo von t3.gg erklärt es so: Stellen Sie sich einen brillanten Ingenieur vor, dessen Gehirn gelöscht wird, sobald er zu viel Arbeit auf einmal erledigt. Er kann alles bauen, aber sobald er zu viele Zeilen Code geschrieben hat, wird sein Gedächtnis zurückgesetzt. Die Techniken, die Sie entwickeln würden, um ihn schnell wieder auf den Stand zu bringen: Genau darum geht es beim Ralph-Loop-Engineering.
Ralph umgeht die Komprimierung, indem er jede Iteration als Neustart behandelt. Das Gedächtnis liegt nicht im Kontext des Modells, sondern im Dateisystem: Git-Commits, Fortschrittsdateien, Aufgabenlisten. Jede Iteration liest den aktuellen Zustand, entscheidet, was zu tun ist, macht eine Sache gut und aktualisiert den Zustand für die nächste Iteration.
Neu ist das nicht. Es ist eine Wiederentdeckung: Zustandslose Worker plus dauerhafter Zustand schlagen clevere In-Memory-Abstraktionen. Unix wusste das. Verteilte Systeme wissen es seit Jahrzehnten. Die LLM-Werkzeuge holen gerade auf.
Die Architektur, die die meisten falsch verstehen
Als Ryan Carson eine Schritt-für-Schritt-Anleitung für Ralph Loops zusammenstellte, antwortete Huntley: „Das ist es nicht.“ Das Claude-Code-Plugin, das viele Entwickler verwenden? Auch kein richtiger Ralph Loop. Der entscheidende Unterschied liegt in der Kontrollhierarchie. In einem richtigen Ralph Loop ist das Bash-Skript die äußere Schicht, die den KI-Agenten steuert. Es kann ihn jederzeit beenden und mit frischem Kontext neu starten. Die Quelle der Wahrheit ist das Dateisystem (das PRD, die Fortschrittsdatei, die Git-Historie), nicht der interne Zustand des Agenten.
Das Plugin dreht das um: Der Agent steuert die Schleife. Er bleibt in einer Session, stößt an die Kontextgrenzen, komprimiert, verliert Information und macht geschwächt weiter. Sie haben verhindert, dass der Agent stehen bleibt, aber den Kontextverfall nicht gelöst, sondern nur versteckt. Denken Sie an ineinander verschachtelte Schachteln. Ralph gehört nach außen und bestimmt, wann der Agent lebt und wann er stirbt. Wenn der Agent Ralph steuert, verlieren Sie den Kernnutzen.
Denselben Fehler haben Entwickler schon bei lang laufenden JVMs gegenüber kurzlebigen Prozessen gemacht, bei zustandsbehafteten CI-Jobs gegenüber idempotenten Pipelines. Wenn Ihr Agent seinen eigenen Lebenszyklus besitzt, haben Sie Beobachtbarkeit und Determinismus verloren.
Was passiert, wenn man es laufen lässt
Der Erfahrungsbericht des YC-Hackathon-Teams zeigt am klarsten, wie Ralph in der Praxis aussieht. Das Team begann mit einfachen Prompts. Für die Portierung von Browser Use nach TypeScript:
Your job is to port browser-use monorepo (Python) to better-use (Typescript)
and maintain the repository.
Make a commit and push your changes after every single file edit.
Keep track of your current status in browser-use-ts/agent/TODO.md
Das sind 42 Wörter. Als das Team den Prompt mit Claudes Hilfe „verbessern“ wollte, blähte er sich auf 1.500 Wörter auf. Der Agent wurde sofort langsamer und dümmer. Zurück auf 103 Wörter, und alles lief wieder. Einige Verhaltensweisen überraschten das Team:
Frühes Stoppen: Die Agenten schrieben Tests, hielten sich an die ursprünglichen Anweisungen und erklärten Portierungen meist von selbst für „fertig“. Ein Agent beendete sich mit pkill selbst, nachdem er erkannt hatte, dass er in einer Endlosschleife festhing.
Übereifer: Nach der ersten Portierung begann der Python-Agent für das AI SDK, Funktionen hinzuzufügen: Integrationen für Flask und FastAPI ohne JavaScript-Gegenstück, dazu Unterstützung für mehrere Schema-Validatoren.
Geordneter Leistungsabfall: Die Agenten kamen auf etwa 90 Prozent Fertigstellung, der Rest brauchte interaktive Sessions. Aber 90 Prozent über Nacht, während man schläft, verändern die Arbeit grundlegend, jedenfalls bei der richtigen Art von Problemen.
Die eigentliche Lektion hat nichts mit Parallelität zu tun
Huntley versteht Ralphs Fehlschläge als Signale zum Nachjustieren: „Jedes Mal, wenn Ralph eine falsche Richtung eingeschlagen hat, habe ich nicht den Werkzeugen die Schuld gegeben, sondern bei mir selbst nachgesehen. Jedes Mal, wenn Ralph etwas Schlechtes tut, wird Ralph gestimmt, wie eine Gitarre.“
Was tatsächlich passiert, lässt sich genauer sagen: Der Agent optimiert gierig bei nur teilweiser Beobachtbarkeit und neigt bei unvollständigem Zustand zu lokalen Optima. Diese Sichtweise zählt, weil sie vorhersagt, wie er scheitert: architektonische Sackgassen, semantische Verschiebungen, die globalen Kontext brauchen, Refactorings, die alles anfassen.
Ralph wird oft als Absage an Parallelität zitiert: Aufgaben laufen linear ab, statt sich auf mehrere Agenten zu verteilen. Klassische Softwareentwicklung zerlegt Projekte in parallele Aufgaben, aber das bringt Komplexität mit sich: Konflikte, Abhängigkeiten, Koordinationsaufwand. Und wenn Ihre Agenten ständig ihr Gedächtnis verlieren, entdeckt ein Agent, der für die Aufgaben sechs, sieben und acht zuständig ist, immer wieder neu, dass Aufgabe sieben von Aufgabe zwei abhängt. Jedes einzelne Mal.
Aber die lineare Ausführung ist nicht der Zauber. Idempotenz ist es.
Es hilft, dass jede Iteration neu startbar ist und jede Aufgabe unabhängig überprüfbar, ohne die Annahme eines gemeinsamen Gedächtnisses in den Agenten. Agenten im Ralph-Stil ließen sich durchaus sicher parallelisieren, wenn man sie wie Cron-Jobs mit Konflikterkennung behandelt und nicht wie Mitarbeiter mit gemeinsamem mentalem Zustand.
Gefährlich wird es, wenn man daraus schließt, „Parallelität ist schlecht“, obwohl die eigentliche Lektion lautet: Parallelität ohne strenge Verträge über den Zustand ist schlecht. Das ist eine Erkenntnis aus den verteilten Systemen und nichts LLM-Spezifisches.
Wo Ralph versagt
Die Technik funktioniert, aber zur intellektuellen Redlichkeit gehört es, ihre Grenzen anzuerkennen.
Bereiche mit impliziter Korrektheit: Ralph funktioniert am besten dort, wo es Tests gibt oder wo sie sich billig ergänzen lassen. In der Finanzwelt, bei Infrastruktur oder bei Compilern, wo Korrektheit implizit ist, wird die Technik teuer. Sicherheitsregressionen, Lizenzkontamination, subtile semantische Bugs und modulübergreifende Invarianten fängt die Frage „Besteht es den Typecheck und die Tests?“ nicht ab.
Neubau gegenüber Wartung: Es ist ein erheblicher Unterschied, ob man Browser Use portiert oder es zwei Jahre lang wartet. Loops mit frischem Kontext sind stark darin, voranzukommen. Schwächer sind sie darin, die architektonische Absicht zu bewahren, undokumentierte Einschränkungen zu respektieren und langfristige Entropie zu vermeiden.
Versteckte Arbeit: Sie tauschen interaktives Programmieren gegen Spezifikationsarbeit, Prompt-Design, die Zerlegung von Aufgaben, Fehleranalyse, Repository-Hygiene und Infrastruktur zur Überprüfung. Die Anekdote von 50k Dollar für 297 Dollar spiegelt die Rechenkosten wider, nicht den Gesamtaufwand. Ralph lagert Kosten aus, beseitigt sie aber nicht.
Das entwertet die Technik nicht. Es grenzt ihren Einsatzbereich ein.
Die Gegenposition: Brauchen Sie das überhaupt?
Peter Steinberger, einer der produktivsten agentischen Programmierer der Community (sein GitHub zeigt einzelne Tage mit über 500 Commits), geht anders vor und nutzt OpenAIs neuere Modelle auf Codex-Basis. Seine Beobachtung: Codex liest 10 bis 15 Minuten lang still Dateien, bevor es Code schreibt. Diese Geduld erhöht die Chance, dass es das Richtige repariert. Claudes Opus ist eifriger, großartig für kleine Änderungen, aber anfällig dafür, Kontext zu übersehen. Diese Unterschiede dürften ebenso sehr an den Voreinstellungen der Werkzeuge, der Verteilung des Token-Budgets und an Trainingseinflüssen liegen wie an einer „Persönlichkeit des Modells“. Der Workflow prägt das Verhalten des Modells. Bevor Sie das als Empfehlung zur Modellwahl nehmen, fragen Sie sich: Liegt es an der Architektur oder nur an der Ergonomie?
Steinbergers Workflow kommt ohne aufwendige Schleifen aus. Er stellt Aufgaben in eine Warteschlange, lässt das Modell arbeiten und vertraut auf die Überprüfung, statt jede Zeile durchzusehen. Sein Rat: „Wenn Sie Ralph nur verwenden, um längere Aufgaben abzuschließen, brauchen Sie es wahrscheinlich nicht.“ Das Ziel von Ralph ist nicht, das Problem zu lösen, dass Agenten zu früh aufhören. Es besteht darin, explizites Zustandsmanagement zu erzwingen.
Praktische Umsetzung
Ryan Carsons Repository bietet einen Einstieg. Das YC-Team hat außerdem RepoMirror gebaut, um Repositories zu portieren:
npx repomirror init \
--source-dir ./browser-use \
--target-dir ./browser-use-zig \
--instructions "convert browser use to Zig"
Die wichtigen Dateien in jedem Ralph-Setup:
- ralph.sh: Bash-Schleife, die frische Agenten-Instanzen startet
- prompt.md: Anweisungen pro Instanz (100 Wörter schlagen 1.500)
- prd.json oder TODO.md: Aufgabenverfolgung mit Erledigungsstatus
- progress.txt oder agent/-Verzeichnis: gesammelte Erkenntnisse
Die entscheidenden Erfolgsfaktoren:
Kleine, unabhängig überprüfbare Aufgaben: Jede sollte in einem Kontextfenster fertig werden und sich isoliert testen lassen. „Eine Datenbankspalte hinzufügen“ hat die richtige Größe. „Das gesamte Dashboard bauen“ nicht.
Commit nach jeder Änderung: Feinkörnige Checkpoints schaffen dauerhaftes Gedächtnis und machen Iterationen neu startbar. Das ermöglicht die Idempotenz.
Starke Feedback-Schleifen: Tests, Typprüfungen, CI. Ohne Überprüfung summiert sich kaputter Code über die Iterationen.
Scratchpad-Verzeichnisse: Lassen Sie den Agenten langfristige Pläne extern ablegen. Daraus wird dauerhafter Zustand, der das Löschen des Kontexts übersteht.
Was wirklich bleibt
Ralph trifft die wichtigste Verschiebung in der LLM-gestützten Entwicklung:
Produktivität hängt nicht an klügeren Modellen, sondern an besseren Grenzen.
Die Technik ist nicht deshalb wertvoll, weil sie eine Bash-Schleife ist, sondern weil sie Entwickler zwingt, Modelle als Wegwerf-Arbeiter zu behandeln, das Gedächtnis in überprüfbare Artefakte zu verlagern und Workflows zu entwerfen, die Amnesie überstehen. Das ist keine Magie. Das ist Ingenieursdisziplin, angewandt auf ein neues Substrat. LLMs zwingen uns, alte Lektionen über Zustand, Kontrolle und Grenzen neu zu lernen, und zwar schneller, als uns lieb ist. Wenn Ralph Entwickler dazu bringt, Kontext als Ressource zu sehen, die man verwaltet, und nicht als Annehmlichkeit, die man anhäuft, leistet er echte Arbeit. Die Technik zählt weniger als das mentale Modell, das sie vermittelt. Verwechseln Sie nur nicht die Schleife mit dem Hebel.
Mehr zu agentischen KI-Architekturen finden Sie in unseren Beiträgen Der Agentic Loop erklärt, Sandboxing autonomer Agenten und Wenn KI-Agenten aus dem Ruder laufen.
Aus dem Englischen übersetzt: zum Originalbeitrag