Loop Engineering: Warum die Macher von Claude Code keine Prompts mehr tippen

Boris Cherny hat Claude Code entwickelt. Peter Steinberger hat OpenClaw gebaut. Millionen Entwickler tippen täglich Befehle in ihre Werkzeuge, doch die Erfinder selbst haben mit der manuellen Eingabe aufgehört. Sie schreiben autonome Schleifen, die den Agenten kontinuierlich steuern, verifizieren und Korrekturen ausführen.

Key Takeaways (TL;DR)

• Entwickler als Flaschenhals: Die manuelle Befehlseingabe blockiert die Geschwindigkeit agentischer Werkzeuge.
• Drei Ebenen der Steuerung: Prompt Engineering formt Aufrufe, Context Engineering Läufe, Loop Engineering Systeme.
• Getrennte Verifikation: Der Agent, der den Code schreibt, darf sein eigenes Ergebnis niemals selbst freigeben.
• Zustand extern verankern: Ohne persistenten Speicher außerhalb des Modells droht Schleifen-Amnesie.

Basiert auf “The Creator of Claude Code Doesn’t Prompt It Anymore” von Saurabh Singh. Das Original findest du hier: https://towardsdev.com/the-creator-of-claude-code-doesnt-prompt-it-anymore-bf2ac2e404d3

Der Ablauf in der aktuellen Softwareentwicklung wirkt vertraut: Befehl tippen, dem Agenten bei der Arbeit zusehen, Diff prüfen, nächsten Befehl tippen. Wer diesen Prozess unvoreingenommen analysiert, erkennt das eigentliche Nadelöhr. Der KI-Agent ist unermüdlich. Der Mensch davor ist die verlangsamende äußere Schleife, die Aufrufe verteilt und Ergebnisse manuell abgleicht.

Saurabh Singh, Entwickler und Gründer von Vibe Engines, beschreibt diesen Schritt als den Übergang zur dritten Stufe der Arbeitsweise mit künstlicher Intelligenz.

Drei Stufen der KI-Interaktion

Prompt Engineering steuert eine einzelne Modellantwort über Wortwahl und Ausgabeformate. Context Engineering bereitet den gesamten Kontext für einen Arbeitsgang vor, inklusive Dateien, Anweisungen und Werkzeugen. Loop Engineering baut das automatisierte System um diese Läufe herum. Es steuert Auslöser, Aufgabenverteilung, Verifikation und Abbruchbedingungen.

Boris Cherny bringt diese Entwicklung prägnant auf den Punkt:

“Ich prompte Claude nicht mehr. Ich habe Schleifen laufen, die Claude prompten und herausfinden, was zu tun ist. Mein Job ist es, Schleifen zu schreiben.”

Das Handwerk der Befehlseingabe stirbt nicht aus, sondern wird zu einem untergeordneten Baustein innerhalb eines größeren Systems.

Die Trennung von innerer und äußerer Schleife

In jedem agentischen Werkzeug existieren zwei unterschiedliche Schleifen. Die innere Schleife ist im Agenten fest integriert und folgt dem ReAct-Muster aus Planung, Werkzeugaufruf und Beobachtung. Die äußere Schleife wird vom Entwickler im Code konstruiert.

Ein strukturierter Ablauf der äußeren Schleife umfasst fünf Phasen:

1. Trigger: Ein Zeitplan, Ereignis oder Heartbeat startet den Durchlauf.
2. Frame: Das System liest den aktuellen Zustand und baut die konkrete Aufgabe.
3. Run: Der Agent führt seine innere Schleife autonom aus.
4. Verify: Eine externe Instanz prüft das erzeugte Ergebnis.
5. Record: Der neue Zustand wird außerhalb des Modells dauerhaft gespeichert.

Diese äußeren Schleifen treten in vier Formen auf. Heartbeat-Schleifen laufen kontinuierlich zur Überwachung von Warteschlangen. Cron-Schleifen starten nach festem Zeitplan für nächtliche Code-Reviews. Hook-Schleifen reagieren auf Ereignisse wie fehlgeschlagene CI-Pipelines. Goal-Schleifen iterieren so lange, bis eine definierte Zielbedingung erfüllt ist.

Maschinelle Abbruchbedingungen statt KI-Einschätzung

Das größte Risiko autonomer Schleifen sind unkontrollierte Endlosschleifen oder vorzeitiges Abbrechen. Generative Modelle tendieren dazu, die eigene Arbeit als korrekt einzustufen. Die Aussage des Modells, eine Refaktorierung sei abgeschlossen, besitzt keine Aussagekraft. Erst ein bestandener Testsuite-Lauf liefert den verlässlichen Beleg.

Zur Absicherung werden drei Schutzschichten kombiniert:

import json, subprocess, sys

MAX_ITERATIONS = 8
STATE_FILE = "loop-state.json"

def load_state():
    try:
        return json.load(open(STATE_FILE))
    except FileNotFoundError:
        return {"queue": ["auth/session.py", "auth/token.py"], "done": []}

def verified():
    return subprocess.run(["pytest", "-q"]).returncode == 0

def run_agent(task):
    subprocess.run(["claude", "-p", task])

for i in range(MAX_ITERATIONS):
    state = load_state()
    if not state["queue"]:
        print("Ziel erreicht")
        sys.exit(0)
    target = state["queue"][0]
    run_agent(f"Migriere {target}. Erledigt: {state['done']}")
    if verified():
        state["done"].append(state["queue"].pop(0))
        json.dump(state, open(STATE_FILE, "w"))

print("Iterationslimit erreicht")

Das gezeigte Minimalbeispiel nutzt harte Limits für die maximale Iterationszahl, eine maschinelle Prüfung durch Pytest und einen externen Speicher.

Besonders kritisch ist die Architektur der Verifikation. Der Agent, der den Code generiert, darf niemals die Freigabe erteilen. In produktiven Setups arbeitet der ausführende Agent in einem isolierten Git-Worktree, während ein zweiter Agent mit eigenem Kontext das Ergebnis anhand der Projektregeln bewertet.

Das Dilemma der kognitiven Überlastung

Kritiker wenden ein, dass Dutzende parallel laufender Agenten zu unkontrollierbarem Code-Output führen. Dieses Gegenargument ist berechtigt. Die Grenze für parallele Agenten liegt nicht in der Rechenleistung, sondern in der menschlichen Kapazität zur Review der Ergebnisse.

Wenn Schleifen schneller Code produzieren, als Entwickler ihn verstehen können, entstehen kognitive Schulden. Das Team verliert schrittweise das tiefere Verständnis für die eigene Codebasis. Autonome Schleifen übernehmen die Ausführung der Aufgaben, entbinden Entwickler jedoch nicht von der Verantwortung für die Architektur und Qualität.

4 Schritte zur Umsetzung

1. Wiederkehrende Routine wählen: Starte mit einer überschaubaren Aufgabe wie CI-Fehler-Triage.
2. Konventionen schriftlich fixieren: Dokumentiere alle Projektregeln in einer Anweisungsdatei.
3. Schutzschichten vorab installieren: Definiere harte Iterationsgrenzen und Testprüfungen vorab.
4. Schleife schrittweise kalibrieren: Betreibe die Schleife eine Woche lang unter Beobachtung.

Wer 50 unbewachte Agenten startet, verbrennt Token; wer eine abgesicherte Schleife jede Nacht laufen lässt, baut Software.