Loop Engineering: Trend der Stunde oder der nächste Sprung?

Mitte Juni machte ein Post von Peter Steinberger, einem Entwickler, der für den Aufbau und späteren Verkauf von PSPDFKit bekannt ist, wochenlang die Runde unter Fachleuten: KI-Agenten werden nicht mehr ge-prompt-et, man entwirft die Loops, die sie antreiben. Wenige Zeilen, ein Tonfall wie eine Offenbarung, und innerhalb weniger Tage tauchte der Begriff „Loop Engineering“ überall auf, von Analytics Vidhya bis hin zu Unternehmensblogs, die auf Agenten-Infrastrukturen spezialisiert sind, wie Requesty. Auch Boris Cherny, einer der Architekten von Claude Code, legte nach und sprach von einem Sprung, der mit dem vom kompilierten Quellcode zu autonomen Agenten vergleichbar sei, wie BDTechTalks bei der Rekonstruktion der Entstehungsgeschichte der Debatte berichtet.

Das klingt vertraut. In den letzten drei Jahren hat die Branche fast alle sechs Monate dasselbe Ritual durchlaufen: erst Prompt Engineering, dann Context Engineering, dann Harness Engineering – jedes Mal mit der Ankündigung eines Paradigmenwechsels. Die ehrliche Frage ist nicht, ob Loop Engineering existiert – es existiert, wie die Tools beweisen, die es konkret implementieren –, sondern ob es wirklich einen konzeptionellen Sprung darstellt oder ob es das letzte Kapitel einer längeren Geschichte ist, die jedes Mal unter einem neuen Namen erzählt wird.

Vom Prompt zum System

Um zu verstehen, was sich ändert, muss man die Abfolge rekonstruieren. Beim Prompt Engineering ging es zwischen 2022 und 2023 um die Formulierung der einzelnen Anweisung, die Wortwahl und die Struktur des unmittelbaren Kontextes, um eine bessere Antwort von einem noch relativ kurzsichtigen Modell zu erhalten. Mit länger werdenden Kontextfenstern und dem Erscheinen der ersten Agenten, die Tools nutzen können, verschob sich die Aufmerksamkeit auf das Context Engineering: was in dieses Fenster hinein soll, welche Dokumente abgerufen werden, wie das Gedächtnis organisiert wird und welche Tools zu einem bestimmten Zeitpunkt verfügbar gemacht werden.

Der nächste Schritt, den BDTechTalks in seinem Artikel über Harness Engineering von Anfang Juni beschreibt, betrifft das Gerüst um das Modell herum, das sogenannte Harness – die Gesamtheit der Tools, Berechtigungen, Sandboxes und Regeln, die ein Sprachmodell in einen Agenten verwandeln, der in einer realen Umgebung ohne ständige Überwachung agieren kann. Hier wird der Vergleich mit der Anatomie nützlich: Wenn das Modell das Gehirn ist, ist das Harness der Körper, der es ihm ermöglicht, in der Welt zu handeln.

Loop Engineering verschiebt in dieser Entwicklung den Schwerpunkt weiter. Es geht nicht mehr nur darum, was das Modell weiß oder womit es interagieren kann, sondern darum, wie sich der Ausführungszyklus im Laufe der Zeit wiederholt, wann er stoppt und wer das Ergebnis prüft, bevor es als endgültig betrachtet wird. Es ist der Unterschied zwischen dem Bau eines guten Werkzeugs und dem Bau des Prozesses, der entscheidet, wann dieses Werkzeug seine Arbeit beendet hat. Requesty unterscheidet in einem Praxisleitfaden für Entwickler, die Agenten in der Produktion einsetzen, vier operative Varianten: Continuous Heartbeat Loops zur Überwachung, zeitbasierte geplante Loops für wiederkehrende Aufgaben, durch externe Ereignisse (wie einen Push in ein Repository) ausgelöste Loops und zielorientierte Loops, die erst beim Erreichen einer expliziten Erfolgsbedingung stoppen; siehe deren Übersicht über Loop-Typen.

Der Schwerpunkt verschiebt sich also tatsächlich vom Inhalt des Prompts auf das ihn umgebende Kontrollsystem. Es bleibt jedoch die Frage, ob diese Verschiebung ein eigenes Etikett verdient oder ob sie einfach die natürliche, fast unvermeidliche Weiterentwicklung des bereits durch das Harness Engineering vorgezeichneten Weges ist.

Nicht erst seit gestern

Hier lohnt es sich, innezuhalten, denn an diesem Punkt riskiert der aktuelle Enthusiasmus, das technische Gedächtnis zu vernebeln. Die Idee eines Systems, das einen Versuch generiert, ihn beobachtet, korrigiert und es erneut versucht, entstand nicht erst mit den LLM-Agenten des Jahres 2026. Das ReAct-Pattern, das 2022 von einer Forschungsgruppe aus Princeton und Google veröffentlicht wurde, formalisierte bereits den verflochtenen Zyklus aus Denken und Handeln, den viele heute einfach „den Loop“ nennen. Im folgenden Jahr fügte Reflexion eine Ebene der verbalen Selbstkritik hinzu: Der Agent liest seinen eigenen Fehler und macht daraus eine Lektion für den nächsten Versuch. Und die Trennung zwischen demjenigen, der eine Lösung generiert, und demjenigen, der sie prüft – das sogenannte Maker-Checker-Pattern –, ist ein softwaretechnisches Prinzip, das so alt ist wie das Code-Review selbst, lange bevor jemand daran dachte, es auf ein Sprachmodell anzuwenden.

Auch die jüngere Literatur bestätigt eher die Kontinuität als den Bruch. Eine Arbeit der Tsinghua-Universität aus dem Jahr 2024 schlägt ein Framework zur iterativen Verfeinerung der Erfahrung für Softwareentwicklungs-Agenten vor, bei dem der Agent seine vergangenen Erfahrungen über aufeinanderfolgende Zyklen hinweg sammelt und filtert – eine Architektur, die vielen heutigen Loops konzeptionell nahesteht und veröffentlicht wurde, als der Begriff „Loop Engineering“ noch gar nicht geprägt war, wie im Original-Paper nachzulesen ist.

Es gibt ein Bild, das die Idee gut wiedergibt und aus einem Bereich fernab der Informatik stammt. Im Detektiv-Videospiel The Forgotten City erlebt der Protagonist denselben Tag dutzende Male – nicht um die sich wiederholende Zeit als Strafe zu erleiden, sondern um sie zu nutzen; jeder Zyklus verfeinert das Verständnis eines Mysteriums, das beim ersten Mal unlösbar schien. Es ist kein Zufall, dass Douglas Hofstadter in Gödel, Escher, Bach dieser Idee bereits einen philosophischen Namen gegeben hatte: den „Strange Loop“ – einen Zyklus, der zu sich selbst zurückkehrt und dabei eine höhere Ebene des Verständnisses erzeugt als die, von der er ausgegangen war. Loop Engineering versucht im Grunde dasselbe mit Code, mit dem Unterschied, dass den Kreis nicht mehr nur die menschliche Intuition schließt, sondern ein zweiter Agent, der als Kontrolleur fungiert.

Was ist also wirklich neu? Nicht die Theorie, die in jahrelanger Forschung über Agenten und Multi-Agenten-Systeme wurzelt. Neu ist die praktische Systematisierung, das Erscheinen dedizierter Befehle wie /loop in Claude Code oder die wiederkehrenden Automatisierungen in Codex, die ein ehemals handwerkliches Muster endlich auf breiter Basis komponierbar und wiederverwendbar machen, wie auch die von max-gherman.dev veröffentlichte technische Analyse zur Anatomie moderner Loops bestätigt. Es ist der Unterschied, der bereits in einem früheren Gespräch über diesen Artikel deutlich wurde: zwischen einer theoretischen Revolution und einer ingenieurtechnischen Reifung – weniger spektakulär anzukündigen, wahrscheinlich aber nützlicher in der Anwendung. Konzeptionelles Schema des Loop Engineering

Wer gewinnt, wer riskiert

Wo funktioniert dieser Ansatz wirklich? Die solidesten Beispiele stammen von Aufgaben mit einem objektiven und mechanisch verifizierbaren Erfolgskriterium: der Agent, der Code korrigiert, bis die Test-Suite besteht; derjenige, der Produktions-Logs überwacht und ein Ticket öffnet, wenn die Fehlerrate einen Schwellenwert überschreitet; derjenige, der Pull-Requests prüft, die älter als ein paar Tage sind, und die Autoren auf Blockaden hinweist. In diesen Fällen hat der Loop einen klaren Schiedsrichter – den Test, der besteht oder fehlschlägt, die Zahl, die den Schwellenwert über- oder unterschreitet –, und die Prüfung erfordert kein menschliches Urteil in Echtzeit.

Das Problem beginnt, wenn dieser Schiedsrichter fehlt oder schwach ist. Wenn das Erfolgskriterium vage ist („der Bericht ist gut genug“, „die Analyse ist vollständig“), riskiert der Loop das, was die technische Analyse von max-gherman.dev als halluzinierte Genehmigung bezeichnet: Ein zweiter Agent erklärt eine nur teilweise erledigte Arbeit für beendet, weil sein eigenes Urteil nicht an etwas mechanisch Verifizierbarem verankert ist. Requesty listet in seinem Leitfaden dieselben Risiken unter anderen Namen auf: das unkontrollierte Ausufern von Iterationen ohne Obergrenze, die Degradierung des Kontextes in sehr langen Loops, die Zustands-Amnesie, wenn der Agent zwischen den Zyklen die Spur verliert, was er bereits verarbeitet hat.

Wer gewinnt in diesem Szenario? Wahrscheinlich die Teams, die sich wiederkehrenden und gut definierten Aufgaben stellen und über ein Budget verfügen, um mit der notwendigen Infrastruktur zu experimentieren: automatische Code-Review, kontinuierliche Überwachung, Datenextraktion im großen Stil. Gewinner sind auch die Infrastrukturanbieter – Model-Routing-Gateways, Orchestrierungsplattformen –, die im Loop Engineering ein neues Vokabular finden, um ein eigentlich bereits existierendes Problem zu verkaufen: nämlich die sichere und kosteneffiziente Verwaltung einer Anzahl von Modellaufrufen, die im Vergleich zu einem einfachen Chat um Größenordnungen wächst. Am meisten riskieren die Teams, die den Enthusiasmus ohne die zugrunde liegende Verifizierungsinfrastruktur übernehmen, in der Überzeugung, es reiche aus, einen Wiederholungszyklus zu einem bereits fragilen Prompt hinzuzufügen, um eine Zuverlässigkeit zu erreichen, die vorher nicht da war. Ein Loop um ein schlechtes Erfolgskriterium erzeugt kein besseres Ergebnis; er erzeugt nur einen Fehler, der mit mehr Selbstbewusstsein wiederholt wird.

Die Abrechnung in Token

Die letzte Frage, die vielleicht am konkretesten für diejenigen ist, die entscheiden müssen, ob sie Zeit in diesen Ansatz investieren, betrifft das Verhältnis zwischen gewonnener Qualität und verbrauchten Ressourcen. Ein Loop ist nicht kostenlos; jede Iteration ist ein neuer Modellaufruf, oft sogar mehr als einer, wenn der Zyklus einen separaten Generator und Verifizierer oder mehrere spezialisierte Agenten vorsieht, die sich die Arbeit teilen. Requesty schätzt, dass ein täglicher Review-Loop mit mehreren Unteragenten bei den leistungsstärksten Modellen zum vollen Preis dutzende Dollar pro Tag kosten kann – eine Summe, die deutlich sinkt, wenn man nur die Schritte, die wirklich fortgeschrittenes Denken erfordern, an die teuersten Modelle leitet und Klassifizierung sowie Vorsortierung an günstigere Modelle delegiert, wie in deren Analyse zu Routing-Kosten beschrieben.

Dies wirft eine Frage auf, die der allgemeine Enthusiasmus gerne in den Hintergrund rückt: Wie viel ist eine zusätzliche Iteration wirklich wert? Wenn der zweite Versuch des Loops einen Fehler korrigiert, der andernfalls in der Produktion gelandet wäre, sind die Kosten wahrscheinlich gut investiert. Wenn der Zyklus jedoch weiterläuft und nur marginale Variationen eines Ergebnisses liefert, das bereits beim ersten Versuch akzeptabel war, handelt es sich um Ausgaben, die im Nachhinein durch kein Kosten-Dashboard zu rechtfertigen sind. Das ernsthafte Maß für den Wert eines Loops ist also nicht, wie viele Iterationen er durchläuft, sondern wie sehr er das Ergebnis im Verhältnis zu den Grenzkosten jedes zusätzlichen Zyklus wirklich verbessert – eine Kalkulation, die in zu vielen enthusiastischen Artikeln zum Thema einfach fehlt.

Eine Disziplin der Kontrolle, keine neue Intelligenz

Um auf die Eingangsfrage zurückzukommen: Verdient Loop Engineering die Aufmerksamkeit, die es erhält? Die ehrliche Antwort lautet ja, allerdings mit einer Einschränkung, die die Tragweite der Ankündigung relativiert. Wir erleben nicht die Entdeckung eines neuen Prinzips; der Zyklus aus Generieren, Verifizieren und Korrigieren stand bereits in den Agenten-Papern von 2022 und noch früher in den Praktiken der traditionellen Softwaretechnik. Was tatsächlich reift, ist die Fähigkeit, dieses Prinzip auf breiter Ebene operabel zu machen – mit nativen Tools, persistentem Zustand außerhalb des Kontextes, Kosten-Routing und Stoppkriterien, die strenger sind als ein einfaches subjektives Urteil.

Es lohnt sich daher zu fragen, ob man in einem Jahr noch von Loop Engineering als eigenständiger Kategorie sprechen wird oder ob der Begriff einfach in den gewöhnlichen Wortschatz der Agentenentwicklung übergehen wird – so wie heute niemand mehr von Prompt Engineering als separater Disziplin spricht, sondern es in jedem technischen Gespräch als selbstverständlich voraussetzt. Vielleicht ist genau das das wahrscheinlichste Schicksal für das Loop Engineering: keine Revolution, an die man sich erinnern wird, sondern ein Baustein, der in ein paar Monaten keinen eigenen Namen mehr braucht, um praktiziert zu werden.