Loop Engineering: die neue Coding-Disziplin 2026

Loop Engineering ersetzt Expertise nicht — es skaliert sie. Oder ihre Abwesenheit ebenso. Wer den Loop baut, entscheidet, ob KI Urteilskraft multipliziert oder ihre Lücke. Das gilt in der Coding-Welt genauso wie in jeder mittelständischen KI-Anwendung, die 2026 seriös gedacht wird.

Was Loop Engineering ist

Addy Osmani, Senior Engineer im Google-Chrome-Team, hat am 7. Juni 2026 in seinem Blog die bis heute meistzitierte Definition aufgeschrieben:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of as a recursive goal where you define a purpose and the AI iterates until complete.

Die Verschiebung wirkt klein und ist doch fundamental. Die Praktikerin ist nicht mehr im Loop, sie baut ihn. Statt einen Coding-Agenten mit einzelnen Anweisungen zu bedienen, entsteht ein kleines System: es findet Arbeit, verteilt sie, prüft die Ergebnisse, schreibt Fortschritt außerhalb des Modells fest und entscheidet, was als Nächstes zu tun ist. Es läuft nach einem Zeitplan, mit klarer Abbruchbedingung oder ununterbrochen.

Boris Cherny, der Kopf hinter Claude Code bei Anthropic, hat das gleiche Prinzip einige Tage vor Osmani öffentlich formuliert. Sein Satz ist zum Meme der KI-Coding-Szene geworden:

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Wer die Fabrikhalle baut, steht nicht mehr am Fließband. Wer den Loop baut, muss über Verifikation, Ausfallsicherheit, Token-Kosten und Governance nachdenken. Das ist ein anderer Job als Prompt-Engineering.

Die Entstehungswoche im Juni 2026

Bemerkenswert an Loop Engineering ist nicht nur der Inhalt, sondern das Tempo der Begriffsbildung. Drei erfahrene Praktiker haben fast gleichzeitig auf dieselbe Verschiebung gezeigt und ihr einen Namen gegeben.

• Anfang Juni 2026 — Peter Steinberger (OpenClaw) postet: „You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.“
• Anfang Juni 2026 — Boris Cherny (Anthropic) echot: „I don't prompt Claude anymore. I write loops.“
• 7. Juni 2026 — Addy Osmani (Google Chrome) schreibt „Loop Engineering“ in seinem Blog auf.
• 10. Juni 2026 — Der erste vertiefende Kilo.ai-Artikel erscheint. Cobus Greyling publiziert auf Substack.
• 15. Juni 2026 — HuaShu veröffentlicht das „Loop Engineering Orange Book“ unter MIT-Lizenz.
• 22. Juni 2026 — Osmanis Original erscheint als Nachdruck auf O'Reilly Radar.

Der Begriff ist damit rund vier Wochen alt und im Wesentlichen Praktiker-Literatur. Peer-reviewte Publikationen gibt es noch nicht. Was es gibt: die operative Bestätigung durch die führenden Coding-Agent-Teams bei Anthropic, OpenAI und Google.

Vier Schichten: Prompt, Context, Harness, Loop

Loop Engineering ersetzt nicht die vorherigen Konzepte, sondern setzt sich als vierte Schicht darüber. Jede Schicht umschließt die innere.

• Prompt Engineering — die einzelne Instruktion. Hauptfrage: Wie forme ich die Anfrage?
• Context Engineering — was das Modell sieht. Hauptfrage: Was gehört ins Kontextfenster?
• Harness Engineering — die Umgebung des Agenten. Hauptfrage: Wie rüste ich den Agenten aus?
• Loop Engineering — der antreibende Zyklus. Hauptfrage: Wie iteriert der Agent autonom?

Context Engineering wurde Mitte 2025 durch Andrej Karpathy popularisiert und meint die Kunst, das Kontextfenster mit der richtigen Information zu füllen. Harness Engineering beschreibt die Werkzeuge, Isolations-Umgebungen und Skills, mit denen der Agent operiert. Loop Engineering sitzt eine Etage darüber, wie Osmani es formuliert: „Loop engineering sits one floor above the harness. The harness runs on a timer, it spawns little helpers, and it feeds itself.“

Die fünf Züge eines Loops

Ein Durchlauf besteht aus fünf Zügen. Fehlt einer davon, ist es kein Loop, sondern ein einmaliges Skript.

Zug 1 · Discovery (Entdeckung)

Der Loop beginnt nicht mit einer manuellen Anfrage. Er entdeckt Arbeit von selbst: liest täglich CI-Failures, scannt neue Issues, findet gestrandete Pull Requests, aggregiert Slack-Feedback. Ohne Discovery ist ein Loop nur ein wiederkehrendes Cronjob-Skript.

Zug 2 · Handoff (Übergabe)

Die gefundene Arbeit wird an Agenten übergeben. Isolierte Arbeitsumgebungen werden geöffnet, Kontext und Werkzeuge zugeschnitten. Bei parallelen Agenten muss sichergestellt sein, dass sie sich nicht in die Quere kommen.

Zug 3 · Verification (Verifizierung)

Der kritischste Zug. Der Agent liefert, der Loop prüft: Tests, Type Checks, Linter, Screenshots für UI-Arbeit, Review-Kommentare. Verifikation ist deterministisch, wo möglich. Ein Pass/Fail vom Compiler kann ein Agent nicht wegdiskutieren. Osmanis Merksatz: „done is a claim, not a proof.“

Zug 4 · Persistence (Persistenz)

Der Loop schreibt Fortschritt außerhalb des Modells auf. Markdown-Datei, Board, Datenbank. Der Agent vergisst zwischen den Runs, das Repository nicht. Ohne Persistence wird jeder Loop zum Amnesie-System, das bei jedem Neustart bei null anfängt.

Zug 5 · Scheduling (Planung)

Der Loop entscheidet selbst, wann er wieder läuft und wann er aufhört. Das schließt die Abbruchbedingung ein. Nicht „stop, wenn ich meine, dass es fertig ist“, sondern „stop, wenn alle Tests in test/auth grün sind und lint clean ist“.

Das Maker-Checker-Prinzip

Wer sich schon mit KI-Modellen beschäftigt hat, kennt das Problem: Ein Sprachmodell, das seinen eigenen Output bewertet, neigt dazu, ihn zu loben. Eine vielzitierte Studie aus dem Jahr 2024 belegt, dass LLMs bei Zusammenfassungs-Aufgaben ihre eigenen Outputs deutlich überproportional gegenüber denen anderer Modelle und von Menschen bevorzugen. Das Phänomen heißt Self-Preference Bias.

Für Loop Engineering ist das kein akademisches Detail, sondern der Ausgangspunkt der wichtigsten Design-Regel: Generator und Evaluator müssen getrennt sein.

• Generator-Agent (Maker): produziert Output, schreibt Code, schlägt Lösungen vor.
• Evaluator-Agent (Checker): unabhängiger Agent mit anderen Instruktionen, idealerweise anderem Modell, ohne Kenntnis des Entstehungsprozesses. Prüft nur das Ergebnis gegen Spec und Tests.

Osmani nennt dies das nützlichste strukturelle Element in einem Loop: „Der Agent, der Code schrieb, ist zu nett zu seinen eigenen Hausaufgaben.“ Der Slash-Befehl `/goal` in Claude Code implementiert genau diese Trennung. Ein separates, frisches Modell entscheidet nach jedem Turn, ob der Loop fertig ist.

Ergänzend zeigt Forschung von Label Studio, dass ein fähiges Modell als Judge rund 80 Prozent Übereinstimmung mit menschlichen Ratern erreicht — bei etwa 500-fach geringeren Kosten. Genau dieses Verhältnis verwandelt Evaluierung von einem gelegentlichen Ereignis in ein kontinuierliches Qualitätsgate.

Praxis-Belege: Stripe und Anthropic

Die neue Praxis ist nicht Theorie. Zwei Datenpunkte machen die Skala greifbar.

Stripe Minions ist die bekannteste Enterprise-Loop-Pipeline. Stripe merged rund 1.300 maschinengeschriebene Pull Requests pro Woche, ohne dass ein Mensch den Code selbst geschrieben hat. Ein Ingenieur schickt eine Slack-Nachricht, ein Minion spinnt in etwa 10 Sekunden eine isolierte Cloud-Instanz auf, liest Jira-Tickets, durchsucht die Codebase, schreibt Code, führt Linter aus, besteht CI, öffnet einen fertigen Pull Request. Ingenieure reviewen, sie schreiben nicht. Das entspricht rund 10 Prozent aller Stripe-PRs. Der Code läuft auf Infrastruktur, die jährlich mehr als eine Billion US-Dollar an Zahlungsvolumen abwickelt.

Boris Cherny bei Anthropic ist der personifizierte Loop. Er betreibt täglich fünf lokale Claude-Code-Instanzen plus fünf bis zehn in der Cloud, alle parallel. Er liefert 20 bis 30 Pull Requests täglich. In einer gemessenen Woche waren es 150 PRs, alle von Claude produziert. Anthropic berichtet einen achtfachen Anstieg an Code pro Engineer seit Jahresbeginn 2026. CEO Dario Amodei nennt etwa 90 Prozent von Claudes eigenem Produktcode als KI-geschrieben.

Das ist eine andere Größenordnung als „ChatGPT hilft mir beim Coden“. Und es ist keine Zukunftsmusik, es ist Betriebsalltag.

Die stillen Kosten und Governance-Fragen

Loops haben vier Kostenarten, die genau dann entstehen, wenn sie gut laufen — nicht wenn sie scheitern. Wer sie ignoriert, zahlt sie später mit Zinsen.

Verification Debt · Verifikationsschuld

Ein Loop, der unbeaufsichtigt läuft, produziert auch Fehler unbeaufsichtigt. Wenn Verifikation schwach definiert ist, häufen sich vermeintlich gelöste Issues an, die in Produktion wiederkommen. „Done“ ist immer eine Behauptung, kein Beweis.

Comprehension Rot · Verständnisfäule

Je schneller ein Loop Code ausliefert, den niemand selbst geschrieben hat, desto größer die Lücke zwischen Ausgeliefertem und Verstandenem. Blake Crosley nennt es cognitive debt. Die Rechnung kommt spätestens beim ersten kritischen Bug in Produktion.

Cognitive Surrender · kognitive Kapitulation

Die komfortabelste Haltung ist die gefährlichste. Osmani: „Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking; same action, opposite result.“ Dasselbe Handeln kann Produktivität multiplizieren oder Expertiseverlust beschleunigen. Die Haltung entscheidet.

Token Blowout · Kostenexplosion

Loops verbrennen Token in anderem Maßstab als manuelle Nutzung. Ein feststeckender Agent, der alle 10 Sekunden loopt, kann 20 bis 50 US-Dollar pro Stunde verbrennen. Skaliert auf 500 parallele Agenten sind das potenziell 25.000 US-Dollar in einer Nacht. Iterations-Caps, Token-Budgets und Hard-Stops bei definiertem Limit sind Pflicht, nicht Kür.

Autonomie-Stufen als Design-Entscheidung

Loop Engineering ist keine binäre Sache. Wie viel Autonomie ein Loop bekommt, ist eine Design-Entscheidung entlang von fünf Stufen:

• L0 · Suggest — Modell schlägt vor, Mensch tut alles.
• L1 · Act-with-Approval — Modell schlägt Aktion vor, Mensch genehmigt.
• L2 · Act-and-Escalate — autonom bei Routine, eskaliert bei High-Risk.
• L3 · Supervised Autonomy — läuft unbeaufsichtigt, Mensch reviewt Ergebnis.
• L4 · Full Autonomy — kein Mensch im Ausführungspfad.

Loops liegen typischerweise auf L2 oder L3. Vollständig unbeaufsichtigte Loops (L4) sind nur bei reversiblen, gut verstandenen Aufgaben mit zuverlässiger Verifikation vertretbar. Die wichtigere Design-Regel: Autonomie ist eine Per-Aktion-Entscheidung, nicht eine Per-Produkt-Entscheidung. Ein Agent darf autonom Type-Fehler fixen, aber nicht autonom eine Datenbank-Migration ausführen. Die Empfehlung aus der Praxis: baue den Agenten zuerst auf L1, beobachte einige hundert echte Durchläufe, promoviere erst dann die spezifischen Aktionen, die sich als sicher und langweilig routinemäßig erwiesen haben.

Was das für den Mittelstand bedeutet

Loop Engineering entsteht in der Coding-Agent-Welt. Der DACH-Mittelstand baut selten eigene KI-Coding-Pipelines. Trotzdem ist die Disziplin relevant, weil sie die Governance-Bausteine liefert, die für jede ernste KI-Anwendung ab 2026 zum Standard werden.

Drei sofort nutzbare Prinzipien

Erstens: Maker-Checker als Grundregel für jede KI-Ausgabe. Wenn Sie KI-Ergebnisse in Ihrem Unternehmen einsetzen — sei es für Angebotserstellung, Bonitäts-Prüfungen oder Content — sollte die Prüfung nie durch dasselbe Modell erfolgen, das produziert hat. Ein zweites Modell, oder mindestens ein Mensch mit anderer Perspektive, gehört zwischen Produktion und Freigabe.

Zweitens: Explizite Abbruchbedingungen statt „gut genug“. Jeder KI-Prozess in Ihrem Unternehmen sollte ein klares Stopp-Kriterium haben. Nicht „Der Assistent macht das so lange, bis es passt“, sondern „Der Assistent macht das, bis Kriterium X erfüllt ist, dann eskaliert er.“ Ohne Abbruchbedingung driften KI-Prozesse langsam aus dem eigentlichen Ziel.

Drittens: Autonomie in kleinen Schritten verdienen. Beginnen Sie jede KI-Anwendung auf Stufe L1. Beobachten Sie mindestens 100 echte Durchläufe. Erst dann erhöhen Sie die Autonomie für spezifische Aktionen, die sich als sicher erwiesen haben. Nicht das ganze Werkzeug wird autonom, sondern einzelne Handgriffe.

Zwei offene Governance-Fragen

Verantwortung für Code, den niemand geschrieben hat. Wer haftet, wenn ein unbeaufsichtigter Loop einen Bug in Produktion schiebt? Die Frage ist im DACH-Raum juristisch nicht geklärt. Wir empfehlen: eine Verantwortungs-Matrix pro KI-Werkzeug, in der geregelt ist, wer entscheidet, wer prüft, wer eskaliert. Analog zur RACI-Logik im klassischen Projektgeschäft. Wer nach EU AI Act Artikel 4 KI-Kompetenz nachweisen muss, kommt an dieser Matrix ohnehin nicht vorbei.

Token-Kosten als Gerechtigkeitsproblem. Loops skalieren nur für Organisationen mit ausreichendem API-Budget. Kleine Betriebe können mit den Effizienz-Sprüngen der großen nicht mithalten, wenn sie sich keine 500 parallelen Agenten leisten können. Das ist eine Frage, die wir in KI-Reifegrad-Workshops zunehmend hören, ohne dass es eine gute Antwort gibt.

Hype oder Substanz?

Der Begriff ist jung, gerade einen Monat alt, und stark durch eine kleine Gruppe hochkarätiger Ingenieure geprägt. Peer-reviewte Studien fehlen. Der Kontext ist bisher fast ausschließlich Coding. Was substanziell bleibt: Die Kernideen — selbstlaufende Feedback-Zyklen, Maker-Checker-Trennung, externe Persistenz, explizite Abbruchbedingungen und Autonomie-Stufen — sind solide gebaut und werden von den führenden Coding-Agent-Teams unabhängig voneinander implementiert. Das ist das Muster einer entstehenden Praxis, nicht das eines Marketing-Buzzworts.

Two people can build the exact same loop and get completely opposite results. — Addy Osmani

Wer den Loop baut, entscheidet. Das ist keine Coding-Frage, das ist eine Führungs-Frage.