Ein Tweet vom "Vater des Hummers": Das Ende der Loop-Ära?
„Diskutieren wir noch über Loops – oder sind wir bereits bei Graphen angekommen?“
Am 18. Juli 2026 verkündete Peter Steinberger mit diesem Satz auf der Plattform X still und leise das Ende der Ära des Loop-Engineerings. Der Beitrag erreichte innerhalb von zwei Tagen nach der Veröffentlichung 2,6 Millionen Aufrufe.
Vor sechs Wochen erzielte er mit dem Konzept „Loops entwerfen, die Agents anweisen“ 8,4 Millionen Aufrufe und machte Entwickler weltweit bewusst, dass die Ära des Prompt-Engineerings vorübergeht und das Loop-Engineering die neue Richtung ist.
Mit insgesamt über 11 Millionen Aufrufen für die beiden Beiträge wurde die heißeste Diskussion im Bereich der KI-Programmierung auf die nächste Stufe gehoben.
Der Aufstieg der Loops
Im vergangenen Monat wurde „Loop Engineering“ schnell zu einem populären Konzept im Bereich der KI-Programmierung.
Seine eigentliche Ursprünge gehen jedoch auf vor einem Jahr zurück. Im Juli 2025 schlug der Softwareentwickler Geoffrey Huntley eine Methode vor, die er „Ralph“ nannte – eine einfache Bash-Schleife, die Claude Aufgaben wiederholt ausführt, bis das Ziel erreicht ist:
while :; do cat PROMPT.md | claude-code ; done
Der Kern der Ralph-Methode liegt darin, die Einschränkungen des Kontextfensters zu umgehen. Mitte 2025 betrug die maximale Größe des Kontextfensters 200.000 Token. Dies reichte für komplexere Aufgaben bei weitem nicht aus, sodass der Agentenablauf in kleinere Ausführungseinheiten unterteilt und nacheinander ausgeführt werden musste.
Vor diesem Hintergrund funktioniert die Ralph-Methode wie folgt:
- Definieren Sie ein Ziel für das Projekt und lassen Sie den Agenten dann kontinuierlich laufen oder neu starten, bis das Ziel erreicht ist.
- Speichern Sie die bereits abgeschlossene Arbeit in komprimierter Form im Dateisystem, beispielsweise als Protokoll oder aktualisierten Plan.
- Starten Sie den Agenten mit einem völlig neuen Kontext, um „Kontextverunreinigung“ so weit wie möglich zu minimieren.
- Erlauben Sie jedem Agenten, bei Bedarf den „Gesamtplan“ hinzuzufügen oder zu ändern.
Huntley baute mit dieser Methode eine Programmiersprache von Grund auf neu auf und bewies deren Machbarkeit. Erst als stärkere Modelle erschienen, verbreitete sie sich schnell in der Entwickler-Community.
Der Durchbruch von Loop wäre auch ohne einige Kernentwickler von Anthropic und OpenAI nicht möglich gewesen. Zuerst sagte Boris Cherny, der Schöpfer von Claude Code, auf der Entwicklerkonferenz von Anthropic: „Ich gebe Claude keine direkten Prompts mehr. Ich führe einige Schleifen aus, die Claude anweisen und entscheiden, was als Nächstes zu tun ist. Meine Aufgabe ist es, die Schleifen zu schreiben.“
Anschließend postete Peter Steinberger ebenfalls einen Beitrag, in dem er Entwickler aufforderte, keine Programmieragenten mehr direkt zu prompten: „Monatliche Erinnerung: Du solltest Programmieragenten nicht mehr selbst prompten. Du solltest Schleifen entwerfen, die Agents anweisen.“
Daraufhin verfasste der ehemalige Google-Ingenieur Addy Osmani einen eigenen Artikel mit dem Titel „Loop Engineering“, in dem er es zusammenfasste: „Beim Loop-Engineering geht es darum, sich aus der Position des direkten Promptens von Agents zu lösen und stattdessen ein System zu entwerfen, das diese Aufgabe für Sie erledigt.“
Mit dem Konzept, dem Namen und der dazugehörigen Infrastruktur ging die Entwicklung schnell voran.
Von April bis Mai 2026 führten Codex, Claude Code und Hermes nacheinander den Befehl /goal ein, der die manuell geschriebenen Schleifen zu einer einzigen Anweisung machte.
Etwa sechs Monate nach der breiten Einführung von Ralph veröffentlichte Codex die Goal-Funktion
In der Codex-Dokumentation heißt es: „Goals sind dauerhafte Ziele in Codex, die einen Gesprächsfaden über mehrere Interaktionen hinweg kontinuierlich zu einem klaren Ergebnis führen lassen. Ein Goal gibt Codex eine Abschlussbedingung an: Welcher Zustand erreicht werden soll, wie der Erfolg überprüft wird und welche Einschränkungen stets eingehalten werden müssen.“
In der Dokumentation wird besonders hervorgehoben: „Ein normaler Prompt sagt: Mach jetzt das. Ein Goal sagt: Arbeite weiter, bis dieses Ergebnis eintritt.“
Bei einer normalen Anfrage verarbeitet Codex die aktuelle Anweisung, gibt das Ergebnis aus und wartet dann auf den nächsten Schritt. Bei Verwendung eines Goals wird ein dauerhaftes Ziel an den Thread angehängt. Nach einer Ausführung kann es die aktuellen Beweise prüfen und beurteilen, ob das Ziel bereits erreicht ist. Wenn die Antwort nein lautet und das Goal noch aktiv ist und das Budget nicht erschöpft ist, kann Codex von dem neuesten Zustand aus weiterarbeiten.
Beispielsweise: „Senken Sie die p95-Latenz im Checkout-Benchmark auf unter 120 Millisekunden, während sichergestellt ist, dass die Korrektheitstestsuite stets durchläuft.“
Dies ist ein ausreichend klares „Abschlusskriterium“, das direkt an den Agenten übergeben werden kann. Anschließend teilt der Agent die Aufgaben selbst auf, erstellt untergeordnete Agenten und läuft kontinuierlich, bis die Arbeit abgeschlossen ist. Das Codex-Team übernahm die Idee der Ralph-Schleife und baute darauf die Infrastruktur auf: Koordination mehrerer Agenten, damit sie sich nicht gegenseitig stören; Zustandsverwaltung; Ausführung von Tests; Starten und Stoppen von Agenten; später kamen Funktionen wie Budgeteinstellungen hinzu.
Architektur der Goals-Funktion
Wie Entwickler Loops verwenden
Was machen Entwickler eigentlich mit Loops? Basierend auf Rückmeldungen aus der Community ist das häufigste Szenario die Bearbeitung periodischer Aufgaben.
Die Fähigkeiten von Loops reichen jedoch weit darüber hinaus. Der wahre Wert des Loop-Engineerings zeigt sich bei komplexeren, langfristigen Aufgaben, die kontinuierliche Iteration erfordern.
Beispielsweise bei der Durchführung groß angelegter Codemigrationen. Rafel Mendiola, Gründer eines Startups, musste eine React-Anwendung in React Native umwandeln. Bei der herkömmlichen Vorgehensweise würde man ein großes Epic erstellen und es in 50 bis 100 Tickets unterteilen – allein der Aufbau der Infrastruktur wirkt abschreckend.
Seine Alternative bestand darin, einen Skill zu erstellen, der den Agenten selbst migrierbare Codeblöcke erkennen, die Umwandlung abschließen und den Fortschritt verfolgen lässt. Dieser Skill wurde dann in einen Cron-Job eingefügt, der alle 30 Minuten ausgeführt wird. Im Vergleich zur Verwaltung eines riesigen Migrationsplans ist dieser Ansatz kognitiv viel einfacher.
Nächste Station: Graph
Die Frage in Peters Tweet zeigt tatsächlich einen Entwicklungspfad auf.
Vor einem Jahr war das Prompt-Engineering noch die Kernfähigkeit. Von 2025 bis Anfang 2026 verlagerte sich der Schwerpunkt auf das Entwerfen von Loops. Und nun weist Peter auf etwas weiter Entferntes hin: Das Entwerfen von Graphen, die aus mehreren Loops bestehen – jeder Agent führt seine eigene Schleife aus und ist über Abhängigkeiten miteinander verbunden.
Die beste Antwort im Diskussionsfaden zu seinem Tweet stammt von Luis Catacora: „Loops haben einen großen Spielraum für Fehlertoleranz. Graphen zwingen dich dazu, zuzugeben, wie viel Teil des Workflows noch überhaupt nicht wirklich modelliert ist.“
Dieser Satz zeigt den Unterschied zwischen den beiden Paradigmen. Loops ermöglichen es, den Architekturentwurf zu verschieben: Lassen Sie zuerst einen Agenten die gesamte Arbeit übernehmen, bis er sie nicht mehr bewältigen kann. Graphen erfordern, dass Sie die gesamte Struktur im Voraus deklarieren – wer wofür verantwortlich ist, welche Aufgaben von welchen anderen abhängen und was zu tun ist, wenn ein Zweig fehlschlägt. Loops sind verzögerte Entscheidungen, Graphen sind vorausschauende Entscheidungen.
Shubham Saboo, leitender KI-Produktmanager bei Google und Autor des Code-Repositorys Awesome LLM Apps (mit über 124.000 Sternen auf GitHub), liefert eine weitere Aufschlüsselung und unterscheidet zwei Ebenen: „Ein langlebiger Organisationsgraph definiert, wer für welchen Bereich verantwortlich ist und behält den Kontext bei; ein Arbeitsgraph definiert, was aktuell zu tun ist, und kann je nach Beweisen aufgeteilt, zusammengeführt, neu sortiert oder direkt verschwinden.“
Was zum Teufel ist eigentlich ein Graph?
Loops machen das Verhalten von Agents programmierbar. Graphen machen die Organisation von Agents programmierbar.
Der nächste Schritt sind dynamische Agentenorganisationen: Während der Aufgabenausführung schreibt der Graph seine eigene Struktur neu.
Preston Holmes: Mindestens zwei Arten von Graphen sind wichtig. Die erste Art ist der Graph, der aus langlebigen Agenten besteht, wie Sie ihn gezeigt haben – sie sind wie eine Zonenverteidigung, jeder ist für einen Bereich verantwortlich. Die zweite Art ist der Graph, der durch die zu erledigende Arbeit entsteht. Er ist dynamisch und verändert sich ständig.
Shubham Saboo: Der langlebige „Organisationsgraph“ bestimmt, wer für jeden Bereich verantwortlich ist und behält den Kontext bei. Der „Arbeitsgraph“ bestimmt, welche Aufgaben aktuell zu erledigen sind. Wenn neue Beweise auftauchen, kann er aufgeteilt, zusammengeführt, neu sortiert oder direkt verschwinden.
Dies ist der Schlüssel zu produktionsreifen Multi-Agent-Systemen: Tatsächlich laufen zwei Graphen gleichzeitig.
Organisationsgraph (Org Graph): Definiert „Wer ist wofür verantwortlich“. Er besteht aus langlebigen Agenten, von denen jeder für einen festen Bereich verantwortlich ist und den Kontext, die Fachkenntnisse und die Werkzeugberechtigungen für diesen Bereich behält. Der Organisationsgraph ist relativ stabil, ähnlich wie die Organisationsstruktur eines Unternehmens.
Arbeitsgraph (Work Graph): Definiert „Was ist jetzt zu tun und wie fließen die Aufgaben“. Er ändert sich ständig mit den Aufgaben und neuen Beweisen, kann aufgeteilt, zusammengeführt, umsortiert oder direkt abgebrochen werden. Der Arbeitsgraph ähnelt eher einem in Echtzeit generierten Projektplan.
Auch Preston Holmes ist der Ansicht, dass beide Graphen wichtig sind und auf unterschiedlichen Zeitskalen laufen. Der Organisationsgraph wird im Voraus entworfen und bereitgestellt; der Arbeitsgraph wird für jede Aufgabe dynamisch erstellt und nach Abschluss der Aufgabe verworfen.
Wenn Loops das Verhalten von Agents programmierbar machen, dann machen Graphen die Organisation von Agents programmierbar. Der nächste Schritt sind dynamische Agentenorganisationen – während der Aufgabenausführung schreibt der Graph seine eigene Struktur neu.
Vom Schreiben von Prompts über das Entwerfen von Loops bis hin zum Aufbau von Graphen verschiebt sich der Fokus der KI-Programmierfähigkeiten kontinuierlich nach oben. Entwickler müssen sich immer weniger darum kümmern, wie sie mit einzelnen Agents kommunizieren, sondern müssen darüber nachdenken, wie sie die Kollaborationsstruktur zwischen den Agents entwerfen.
Referenzlinks:
https://x.com/i/trending/2077885008564646115