Von Prompt-Engineering zu Loop-Engineering

Am 2. Juni 2026 saß Boris Cherny bei „Acquired Unplugged“, präsentiert von WorkOS, und beschrieb seine eigene Arbeit in drei Stufen. Vor einem Jahr schrieb er Code noch von Hand, mit Autovervollständigung als Hilfe. Dann ließ er fünf bis zehn Claude-Sitzungen parallel laufen und promptete jede einzeln. Inzwischen promptet er gar nicht mehr. Er schreibt Loops, die das für ihn übernehmen, während einige hundert Agenten Rückmeldungen aus GitHub, Slack und Twitter auswerten und daraus Vorschläge für die weitere Arbeit erzeugen (1).

Fünf Tage später, am 7. Juni, komprimierte OpenClaw-Erfinder Peter Steinberger denselben Gedanken in einen Satz, der weit über die Entwicklerszene hinaus verbreitet wurde: Man solle aufhören, Agenten zu prompten, und stattdessen die Loops entwerfen, die sie prompten (2). Noch am selben Tag veröffentlichte der Entwickler und Autor Addy Osmani einen Essay, schlicht „Loop Engineering“ betitelt, der der Bewegung ihre viel zitierte Anatomie gab.

Von diesen vier Begriffen trat nur Prompt-Engineering zeitweise als eigenständiger, öffentlich viel beachteter Stellentitel hervor. Anthropic selbst hatte 2023 eine Stelle als „Prompt Engineer & Librarian“ ausgeschrieben, Gehaltsspanne 175.000 bis 335.000 Dollar. Ein bestimmter Hochschulabschluss wurde nicht verlangt, sehr wohl aber Vertrautheit mit der Funktionsweise von Sprachmodellen sowie grundlegende Programmier- und Testkenntnisse (3). Loop-, Context- und Harness-Engineering sind dagegen bis heute eher Praxisbezeichnungen als etablierte Stellentitel. Prompt-, Context-, Harness- und Loop-Engineering sind deshalb weniger eine Reihe neuer Berufe als wechselnde Beschreibungen dafür, an welcher Stelle menschliche Arbeit gerade den größten Unterschied macht. Nicht jede davon hätte einen eigenen Briefkopf verdient.

Bevor man versteht, was da für erledigt erklärt wurde, lohnt der Blick auf das Können, das ein Prompt Engineer 2023 tatsächlich brauchte. Few-Shot-Prompting legte dem Modell ein paar Beispiele vor, bevor die eigentliche Aufgabe kam, eine Technik, die bereits im GPT-3-Aufsatz von 2020 beschrieben wurde (4). Chain-of-Thought-Prompting brachte ein Modell dazu, seine Zwischenschritte auszuformulieren statt direkt zur Antwort zu springen, was bei mehrstufigen Aufgaben nachweislich bessere Ergebnisse lieferte (5), obschon diese Zwischenschritte selbst wieder erzeugter Text bleiben und den internen Entstehungsweg einer Antwort nicht verlässlich abbilden, wie eine vielzitierte Studie 2023 an verzerrten Multiple-Choice-Aufgaben zeigte (6). Dazu kamen Rollenzuweisungen, ein sorgsam gewählter Temperature-Wert als Teil der Modellsteuerung, nicht des Prompts selbst, und ein zäher Zyklus aus Formulieren, Testen, Nachschärfen.

Selbst Anthropics eigene Stellenausschreibung verlangte damals bereits mehr als gutes Sprachgefühl: den Aufbau von Promptketten, deren Dokumentation und eine wiederverwendbare Bibliothek für andere Teams. Prompt-Engineering zielte von Anfang an aufs System, der einzelne Satz war nur sein sichtbarster Teil.

Das Neue am Juni 2026 ist, streng genommen, nicht die Schleife selbst. Schon 2021 beschrieb ein vielzitierter Aufsatz Metaprompts, mit denen ein Modell sich seine eigenen aufgabenspezifischen Prompts erzeugt (7). ReAct verband 2022 Schlussfolgern und Handeln zu einem wiederholten Ablauf (8). Reflexion ließ Agenten 2023 aus sprachlichem Feedback lernen und einen nächsten Versuch ableiten (9). Ende 2024 beschrieb Anthropic in einem vielgelesenen Grundsatztext bereits Prompt-Chaining, Orchestrator-Worker- und Evaluator-Optimizer-Muster als verbreitete Architekturen, Agenten seien im Kern Modelle, die anhand von Rückmeldungen aus ihrer Umgebung wiederholt Werkzeuge einsetzen.

Entscheidend ist etwas Prosaischeres. Diese Schleifen sind aus Forschungsarchitekturen und selbst geschriebenen Skripten in alltägliche Entwicklungsprodukte gewandert, mit Zeitsteuerung, persistentem Zustand, parallelen Agenten und eingebauten Prüfungen. Früher musste man die Schleife programmieren. Heute muss man vor allem entscheiden, was man ihr anvertraut. Osmanis eigene Anatomie des Loops umfasst Automationen, parallele Arbeitskopien, dokumentiertes Projektwissen, Werkzeuganbindungen, prüfende Nebenagenten und ein Gedächtnis, das den Neustart übersteht. Sie ist damit reichhaltiger als die vereinfachten Vierer- oder Fünferschemata, die seither kursieren, dieses hier eingeschlossen.

Nicht jeder in dieser jungen Debatte hält die ältere Fertigkeit für erledigt. Anthropic selbst hält Context-Engineering weiterhin für zentral und zeigt, wie ein Loop bei jedem Durchlauf neuen Kontext erzeugt, der laufend kuratiert werden muss. OpenAI beschreibt parallel, wie sich der eigene Softwareentwicklungsprozess vom Schreiben einzelner Codezeilen zum Entwerfen der Umgebung verschoben hat, in der Agenten arbeiten.

Die Schichten greifen ineinander, ohne sich gegenseitig zu ersetzen: Prompt-Engineering gestaltet Anweisungen. Context-Engineering kuratiert die Informationen, die in einem bestimmten Moment verfügbar sind. Harness-Engineering gestaltet Werkzeuge, Rechte, Zustände und Rückmeldungen. Loop-Engineering bestimmt, wann und unter welchen Bedingungen das System erneut handelt oder stoppt. Für die Frage, wer am Ende urteilt, macht es keinen Unterschied, ob man die ältere Fertigkeit für abgelöst oder nur für eine Schicht unter mehreren hält. Das Gewicht ist ohnehin bereits gewandert.

Der GitHub-Ingenieur Napalys Klicius beschrieb im Juli 2026 einen Fall, der diese Verschiebung genauer fasst als jede Ankündigung. Sein Team hatte den Code-Review-Agenten zunächst auf gemeinsam genutzte Werkzeuge umgestellt, dieselben grep-, glob- und Lesewerkzeuge, die auch andere Copilot-Produkte verwenden. Das Ergebnis war zunächst eine Verschlechterung: Der Agent suchte breiter, las mehr, fand dabei immer neue Gründe für die nächste Suche, eine Schleife ohne eigenes Ende.

Erst als das Team die Textanweisungen umschrieb, die dem Modell sagen, wann und wie es diese Werkzeuge einsetzen soll, kehrte sich der Effekt um. Ergebnis: rund 20 Prozent geringere durchschnittliche Prüfkosten, bei gleichbleibender Qualität. Der Loop hat das Prompten dort nicht überflüssig gemacht. Er hat einzelne Prompts zu Infrastruktur gemacht: verlagert vom Chatfenster in versionierte Systemtexte, Werkzeugbeschreibungen und Bewertungsschemata, die getestet und gemeinsam weiterentwickelt werden. Verschwunden ist nicht das Formulieren, verschwunden ist nur seine sichtbare Einzelhandlung im Chatfenster.

Anthropics im Januar 2026 veröffentlichter Leitfaden unterscheidet für die Evaluation von Agenten drei Arten von Gradern. Keiner dieser drei ersetzt die anderen, sie erkennen unterschiedliche Fehlerklassen: Ein codebasierter Test stellt einen überprüfbaren Zustand fest, schnell und günstig, aber starr. Ein modellbasierter Grader bewertet offene Ergebnisse anhand einer Rubrik, flexibel, aber selbst nicht deterministisch. Ein menschliches Fachurteil beurteilt Bedeutung, Angemessenheit und Risiko, der Goldstandard, langsam und teuer.

Der Leitfaden unterscheidet deshalb zwischen der Behauptung des Agenten und dem überprüfbaren Zustand in der Welt. Ein Reiseagent, der meldet, ein Flug sei gebucht, hat damit noch nichts bewiesen. Bewiesen ist es erst, wenn in der Buchungsdatenbank tatsächlich eine Reservierung existiert.

Eine vollständig grüne Testsuite beweist, dass die Tests bestanden wurden. Sie beweist nicht, dass die Tests das Richtige prüfen. Ein Agent kann eine Kennzahl erfüllen und den dahinterliegenden Zweck trotzdem verfehlen, ein Problem, das als Goodharts Gesetz bekannt ist: Sobald ein Maßstab selbst zum Ziel wird, verliert er leicht seine Qualität als Maßstab (10).

Bei einem medizinischen oder juristischen Vorgang reicht deshalb die Frage, ob ein Ergebnis formal vollständig ist, nicht aus. Relevant sind auch Herkunft der Information, eingehaltene Verfahrensschritte und mögliche Schäden, Dinge, die sich nicht restlos in eine Prüfroutine gießen lassen. Der Verifier besitzt keine eigene Wahrheit. Er prüft nur, was man ihm zu prüfen gegeben hat, und je ausdauernder ein Loop arbeitet, desto unerbittlicher optimiert er auf genau diesen Maßstab, blinde Flecken eingeschlossen.

Die eigentliche ökonomische Verschiebung zeigt sich weniger daran, dass Arbeit wandert, als daran, dass zwei Kostenarten unterschiedlich schnell fallen. Erzeugung lässt sich vervielfachen, ohne dass im selben Maß mehr Menschen arbeiten. Verifikation lässt sich nicht bei jeder Aufgabe ebenso leicht vervielfachen, sie bleibt teuer, langsam oder strittig, je nachdem, was geprüft werden soll.

Eine aktuelle, noch nicht begutachtete Studie von Achint Mehta an 1.116 automatisiert erzeugten Webanwendungen zeigt, wie ungleich dieser Effekt ausfällt. Ohne Prüfwerkzeug startete ungefähr eine von sieben Anwendungen überhaupt nicht. Ein einfacher Boot-Test beseitigte fast alle diese Ausfälle und benötigte dafür nur rund 35 Prozent der Tokenkosten eines vollständigen Shell-Zugangs. Dieser wiederum kostete etwa das 2,35-Fache eines Laufs ohne Prüfwerkzeuge, ohne die Qualität entsprechend stark zu erhöhen.

Wo sich die Prüfung nicht ebenso leicht automatisieren lässt wie die Erzeugung, entsteht dadurch keine arbeitsfreie Organisation, sondern eine neue Verteilung der Arbeit. Fachleute sichten mehr Entwürfe, Sachbearbeiter übernehmen die Ausnahmefälle, Kundinnen entdecken Fehler, die früher vor der Veröffentlichung aufgefallen wären. Die Maschine senkt die Kosten der Herstellung, ein Teil der Qualitätssicherung fällt dabei an Menschen, deren zusätzliche Arbeit in keiner Produktivitätsrechnung auftaucht. Daraus lässt sich eine praktische Regel ableiten: Automatisierung ist besonders attraktiv, wenn sich Ergebnisse günstig beobachten und Fehler ohne großen Schaden zurücknehmen lassen. Ob ein Vertrag die Interessen einer Partei angemessen schützt oder eine Gestaltung verständlich wirkt, lässt sich erheblich schwerer automatisiert prüfen als ein fehlgeschlagener Serverstart.

Für einen Fachverband, eine Kanzlei oder eine Arztpraxis, die nie einen Prompt Engineer eingestellt haben, klingt das zunächst nach einer internen Debatte der Softwarebranche. Ist es nicht.

Bei einer Kongressplattform kann ein Loop zuverlässig feststellen, ob ein Raum doppelt belegt wurde, ein Vortrag die zulässige Länge überschreitet oder eine Pflichtangabe fehlt: reine Regelprüfung. Ob ein Programm fachlich ausgewogen ist, zwei Beiträge sich inhaltlich überschneiden oder eine Absage gegenüber einer Einreicherin angemessen begründet wurde, ist eine andere Art der Prüfung. Beides heißt Prüfung, doch beides lässt sich nicht im gleichen Maß automatisieren. Wer für die eigene Domäne nicht sagen kann, was in diesem zweiten, unschärferen Sinn als gelungen zählt, kauft sich mit noch so ausgefeilter Software keine Abkürzung. Das Urteilsvermögen lässt sich nicht outsourcen, nur die Ausführung.

Das ist nicht identisch mit dem Menschen in der Schleife, aber beides gehört zusammen. Dort beaufsichtigt ein Mensch eine konkrete Entscheidung. Hier entwirft er zunächst die Kriterien, nach denen Entscheidungen ohne ihn weiterlaufen dürfen. Bei Grenzfällen, hohem Schadenpotenzial und immer dann, wenn der Prüfmaßstab selbst fragwürdig wird, kehrt er in den Prozess zurück. Addy Osmani nennt das die innere und die äußere Schleife: Wer die innere den Agenten überlässt, muss die äußere umso entschiedener selbst führen.

Bald tippt kaum noch jemand jeden Prompt von Hand. Wer weniger formuliert, muss mehr verantworten.