Loop Engineering mit Claude: KI-Schleifen bauen, die sich selbst steuern

Was Loop Engineering ist

Loop Engineering heißt, sich selbst als die Person zu ersetzen, die den Agenten anweist, und stattdessen das System zu bauen, das es tut. Man füttert den Agenten nicht mehr Zeile für Zeile, man entwirft die Maschine, die ihn füttert. Damit steht man nicht mehr in der Schleife, sondern außerhalb und baut sie. Das Gewicht des Satzes liegt auf dem Ersetzen seiner selbst.

Der Begriff kam im Juni 2026 fast gleichzeitig von drei Praktikern. Peter Steinberger, Autor von OpenClaw, postete, man solle Coding-Agenten nicht mehr prompten, sondern die Schleifen entwerfen, die sie prompten, der Beitrag erreichte über acht Millionen Aufrufe. Boris Cherny, Lead von Claude Code bei Anthropic, sagte zur selben Zeit, er prompte Claude nicht mehr, sondern habe Schleifen laufen, die Claude prompten. Am 7. Juni 2026 schrieb Addy Osmani vom Google-Chrome-Team es unter dem Titel Loop Engineering auf und gab der Praxis ihren Namen.

Warum gerade jetzt? Drei Werkzeuge hatten leise eine Schwelle überschritten. Coding-Agenten wurden zuverlässig genug, eine nicht-triviale Aufgabe unbeaufsichtigt zu beenden. Scheduling-Primitive kamen in die großen Harnesses. Und ein einzelner Agentenlauf wurde billig genug, ihn wiederholt auf einem Timer laufen zu lassen, ohne dass es verschwenderisch wirkt. Die Praxis kam vor dem Namen, so wie Teams Schreiber- und Reviewer-Agenten paarten, lange bevor das Generator-Evaluator-Muster einen Namen hatte.

Eine Etage über dem Harness

Loop Engineering ersetzt die frühen Schichten nicht, es stapelt sich darauf. Jede Schicht kümmert sich um etwas Größeres: ein Satz beim Prompt, ein Fenster beim Kontext, ein Lauf beim Harness und schliesslich eine Schleife, die sich selbst dreht. Wer das Harness Engineering kennt, erkennt Loop Engineering als die nächste Etage darüber.

Drei Verben trennen den Harness von der Schleife. Sie läuft auf einem Timer und wacht nach Zeitplan auf, ohne Knopfdruck. Sie spaltet Helfer ab, ein Sub-Agent schreibt, ein anderer tut nichts als prüfen. Und sie füttert sich selbst: Was die Schleife produziert, wird zur eigenen Eingabe der nächsten Runde, das Gedächtnis liegt in einer Datei, nicht im Kontextfenster. Genau dieses Gedächtnis über Konversationen hinweg macht aus einem oft wiederholten Lauf eine echte Schleife.

Die fünf Bewegungen einer Schleife

Das Wort Schleife verleitet zum Bild des Leerlaufs. Jede Runde tut etwas Konkretes: Sie findet Arbeit, übergibt sie, prüft das Ergebnis, sichert den Stand und entscheidet den nächsten Schritt. Fällt eine der fünf Bewegungen weg, dreht die Schleife durch oder steht still.

Die sechs Bausteine in Claude Code

Wenn die Bewegungen beschreiben, was passiert, beschreiben die Bausteine, was dafür vorhanden sein muss. In Claude Code haben sie konkrete Namen, und die Befehle gibt es auch in Codex unter anderen Bezeichnungen.

Mit allen sechs hat eine Schleife ein Skelett: Die Automation bringt sie in Bewegung, Worktrees halten sie davon ab, sich selbst zu behindern, Skills bewahren sie vor doppelter Arbeit, Connectors lassen sie nach aussen sehen, Sub-Agenten lassen sie sich selbst korrigieren, und Memory lässt sie sich erinnern. Wer tiefer in einzelne Bausteine einsteigen will, findet das bei Skills und bei parallelen Agentenschwärmen .

Generator und Evaluator: der Teil, der Nein sagt

Der schwierigste Teil einer Schleife ist nicht, den Agenten zum Laufen zu bringen, sondern etwas einzubauen, das Nein sagen kann, und der Agent, der den Code schreibt, ist der, der es am wenigsten tut. Fragt man einen Agenten, seine eigene Arbeit zu bewerten, lobt er sie meist selbstbewusst, auch wenn ein Mensch die mittelmäßige Qualität klar sieht.

Das ist kein Intelligenzproblem, es ist das Benoten der eigenen Hausaufgabe. Der Kontext, in dem der Code geschrieben wurde, ist schon voll mit den Gründen, warum er so geschrieben wurde. Wenn der Agent seine Ausgabe ansieht, sieht er nicht das Ergebnis, sondern die Kette der Selbstüberzeugung, die dorthin führte. In einer Schleife verstärkt sich der Fehler: Wenn jede Runde der Agent selbst entscheidet, ob etwas gut genug ist, nickt er sich jede Runde zu und driftet weiter von echter Qualität ab.

Der Anthropic-Ingenieur Prithvi Rajasekaran beschreibt drei Schritte, die den Prüfer scharf machen. Erstens den Generator vom Bewerter strukturell trennen, ein zweiter Agent mit völlig anderen Anweisungen, der den Code von Grund auf ansieht. Die Idee stammt aus den Generative Adversarial Networks, einer baut, einer sucht Fehler. Zweitens den Evaluator handeln lassen statt nur lesen: Rajasekaran hängte ihn an Playwright MCP, damit er die Seite öffnet, Buttons klickt, Screenshots macht und das DOM prüft wie ein QA-Ingenieur. Aus der Code sieht richtig aus wird so ich habe geklickt, hier ist der Screenshot. Drittens das Modell mitwechseln, denn dasselbe Modell mit neuen Anweisungen behält oft seine blinden Flecken.

Claude Code macht das zum Primitiv. /goal nimmt eine Bedingung und läuft, bis sie erfüllt ist. Nach jeder Runde prüft ein frisches, kleines Modell, ob die Bedingung hält, statt die Kontrolle zurückzugeben. Die Vollendung entscheidet ein frisches Modell, nicht das, das die Arbeit gemacht hat. Das ist das Maker-Checker-Prinzip aus dem Bankwesen, wo die Person, die eine große Überweisung eingibt, und die, die sie prüft, verschieden sein müssen. Eine gängige Kalibrierung sagt dem Evaluator, den Code als kaputt anzunehmen, bis das Gegenteil bewiesen ist. Default ist Zweifel, nicht Vertrauen.

Loop Engineering mit Claude im Detail

Die Theorie wird konkret, sobald man die Befehle sieht. Die folgenden Beispiele zeigen pro Baustein eine schlechte und eine gute Umsetzung in Claude Code. Die schlechte Variante läuft fast immer auch, sie fällt nur später auf, und das ist genau das Tückische an der Schleifen-Ebene.

Discovery: eine Skill statt einer Wand aus Anweisungen

Discovery gehört in eine Skill, die man wiederverwenden und pflegen kann, nicht in einen Cron-Job mit hineinkopiertem Prompt. Die Prompt-Wand verrottet in einem Zeitplan, den niemand mehr anfasst, die Skill bleibt benannt, versioniert und testbar. Sie löst die wiederkehrende Intent Debt ab, also die Kosten, jedem Lauf neu zu erklären, was das Projekt ist und wo die Fallen liegen.

# Schlecht: ein langer Prompt direkt im Cron-Job
0 6 * * *  claude -p "Schau dir die CI an, finde
Fehler, prüfe offene Issues, entscheide was wichtig
ist, baue Fixes, und denk an die Tests ..."   # verrottet

Die gute Variante ist eine Triage-Skill mit klar getrennten Abschnitten. Fünf davon bilden die fuenf Bewegungen ab, der sechste, Stop, ist die Grenze, die du selbst hineinschreibst:

# .claude/skills/morning-triage/SKILL.md
---
name: morning-triage
trigger: täglich von der Automation aufgerufen
---

## Lesen (die DISCOVERY-Eingaben)
- CI-Läufe, die seit dem letzten Lauf gescheitert sind
- Issues der letzten 24 Stunden
- Commits seit gestern
- die vorige ./state/triage.md

## Urteilen (setzt die Qualitätsgrenze)
Für jeden Kandidaten entscheiden:
- jetzt handlungswürdig oder nur Rauschen?
- blockiert ein Release? -> Priorität
- schon getrackt? -> überspringen

## Schreiben (die PERSISTENCE-Ausgabe)
An ./state/triage.md anhängen, eine Zeile pro Fund:
| finding | quelle | priorität | status |

## Stop (die Grenze, die du behältst)
Nie mergen, nie löschen. Unsicheres geht nach
./inbox/ für einen Menschen, nicht in einen PR.

Der Stop-Abschnitt ist kein Beiwerk. Er ist die eine Stelle, an der du festschreibst, was die Schleife nicht von selbst weiss. Lässt du ihn weg, merged sie mit einem Selbstvertrauen, das sie nicht verdient hat.

Verification: ein eigener Evaluator statt Selbstbewertung

Der Generator darf nicht sein eigener Prüfer sein. Der schlechte Weg lässt denselben Agenten, der den Code geschrieben hat, am Ende fragen, ob er gut ist, und die Antwort ist fast immer ja. Der gute Weg ist ein separater Agent mit eigenen Anweisungen, einem anderen Modell und der Grundhaltung, der Code sei kaputt, bis das Gegenteil bewiesen ist.

# Schlecht: derselbe Agent benotet seine Hausaufgabe
claude "baue das Login und sag mir, ob es gut ist"
# -> nickt sich zu, jede Runde, im Maschinentempo

Gut ist ein dedizierter, skeptischer Reviewer-Agent, der handelt statt nur zu lesen:

# Evaluator-Agent (.claude/agents/reviewer.md)
ROLE: Adversarialer Code-Reviewer.
ASSUME: dieser Code ist KAPUTT, bis das Gegenteil
        bewiesen ist. Nicht loben, finde was scheitert.

PRUEFE der Reihe nach:
1. Läuft er überhaupt? (ausführen, nicht lesen)
2. Tests laufen lassen, echte Ausgabe einfügen.
3. Randfälle, die der Autor übersprungen hat.
4. Passt das Verhalten zum Ticket?

NUTZE Playwright MCP: Seite öffnen, klicken,
Screenshot machen, DOM prüfen. Urteile ueber
Verhalten, nicht ueber Absicht.

VERDICT: PASS nur wenn jede Prüfung hält.
Sonst REJECT und jeden Grund einzeln auflisten.

Die Stop-Bedingung übergibt man an /goal. Nach jeder Runde prüft ein frisches, kleines Modell, ob sie hält, nicht der Agent, der die Arbeit gemacht hat:

# Stop-Bedingung, von einem frischen Modell geprüft
/goal alle Tests in test/auth bestehen und der
      Lint-Schritt ist sauber

Handoff: ein Worktree pro Aufgabe statt ein gemeinsames Verzeichnis

Mehrere Agenten im selben Verzeichnis ist dasselbe Problem wie zwei Entwickler, die gleichzeitig auf dieselben Zeilen committen. Das Fehlerbild zeigt sich erst unter Parallelität: Ein einzelner Agent läuft sauber, und am ersten Morgen, an dem fuenf gleichzeitig laufen, wird der Merge zum Chaos. Ein isolierter Worktree pro Aufgabe macht aus läuft, aber chaotisch ein läuft und sauber.

# Schlecht: alle Agenten im selben Verzeichnis
claude "fix auth bug"      # Terminal 1
claude "fix null deref"    # Terminal 2  -> Kollision

# Gut: ein isolierter Worktree pro Fund
claude --worktree fix/auth-test  "entwirf den Fix"
claude --worktree fix/null-deref "entwirf den Fix"

Scheduling: lokal anstoßen oder in der Cloud

Lokal heißt kurze Intervalle und Zugriff auf lokale Dateien, aber die Maschine muss anbleiben. Cloud heißt echte Autonomie, dafür ein gröberes Intervall und ein frischer Klon pro Lauf. Eine reife Schleife nutzt beides, lokal für die engen inneren Prüfungen, Cloud für den nächtlichen Durchlauf.

# Lokal: wiederholt, solange die Maschine läuft
/loop 5m prüfe das Deployment  # fest: alle 5 Minuten
/loop prüfe das Deployment     # der Agent taktet sich selbst

# Cloud: läuft auch mit ausgeschalteter Maschine
# .github/workflows/triage.yml
on:
  schedule:
    - cron: '0 6 * * *'         # 06:00 täglich
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - run: claude --skill morning-triage

Eine vollständige erste Schleife, kommentiert

Klein genug, um sie in einem Zug zu lesen, und doch mit allen sechs Bausteinen. Die sechs nummerierten Kommentare sind die sechs Bausteine, jeder in zwei bis drei Zeilen:

# 1. SCHEDULING -- ein echter Trigger
on:
  schedule:
    - cron: '0 6 * * *'        # 06:00 täglich, Cloud

# 2. DISCOVERY -- eine Skill, keine Textwand
run: claude --skill morning-triage

# 3. PERSISTENCE -- Zustand auf der Platte
#    die Skill schreibt ./state/triage.md
#    und committet sie zurück ins Repo

# 4. HANDOFF -- ein Worktree pro Fund
for finding in $(parse ./state/triage.md); do
  claude --worktree "fix/$finding" \
    --goal "Tests bestehen und Lint ist sauber" \
    "entwirf einen Fix für $finding"
done

# 5. VERIFICATION -- ein frisches Modell urteilt
#    /goal prüft nach jeder Runde, ein reviewer.md
#    sucht zusätzlich nach Fehlern

# 6. HUMAN REVIEW -- die offene Tür
#    PRs werden geöffnet, nie automatisch gemergt,
#    Unsicheres landet in ./inbox/

Eine Schleife mit allen sechs ist eine echte Schleife, auch wenn sie winzig ist. Fehlt einer, ist es eines der fuenf Fehlerbilder in Verkleidung. Die sichere Reihenfolge beim Wachsen: erst beweisen, dass der Evaluator echte Fehler fängt, dann die Parallelität erhöhen, nicht umgekehrt.

Zwei Schleifen aus der Praxis

Drei öffentliche Fälle unterscheiden sich stark in der Skala, teilen aber ein Skelett: Ein Auslöser drückt Start, Leitplanken halten die Schleife auf Kurs, am Ende sitzt ein menschlicher Prüfpunkt. Dass etwas läuft, während man schläft, hing nie an der Stärke des Modells, sondern an der Solidität dieses Skeletts.

Osmanis Morning-Triage-Loop

Osmani baute sich eine morgendliche Triage-Schleife. Morgens startet eine Automation von selbst. Eine Triage-Skill liest die gestern gescheiterten CI-Tests, die offenen Issues und die neuen Commits und schreibt ihre Funde in eine Markdown-Datei oder ein Linear-Board. Für jeden handlungswürdigen Fund öffnet sie einen isolierten Worktree, ein Sub-Agent entwirft den Fix, ein zweiter prüft ihn gegen die Skills und Tests des Projekts. Ein Connector öffnet den Pull Request und aktualisiert das Ticket. Was sie nicht erledigen kann, landet in einer Inbox für den Menschen, und eine Status-Datei überlebt, damit der nächste Tag dort weitermacht, wo dieser aufgehört hat.

Stripes Minions: 1.300 Pull Requests pro Woche

Für die Enterprise-Skala ist Stripes Minions der Fall zum Studieren: über 1.300 gemergte Pull Requests pro Woche, keine Zeile von Hand geschrieben, beschrieben vom Stripe-Ingenieur Steve Kaliski im How-I-AI-Podcast. Der Auslöser ist leicht, ein @-Ruf an den Bot in Slack oder eine Emoji-Reaktion. Zuverlässig wird das durch die Strecke, bevor das Modell aufwacht: Ein deterministischer Orchestrator sammelt zuerst den Kontext, scannt Links, zieht Jira, findet Docs und nutzt Sourcegraph plus MCP, um relevanten Code zu finden. Was deterministische Logik lösen kann, geht nie an ein probabilistisches Modell.

Der entscheidende Punkt: Minions läuft nicht auf einem stärkeren Modell, sondern ist ein Fork des Open-Source-Werkzeugs Goose. Die Zuverlässigkeit kommt aus der Qualität der Leitplanken, nicht aus der Größe des Modells. Die 1.300 PRs werden weiter von Menschen geprüft. Der Mensch ist nicht gegangen, er hat den Schreibtisch gewechselt, vom Schreiben zum Prüfen.

Lokal oder Cloud: wovon läuft während du schläfst abhängt

Die Wahl zwischen lokalem und Cloud-Scheduling folgt aus einer Frage: Ist die Arbeit der Schleife an die lokale Maschine geklebt oder kann sie weg? Eine Schleife, die jede Minute einen lokalen Entwicklungsserver prüft, kann nur lokal laufen. Eine Schleife, die um drei Uhr nachts offene Issues scannt, sollte nie an einem Laptop hängen, dessen Deckel zugeklappt wird.

Die Verzerrung, die man vermeiden sollte, ist, lokalen Rerun für das Ganze von während du schläfst zu halten. Lokaler Rerun heißt, ein paar Extra-Runden zu fahren, solange man da ist. Cloud-Scheduling heißt, zu laufen, auch wenn man nicht da ist. Eine reife Schleife nutzt oft beides: lokal für die engen inneren Prüfungen, Cloud für den nächtlichen Durchlauf. Die Cloud Routines und die dynamischen Workflows sind bei innobu bereits eigen beschrieben.

Vier stille Kosten

Eine Schleife, die sich selbst steuert, ist zugleich eine, die selbst Fehler macht. Je fröhlicher sie läuft, desto leiser irrt sie. Vier Kosten laufen auf, keine schlägt während des Laufs Alarm, und sie verstärken sich gegenseitig.

Verifikationsschuld. Jeder gemergte PR spart Zeit, die sich in ungeprüfte Ausgabe verwandelt, die wieder fällig wird. Das Problem versteckt sich dort, wo Tests nicht hinreichen, in der Lücke zwischen läuft und richtig, und häuft sich bis zu einem Liefermorgen, an dem es auf einmal hochgeht. Der Schutz ist ein unabhängiger Evaluator.

Verständnis-Verfall. Je schneller die Schleife Code liefert, den man nicht geschrieben hat, desto größer die Lücke zwischen dem, was existiert, und dem, was man versteht. Code lesen ist langweiliger als Code schreiben, und die Schleife hat das Schreiben übernommen. Der Schutz ist, regelmäßig eine Stichprobe zu lesen und sich zu zwingen, ein paar Änderungen zu erklären.

Kognitive Kapitulation. Wenn die Schleife sich selbst steuert, ist es verlockend, keine Meinung mehr zu haben und einfach zu nehmen, was sie liefert. Je zuverlässiger die Schleife, desto leichter gibt man das Urteil ab. Der Schutz ist eine Zeile: Die Schleife darf ausführen, aber nicht entscheiden.

Token-Explosion. Die einzige Kosten, die direkt auf die Rechnung schlägt und schwer vorab zu schätzen ist. Die Schleife brütet Helfer aus, wiederholt und läuft Runde um Runde, ein Bug kann eine ganze Nacht leerlaufen. Anthropics eigene Experimente zeigen die Spanne: Ein voller Harness-Lauf für eine DAW-App kostete rund 124,70 US-Dollar bei knapp vier Stunden Laufzeit, ein einfacher Retro-Game-Maker lag bei 9 US-Dollar in 20 Minuten gegenüber 200 US-Dollar in sechs Stunden mit vollem Rahmenwerk. Der Schutz sind harte Obergrenzen vor dem Start: Pro-Lauf-Budget, Tagesbudget, maximale Wiederholungen.

Deutsche und europäische Perspektive

Das Maker-Checker-Prinzip ist im deutschen Bankwesen seit Jahrzehnten Standard und überträgt sich direkt auf den Prüfpunkt einer Schleife. Wer eine große Überweisung eingibt, prüft sie nicht selbst. Genau diese Trennung baut der Evaluator in die Schleife ein, und für regulierte Branchen ist sie kein Nice-to-have.

• Der EU AI Act verlangt für Hochrisiko-Systeme wirksame menschliche Aufsicht. Ein offener Prüfpunkt in der Schleife, an dem PRs geöffnet, aber nie automatisch gemergt werden, ist damit nicht nur gute Praxis, sondern Anschluss an die Regulierung.
• DSGVO und Betriebsgeheimnisse: Cloud-Schleifen ziehen oft einen frischen Klon des Repos, Connectors greifen auf Tickets und Datenbanken zu. Datenflüsse und Zugriffsrechte gehören geklärt, bevor die erste Schleife unbeaufsichtigt läuft.
• Der deutsche Mittelstand profitiert besonders, weil eine gut gebaute Schleife knappe Entwicklerkapazität vervielfacht. Das gilt aber nur, wenn das Urteil im Haus bleibt und nicht mitautomatisiert wird.

Herausforderungen und Risiken

Die fünf typischen Fehlerbilder entsprechen je einer ausgelassenen Bewegung. Am häufigsten ist die nickende Schleife, in der derselbe Agent seine Arbeit selbst für gut erklärt und im Maschinentempo plausibel aussehende Fehler anhäuft.

Verbreitete Zahlen sind mit Vorsicht zu behandeln. Aussagen wie 90 Prozent von Claude Code schreibt sich selbst oder große Migrations-Geschwindigkeiten sind meist Sekundärzusammenfassungen und taugen nur als grobe Orientierung. Die drei Fälle in diesem Artikel gehen auf Erstquellen zurück, das hält besser als eine beeindruckend klingende Einzelzahl.

Was Unternehmen jetzt tun sollten

Stripes Pipeline ist der Endpunkt, nicht der Start. Die erste Schleife sollte so klein sein, dass sie kaum wie ein System aussieht, eine Kleinigkeit, die etwas auf einem Timer prüft, aber mit eingebautem Prüfpunkt und menschlicher Kontrolle.

1. Klein anfangen mit einem /loop

   Eine Aufgabe auf einem Intervall wiederholen lassen. Das ist noch keine Schleife, aber der Einstieg. Dann eine Triage-Skill ergänzen, die CI-Fehler, neue Issues und Commits liest und auflistet, was handlungswürdig ist.

2. Den Evaluator zuerst härten

   Ein starker Generator mit schwachem Prüfer produziert selbstbewussten Müll. Erst beweisen, dass der Evaluator echte Fehler fängt, dann die Parallelität erhöhen. Parallelität kommt zuletzt, nach den Prüfungen.

3. Obergrenzen vor dem ersten unbeaufsichtigten Lauf setzen

   Pro-Lauf-Budget, Tagesbudget und maximale Wiederholungen. Diese Zahlen sind Sicherungen, die ein offenes Risiko in ein begrenztes verwandeln, kein nachträgliches Sparen nach der ersten überraschenden Rechnung.

4. Eine Tür offen lassen

   Mindestens ein Prüfpunkt, an dem die Schleife auf einen Menschen wartet. PRs werden geöffnet, nie automatisch gemergt, Unsicheres landet in einer Inbox. Der menschliche Review-Punkt ist kein Gerüst, das man später entfernt, sondern das Merkmal, das die Schleife vertrauenswürdig hält.

5. Täglich eine Stichprobe lesen

   Nicht alles, was die Schleife produziert, sondern eine repräsentative Probe, und sich zwingen, jede Änderung zu erklären. Wer eine Änderung nicht erklären kann, dessen Landkarte ist veraltet. Das ist auf einem ruhigen Morgen billiger zu entdecken als in einem Produktionsvorfall.

Fazit

Dieselbe Schleife, von zwei Menschen gebaut, endet an entgegengesetzten Orten, und der Unterschied liegt nicht in der Schleife. Wer sie nutzt, um auf Bekanntem schneller zu werden, liest weiter den Code, hält eine feste Richtung und skaliert ein Urteil, das er schon hatte. Wer sie nutzt, um nie wieder verstehen zu müssen, wird sechs Monate später zum Torwächter einer Maschine, die er nicht lesen kann.

Die Schleife macht die Generierung extrem billig, Code, Pläne, PRs, Fixes, fast gratis. Knapp bleibt das Urteil: zu wissen, welcher Plan richtig ist, welche Zeile gestoppt gehört, welche Ausgabe sauber läuft und an der Wurzel doch falsch ist. Loop Engineering entwertet das Urteil nicht, es streift alles ab, was kein Urteil braucht, und lässt das Urteil als alles übrig, was bleibt. Bau die Schleife, aber bau sie wie jemand, der vorhat, Engineer zu bleiben, nicht nur der, der auf Start drückt.

Weiterführende Informationen