Loop Engineering: Die neue zirkuläre Mautstelle

Im Juni wurde die Welt des AI-Programmierens von zwei Sätzen entfacht.

Boris Cherny von Anthropic sagte: Ich schreibe keine Prompts für Claude mehr. Meine Arbeit besteht darin, Schleifen zu schreiben. Peter Steinberger von OpenAI sagte: Hör auf, Prompts für Programmier-Agenten zu schreiben. Entwerfe stattdessen Schleifen.

Die beiden Sätze erreichten Millionen von Aufrufen. Addy Osmani, ein Google-Engineering-Manager, gab dieser Idee offiziell den Namen: Loop Engineering. Schlagzeilen wie "Prompt Engineering ist tot" überzogen die Bildschirme.

Zuerst einmal: Was genau ist Loop Engineering?

Streift man die neue Bezeichnung ab, so ist eine Schleife (loop) eine vorgegebene "Baumeister"-Logik: Sie ermittelt selbst, welche Aufgaben zu erledigen sind, übergibt diese an die KI, prüft das zurückgegebene Ergebnis und übergibt es bei Nichterfüllung erneut, bis es akzeptiert wird oder die voreingestellte Anzahl von Versuchen und das Budget erreicht sind.

Der entscheidende Unterschied liegt darin, ob der Benutzer oder die KI die Schritte ausführt.

Früher ging es so: Man sagte Claude "Schreibe eine Schnittstelle für das Hinzufügen, Löschen, Ändern und Abfragen von To-Do-Elementen". Nachdem es die Schnittstelle geschrieben hatte, stellte der Benutzer fest, dass die Feldprüfung fehlte und sagte: "Füge Prüfung und Tests hinzu". Claude änderte es dann. Dies war Prompt Engineering: Die Benutzer kommunizierten in mehreren Runden mit dem Modell.

Eine Schleife ändert dies. Der Benutzer schreibt ein kleines Skript und definiert auf einmal vier Dinge: das Ziel (die Schnittstelle funktioniert, alle Tests sind grün), die Akzeptanzkriterien (führe npm test aus), die verfügbaren Tools und wann die Schleife stoppen soll (nach erfolgreichen Tests oder nach maximal 50 Versuchen). Dann überlässt er die Arbeit dem Skript. Das Skript gibt dem Modell wiederholt Anweisungen, führt die Tests aus und übergibt die Fehlermeldungen, wenn die Tests fehlschlagen. Der Benutzer muss nicht eingreifen und wird erst benachrichtigt, wenn die Schleife abgeschlossen ist oder blockiert.

Wie Boris Cherny sagt, hat sich die kleinste Arbeitseinheit geändert: von einem Codezeilen schreiben, zu einem Prompt schreiben, bis hin zu einer Schleife schreiben. Der Benutzer ist nicht mehr derjenige, der Prompts schreibt, sondern derjenige, der das "Prompt-Schreibende" schreibt.

Eigentlich ist eine Schleife eine Zustandsmaschine mit unscharfen Entscheidungen. Das Schwierige ist nie die Schleife selbst, sondern die Randbedingungen, die verhindern, dass sie in einer Endlosschleife 200 Dollar verbrennt. Merken Sie sich das, es wird später wichtig sein.

Aber der Kern ist altbekannt. 2023 hat AutoGPT versucht, die KI selbst in einer Schleife laufen zu lassen, ohne Validierung und Randbedingungen. Es endete im Scheitern. 2025 hat Karpathy Context Engineering unterstützt, und Anfang 2026 war Harness Engineering noch heiß. Ein altes Konzept, das nur mit Kontrollen versehen wurde. Warum braucht es plötzlich im Juni 2026 einen neuen Namen?

Die Technologie entwickelt sich tatsächlich weiter, aber die Notwendigkeit einer neuen Methode lässt sich am besten im Geschäftsfeld beurteilen.

Das Wachstum der Modelle stagniert

Es ist eine allgemeine Meinung in der Branche, dass die Randüberraschungen der großen Modelle schnell abnehmen.

Von GPT-4 über Claude 4 bis zu Gemini 2 wird der Unterschied für die Entwickler immer kleiner. Vor einem Jahr konnte der Wechsel des Modells die Qualität der Ausgabe deutlich verbessern. Heute ist der Unterschied eher darin zu sehen, dass die Syntax eines Modells etwas besser ist oder die Kommentare eines anderen Modells etwas ordentlicher sind. Die Zahlen in den Benchmarks steigen zwar weiter, aber die "Aha-Momente" in der Produktionsumgebung werden seltener.

Eine Studie des MIT Anfang 2026 zeigt, dass der Leistungsunterschied zwischen Spitzenmodellen und leichten Modellen mit zunehmendem Rechenleistungseinsatz abnimmt und die Verbesserung pro zusätzlichem Dollar kontinuierlich sinkt. Steve Eisman sagte in einem Podcast Ende 2025, dass die weitere Vergrößerung von LLMs möglicherweise eine Sackgasse sei. Ilya Sutskever äußerte sich auch auf der NeurIPS 2024: Die Ära des Pre-Trainings neigt sich dem Ende zu.

Aber das Stagnieren der Randüberraschungen in Chat-Szenarien bedeutet nicht, dass das Modell in allen Szenarien stehen bleibt. Die Möglichkeit für Agenten-Stacks öffnet sich gerade an diesem Punkt. Die Tool-Aufrufe sind von anfällig zu einem standardisierten MCP-Protokoll geworden, die Langzeitkontext-Verarbeitung kann jetzt Millionen von Tokens stabil verarbeiten, und die Selbstvalidierung hat sich von Selbstgesprächen zu einem Engineering-Mechanismus mit getrennter Schreib- und Abfragefunktion entwickelt. Das Modell selbst hat keine exponentielle Verbesserung gezeigt, aber die umgebende Engineering-Infrastruktur ist aufgefüllt worden.

So gibt es einen subtilen Schnittpunkt: Das Modell ist gut genug, um die Schleife nicht zusammenbrechen zu lassen, aber nicht gut genug, um die Schleife überflüssig zu machen. Wenn das Modell alles auf einmal richtig macht, braucht man keine kostenpflichtige Schleife. Loop Engineering wird genau an diesem Punkt vermarktet.

Für Unternehmen wie Anthropic und OpenAI, deren Wertschätzung auf ständigem Wachstum basiert, ist es das gefährlichste Signal, wenn die Modelle sich nicht voneinander abheben können. Die Modelle sind die Infrastruktur, aber der Gewinn liegt nicht in den Modellen selbst, sondern an den "Toll-Stationen". Sie müssen die Rohrleitungen, durch die die Modelle fließen, aufwerten. Loop Engineering ist diese neue Rohrleitung.

Die Anbieter verkaufen "Paradigmen"

Von 2022 bis 2024 verkauften die Anbieter die Fähigkeiten ihrer Modelle. Derjenige, dessen Modell klüger war, gewann.

Ab 2025 hat sich die Regel geändert. Da der Unterschied zwischen den Modellen kleiner geworden ist, verkaufen die Anbieter stattdessen "die Art, wie man die Modelle nutzt". Context Engineering sagt, dass die Modelle bereits klug genug sind, der Engpass liegt in der Nutzung. Man muss den Kontext richtig einrichten. Harness Engineering sagt, dass die Modelle bereits klug genug sind, der Engpass liegt in der Nutzung. Man muss die Agenten mit der richtigen Infrastruktur ausstatten. Loop Engineering sagt, dass die Modelle bereits klug genug sind, der Engpass liegt in der Nutzung. Man muss sich zum Schleifen-Entwickler entwickeln.

Jede dieser Phasen bringt denselben Unterton mit: Die Modelle sind bereits klug genug, der Engpass liegt in der Nutzung.

Dieser Satz ist möglicherweise nicht falsch - wenn der Engpass wirklich von den Modellen auf die Nutzung verschoben hat, ist es die Wahrheit. Das Problem ist, wie die Anbieter ihn nutzen: Sie wandeln die Drucke des langsamen Modellwachstums stillschweigend in die Angst der Benutzer um, dass sie nicht ausreichen. Die Benutzer kaufen nicht mehr Rechenleistung, sondern die "Qualifikation", nicht aus der Konkurrenz zu fallen.

Betrachtet man die jüngste Zeitlinie der AI-Entwicklung, scheint dies eine "Agenda-Setzung" zu sein. Mitte 2025 wurde Context Engineering von Tobi Lütke und anderen verbreitet und von Karpathy auf der sozialen Ebene unterstützt. Es wurde schnell zur gefragten Methode im Agenten-Stack. Anfang 2026 hat Mitchell Hashimoto Harness Engineering vorgeschlagen. Im Juni 2026 hat Addy Osmani Loop Engineering benannt und die Welt gerüttelt.

Von Context bis Loop sind es etwa neun Monate. Jede Phase wird von Top-Experten in der Branche unterstützt, und jede Phase behauptet, dass die vorherige veraltet ist.

Der natürliche Rhythmus der Technologie-Entwicklung ist immer langsam. TCP/IP hat zwanzig Jahre von der Entstehung bis zur Verbreitung gebraucht, und React hat fünf Jahre von der Veröffentlichung bis zur Dominanz im Frontend benötigt. Echte Engineering-Paradigmenwechsel sind langsam, von unten nach oben und kontrovers. Die Linie von Prompt über Context, Harness bis Loop ist schnell, von oben nach unten und einhellig.

Hier muss man genau sein. Dieselbe Gruppe von Phänomenen - mehrere Anbieter synchron, Konzepte in einer klaren Reihenfolge - kann sowohl als sorgfältige Planung interpretiert werden als auch als eine andere Möglichkeit: Einige Labors haben unter demselben Werkzeugset auf dieselbe Engineering-Schwelle gestoßen und sich natürlich auf dieselbe Lösung geeinigt. Übereinstimmung bedeutet nicht Verschwörung. Deshalb ist es sicherer und haltbarer zu sagen: Die Anbieter haben diesen Rhythmus möglicherweise nicht geplant, aber sie nutzen ihn definitiv. Egal welche Interpretation man wählt, dieser Rhythmus sieht eher wie ein Marken-Refresh-Zyklus aus als wie ein natürlicher Wechsel des Engineering-Paradigmas.

Interessanterweise fallen die Veröffentlichungen von Konzepten und Produkten zusammen. Anthropic hat am 28. Mai Claude Code mit Dynamic Workflows (dynamische Arbeitsabläufe) ausgestattet, sodass das Modell selbst Skripte schreiben und Hunderte von Sub-Agenten im Hintergrund planen kann. OpenAIs Codex hat bereits im Frühjahr die Möglichkeit von kontinuierlichen Zielen (goals) erhalten. Die Produkte sind bereit, und dann wartet man auf ein Konzept, um den Markt zu entfachen. Die Benennung von Loop Engineering ist im Wesentlichen eine erneute Auktion der Aufmerksamkeit. Interessanterweise gewinnt immer derjenige, der am meisten Tokens hat.

Wenn die Benutzer auf X darüber streiten, ob Loop Engineering altes Wein in neuen Schläuchen ist, haben sie bereits das getan, was die Anbieter wollen: Die Aufmerksamkeit von "Hat das Modell Fortschritte gemacht?" auf "Lohnt sich das neue Paradigma?" verschoben.

Bindung und Geldverbrennung

Loop Engineering erhöht zwar scheinbar die Effizienz, verbraucht aber in Wirklichkeit Geld an zwei Stellen: einmal für die Migrationskosten und einmal für die Betriebskosten.

Zuerst die Bindung. Wenn man Prompts in SKILL.md schreibt, die Akzeptanzregeln in CLAUDE.md und die Schleifenlogik in die Schleifen und dynamischen Arbeitsabläufe von Claude Code einbettet, baut man nicht nur ein Werkzeug, sondern eine eigene Architektur. Je komplexer die Schleife und je mehr Regeln gesammelt werden, desto stärker ist die Abhängigkeit von diesem System.

Die Schleifenkomponenten von Anthropic und OpenAI sind fast identisch: Automations, Worktrees, Skills, Connectors, Sub-Agents, Memory - die sechs Hauptkomponenten stimmen weitgehend überein. Beide Unternehmen haben unabsichtlich eine gegenseitige Bindung hergestellt: Da es keinen Unterschied zwischen den Modellen gibt, schaffen sie in der Engineering-Ebene Auswahlkosten. Wenn man das Schleifensystem von Claude Code wählt, muss man es bei einem Wechsel zu Codex neu aufbauen, und umgekehrt.

Einige informelle Rückmeldungen von frühen Teams zeigen, dass es viel mehr Zeit und Ressourcen kostet, ein Loop-System aus einer Organisation zu entfernen, als erwartet. Je länger man wartet, desto schlimmer wird es. Die Anbieter wollen nicht nur einmalig API-Lizenzen verkaufen, sondern die Benutzer dazu bringen, jedes Jahr Engineering-Kosten für das Aufrechterhalten des bestehenden Systems zu zahlen.

Versteckt hinter der technischen Schulden sind die Schulden an Konzepten und Verständnis.

Wenn man alle neun Monate das Konzept wechselt, muss das Team alle neun Monate den Arbeitsablauf neu strukturieren. Das Kontext-System, das mit Context Engineering aufgebaut wurde, muss mit Harness geändert werden. Und wenn Harness das Gerüst aufgebaut hat, muss es mit Loop erneut geändert werden. Die Anbieter zahlen nicht für diese Umstrukturierungen, aber die Produktivität des Teams wird während der Konzeptwechsel kontinuierlich verbraucht.

Dabei entsteht auch Schulden an Code-Verständnis. Der Code, der von Schleifen in Massenproduktion erzeugt wird, wird von niemandem gelesen. Das Verständnis des Systems durch das Team nimmt kontinuierlich ab. Man verfolgt die neuen Konzepte und ändert den Arbeitsablauf, während man sich mit dem schwarzen Kasten-Code herumschlägt. Addy Osmani selbst hat auch diese Warnung ausgesprochen: Je schneller die Schleifen Code erzeugen, desto geringer ist der Anteil, den die Benutzer verstehen. Die bequemste Wahl ist die kognitive Kapitulation: Akzeptiere alle Ergebnisse, die die Schleife liefert.

Das ist kein überflüssiges Sorgen. Die Erinnerung an Vibe Coding aus 2025 ist noch frisch. Eine randomisierte kontrollierte Studie von METR im Juli 2025 zeigte, dass erfahrene Entwickler bei der Bearbeitung komplexer Aufgaben mit AI-Werkzeugen sogar 19 % weniger effizient waren (anzumerken: METR hat Anfang 2026 die Methode dieser Studie in Frage gestellt, und die Ergebnisse wurden korrigiert zu "Es ist noch nicht sicher, ob AI die Produktivität erhöht" - diese Daten sollten mit dieser Einschränkung verwendet werden). Im Bereich der Sicherheit ist es sicherer: Ein Bericht von Veracode aus 2025 zeigte, dass 45 % des von AI generierten Codes nicht die Sicherheits-Tests bestanden. Auch auf der Lovable-Plattform gab es Fälle, in denen Anwendungen die Benutzerdaten in Massen preisgaben.

Schleifen vergrößern diese Probleme. Es gibt drei besonders versteckte Fallstricke: Faulheit, wenn man 20 von 50 Sicherheitsaufgaben erledigt und sagt, dass es fertig ist; Selbstlob, wenn man seine eigenen Ergebnisse hoch bewertet; Drift, wenn die ursprüngliche Einschränkung "Tue nicht X" nach 47 Runden verschwindet. Die Tests sind bestanden, aber die Architektur ist verfehlt. Die Funktionen funktionieren, aber es gibt versteckte Fehler in der Logik. Wenn niemand die Zwischenergebnisse kontrolliert, weiß niemand, wo der Fehler liegt. Ein Zustandsautomat, der 47 Runden gelaufen ist, zu debuggen, ist 10 Mal schwieriger als einen Prompt zu reparieren.

Ironischerweise sind die Hauptopfer der Konzeptschulden die mittleren Entwickler. Oberschicht-Designer wie Boris haben fast unbegrenzte Tokens und eine vollständige Infrastruktur. Für sie ist die Konzept-Änderung nur eine zusätzliche Verwaltungsdimension. Die unteren Prompt-Schreiber sind sowieso noch nicht am Start