Prompt Engineering ist tot. Lang lebe Loop Engineering.

Das Zitat, das die Illusion zerschlug

Vor ein paar Tagen sorgte ein einziges Zitat von Boris Cherny — dem Ingenieur, der die Entwicklung von Claude Code bei Anthropic leitet — still für Aufsehen in der Software-Community.

Auf einem öffentlichen Panel gab Cherny einen Einblick, wie die Menschen, die die weltweit ausgefeilteste Programmier-KI bauen, tatsächlich mit ihren eigenen Modellen arbeiten. Was er sagte, stellte nicht nur den Status quo infrage — es erklärte eine ganze aufstrebende Disziplin für obsolet:

Lass das sacken.

Der Mann mit beiden Händen am Steuer des besten Entwicklermodells der Welt sagt dir, dass er die Hände vom Steuer genommen hat. Er sitzt nicht in einem Chat-Fenster und feilt am perfekten Absatz von Anweisungen. Er schreibt Code, der die KI zwingt, mit sich selbst zu sprechen, ihre eigenen Fehler zu beurteilen und sie innerhalb eines geschlossenen, autonomen Kreislaufs zu korrigieren. Er baut die Maschine, die das Modell steuert — und lässt sie dann fahren.

Wenn du immer noch deine Tage damit verbringst, Prompts zu optimieren, um dem LLM den richtigen Codeblock zu entlocken, ist seine Botschaft brutal klar: du optimierst eine Welt, die es schon nicht mehr gibt.

Der Paradigmenwechsel: vom Mikromanagement zur Systemarchitektur

Um zu verstehen, warum dies ein tektonischer Wandel ist, schau dir an, wie sich unsere Beziehung zur generativen KI in nur ein paar Jahren entwickelt hat.

Phase 1 — Der lineare Prompt (der menschliche Engpass)

Bis vor Kurzem war die gesamte Branche besessen von Prompt Engineering. Wir behandelten LLMs wie brillante, aber leicht abzulenkende Junior-Entwickler. Der Arbeitsablauf war linear, fragil und vollständig manuell:

du schreibst einen Prompt  ─▶  die KI schreibt Code  ─▶  du findest den Bug  ─▶  du korrigierst den Prompt  ─┐
     ▲                                                                          │
     └─────────────────────────  wieder von Hand  ◀─────────────────────────────┘

In diesem Paradigma ist der Mensch der Engpass. Du schreibst einen Prompt, liest die Ausgabe, entdeckst einen Syntaxfehler, fügst ihn wieder in den Chat ein und betest, dass das Modell den Kontext fünf Schritte später nicht vergessen hat. Es fühlt sich produktiv an. Es ist erschöpfendes, nicht skalierbares Mikromanagement — und es kann definitiv nicht laufen, während du schläfst.

Phase 2 — Loop Engineering (der autonome Kreislauf)

Was Cherny beschreibt, ist Loop Engineering — agentische Workflows, bei denen der Mensch vollständig aus der Ausführungsschleife heraustritt. Du hörst auf, das Auto zu fahren. Du baust die Strecke und lässt die Maschine die Runden drehen.

Statt einen Prompt zu schreiben, um ein Problem zu lösen, schreibst du einen programmatischen Loop, der die KI in einen automatisierten Zyklus aus Ausführung und Verifikation einbettet:

1. Das Ziel. Ein Mensch setzt ein einziges übergeordnetes Ziel — „baue diesen API-Endpunkt und erreiche 98 % Testabdeckung".
2. Die Aktion. Die KI erstellt einen ersten Entwurf des Codes.
3. Die Verifikation. Eine automatisierte Umgebung — Compiler, Linter, Unit-Tests, deine CI — führt den Code aus und findet jeden Fehler.
4. Die Selbstkorrektur. Bei einem Fehlschlag erfasst das System den Stack-Trace, gibt ihn der KI als neue Anweisung zurück und befiehlt ihr, es erneut zu versuchen.

du legst das Ziel fest
     │
     ▼
die KI schreibt Code  ─▶  CI führt jede Prüfung aus  ─▶  grün?  ─▶  ✦ ausgeliefert
     ▲                      │
     │                      ▼  (rot)
     └──  die KI liest die Logs und stellt sich selbst einen neuen Prompt

Der Loop läuft mit Maschinengeschwindigkeit, arbeitet Dutzende Iterationen ab, korrigiert und heilt sich selbst, bis die Verifikationskriterien erfüllt sind. Du hast nicht eine einzige Rückfrage getippt. Du hast die Prompts nicht geschrieben — du hast die Strecke gebaut, und das Modell hat jede Runde selbst gedreht.

Die eigentliche Fähigkeit ist nicht, Code zu schreiben. Es ist, den Richter zu schreiben.

Hier ist der Teil, den fast jeder übersieht — und darum geht es beim ganzen Spiel. Der schwierige Teil eines Loops ist nicht, den Code zu generieren. Modelle sind darin bereits erschreckend gut. Der schwierige Teil ist das, was entscheidet, ob der Code taugt.

Gib dem Loop einen starken, gnadenlosen Verifizierer — echte Tests, statische Analyse, einen Compiler, der sich weigert zu lügen — und er konvergiert zu etwas, das wirklich funktioniert. Gib ihm einen schwachen, und derselbe Loop wird fröhlich einen endlosen Strom selbstsicheren, wunderschön formatierten Mülls produzieren, der sich seinen Weg zu einem grünen Häkchen halluziniert, das nichts bedeutet.

Die Fähigkeit des nächsten Jahrzehnts ist also nicht die Kunst des Promptens. Es ist das Design der Verifikation — die kugelsicheren Validierungssysteme, die es einer KI erlauben, sicher mit sich selbst zu sprechen, ohne von einer Klippe zu stürzen. Das ist eine schwierigere, seltenere und weitaus wertvollere Art von Ingenieurskunst als die richtigen Worte zu finden.

Von der Philosophie zur Produktion: wie wir den Loop entworfen haben

Während der Rest der Tech-Welt Chernys Zitat in den sozialen Medien zerlegt, ist die eigentliche Herausforderung wenig glamourös: wie baut man eine Loop-Engineering-Infrastruktur, die in der Produktion tatsächlich funktioniert — außerhalb von Anthropics internen Laboren?

Schließe einen Loop um ein einzelnes Modell, und du stößt schnell an die Wände der realen Welt: Verschlechterung des Kontextfensters, halluzinatorische Todesspiralen und kein Gedächtnis über ein Projekt hinweg. Bei Fractera haben wir das letzte Jahr damit verbracht, Chernys Philosophie nicht als Vorhersage, sondern als architektonischen Bauplan zu behandeln — und den Loop gebaut, auf dem dieser Arbeitsbereich läuft.

Die Anatomie eines produktionsreifen Loops

Um Loops für echte Software tauglich zu machen, muss man aufhören, das Modell zu bewundern, und anfangen, die drei wenig glamourösen Dinge darum herum zu bauen — den Richter, das Gedächtnis und die Hand, die ausliefert:

• Ein Verifizierer, der sich nicht beschwatzen lässt. Der Richter ist kein zweites Modell mit einer Meinung; es ist eine Sammlung von Skripten, die den Build scheitern lassen. Existieren die Sprachsignale auf jeder öffentlichen Seite? Hat jeder Beitrag den Markdown-Zwilling, den ein KI-Leser braucht? Wird ein Bild referenziert, das niemand eingecheckt hat? Jede Prüfung existiert, weil genau dieser Fehler einmal ausgeliefert wurde, und jede antwortet mit einem Exit-Code statt mit einem Absatz.
• Ein Gedächtnis, das die Sitzung überlebt. Der Amnesie-Effekt ist real: fünfzehn Schleifen an einem hartnäckigen Bug, und der Agent verliert die Architektur aus den Augen. Hier ist das Gedächtnis kein Dienst, der offline sein kann — es sind Dateien neben dem Code, die mit dem Repository reisen: die Arbeitsanweisung, die Lektionen, die genau in dem Moment angehängt werden, in dem der Besitzer etwas korrigiert, die Liste der Antipatterns, die bestätigten Anwendungsfälle. Eine neue Sitzung beginnt damit, sie zu lesen, sodass die fünfzehnte Iteration weiß, was die erste gelernt hat.
• Ein Schlussakt, der nicht dem Agenten gehört. Der Loop endet im Kontrollzentrum: es baut das Projekt, führt ein Protokoll der Deployments und kann zum letzten funktionierenden Build zurückkehren. Einstellungen, Texte und Bilder ändern sich dort ganz ohne Neubau — sodass der Loop nie gebeten wird, etwas zu lösen, das nie ein Code-Problem war.

Beachte, was nicht auf dieser Liste steht: ein Schwarm von Modellen, die sich gegenseitig überwachen. Das war unsere erste Architektur, und wir haben sie entfernt. Orchestrierung ist der aufregendste Teil eines agentischen Diagramms und der am wenigsten tragende Teil eines funktionierenden — ein schwacher Richter wird nicht durch eine zweite Meinung repariert, und ein starker braucht selten eine.

Die neue Stellenbeschreibung des Software-Ingenieurs

Wir bewegen uns weg vom Code schreiben, vorbei am Prompt schreiben, und direkt hinein in das Bauen kognitiver Pipelines. Das Handwerk ist nicht mehr die Anweisung — es ist das System, in dem die Anweisung läuft.

Und es ist nicht umsonst. Zwei neue Kosten kommen mit den Loops. Verständnisschulden: wenn ein Agent eine Datei dreihundert Mal hinter den Kulissen schreibt und umschreibt, erodiert dein Verständnis deiner eigenen Codebasis leise — sie funktioniert, du bist dir nur nicht mehr sicher, warum. Und rohe Rechenleistung: ein Loop kann echtes Geld in Tokens verbrennen, während er einem einzigen Bug über hundert stille Versuche hinweg hinterherjagt. Die Ingenieure, die diese Ära gewinnen, behandeln Kosten-gegen-Qualität als bewusste Designentscheidung, nicht als Überraschung auf der Rechnung.

Die Ära des Prompt Engineering liegt offiziell hinter uns. Die einzige verbleibende Frage ist die, die Cherny sich selbst schon beantwortet hat: versuchst du noch, mit deiner KI zu sprechen — oder baust du bereits die Loops, die sie laufen lassen?

Quelle: ein weit verbreiteter LinkedIn-Beitrag von Guillermo Flor, der Boris Chernys Bemerkungen ans Licht brachte. Das Zitat wird so wiedergegeben, wie es kursierte; die Architektur und die Analyse sind unsere eigenen.