Loop Engineering Claude Code 2026: was läuft, wenn Sie nicht davorsitzen

Constantin, Platform Engineering bei Pexon Consulting | 11 Min. Lesezeit | 31.08.2026

TL;DR

Loop Engineering heißt: Sie prompten den Agenten nicht mehr, Sie bauen das System, das ihn promptet. In Claude Code sind das vier Bausteine, /goal, /loop, Desktop-Tasks und Cloud-Routines. Der Unterschied zwischen einem Loop, der trägt, und einem, der Geld verbrennt, ist ein einziges Bauteil: ein Prüfer ohne Meinung.

Warum der Loop, den Sie gestern gebaut haben, nächste Woche still steht

Der häufigste Fehler ist nicht der falsche Befehl. Er ist die Annahme, dass ein Loop weiterläuft, weil er gestern gelaufen ist.

Ein Beispiel aus unserem eigenen Betrieb. Wir fahren bei Pexon 14 KI-Agenten produktiv, darunter eine wöchentliche SEO-Pipeline und einen monatlichen Indexing-Lauf. Der erste Anlauf lief lokal über /loop. Nach genau sieben Tagen kam nichts mehr, ohne Fehlermeldung, ohne Log-Eintrag. Der Grund steht in der Dokumentation und niemand liest ihn vorher: wiederkehrende /loop-Tasks laufen nach sieben Tagen aus. Sie feuern ein letztes Mal und löschen sich selbst.

Das ist kein Bug, das ist eine Sicherung. Sie begrenzt, wie lange ein vergessener Loop Geld ausgeben kann. Aber wer sie nicht kennt, baut einen Dauerbetrieb auf eine Wochenfrist.

Genau solche Details entscheiden, ob Loop Engineering bei Ihnen ein Produktivitätsgewinn wird oder ein Posten in der nächsten Abrechnung. Deutsche Artikel zum Thema erklären derzeit fast ausschließlich den Begriff. Dieser hier erklärt den Betrieb.

Loop Engineering Claude Code: die vier Ebenen und wo Ihr Setup gerade steht

Loop Engineering ist die vierte von vier Ebenen, die aufeinander aufbauen statt sich abzulösen. Das Claude-Code-Team definiert einen Loop schlicht als einen Agenten, der Arbeitszyklen wiederholt, bis eine Abbruchbedingung hält. Was sich zwischen den Ebenen ändert, ist die Einheit, die Sie noch selbst in der Hand haben.

Je höher die Ebene, desto weiter sind Sie vom Geschehen weg und desto länger sammeln sich Fehler an, bevor jemand sie bemerkt. Das ist der eigentliche Grund, warum ein Loop mehr Disziplin braucht als ein Prompt, nicht weniger.

Eine Abgrenzung vorweg, weil die Begriffe im Deutschen kollidieren: Human-in-the-Loop meint einen Freigabeprozess mit einem Menschen im Ablauf. Damit hat Loop Engineering nichts zu tun. Hier geht es um die Schleife, die der Agent von selbst dreht.

Loop oder Graph: welche Form fährt Ihr Setup wirklich

Fragen Sie zehn Entwickler, die mit Agenten arbeiten, welche der beiden Formen sie einsetzen. Die meisten haben die Frage noch nie gestellt bekommen.

Ein Loop gibt den Rahmen vor, den Weg sucht der Agent selbst. Das passt, solange die Route noch niemand kennt. Loops sind flexibel und praktisch nicht testbar. Ein Graph zeichnet den Weg vor, der Agent füllt nur die Knoten. Das ist sauber testbar, setzt aber voraus, dass die Karte schon existiert.

Unsere Regel dafür ist unspektakulär und hat sich bewährt: Frieren Sie einen Loop zu einem Graphen ein, sobald er Sie nicht mehr überrascht. Solange jeder Lauf noch etwas zutage fördert, mit dem Sie nicht gerechnet haben, ist die Freiheit ihren Preis wert. Ab dem Punkt, an dem er jeden Morgen dasselbe tut, zahlen Sie für Freiheit, die niemand mehr braucht.

Die vier Loop-Typen und welcher Befehl dahinter steckt

Claude Code sortiert Loops nach zwei Fragen: Was startet einen Lauf, und was beendet ihn. Aus den Antworten ergibt sich der Befehl.

Zwei davon werden ständig verwechselt, und daran scheitern die meisten kaputten Loops: /loop läuft auf einer Uhr, /goal läuft bis eine Bedingung hält. Takten und Aufhören sind zwei getrennte Aufgaben.

Die Angaben hier beziehen sich auf Claude Code v2.1.248, Stand August 2026. Das ist keine Formalie: /loop ohne Intervall, bei dem Claude die Pause zwischen einer Minute und einer Stunde selbst wählt und nach jeder Runde begründet, braucht genau diese Version. Auf älteren Ständen läuft derselbe Befehl stumpf auf einem festen 10-Minuten-Takt. Die jeweils gültigen Details stehen in der Dokumentation zu geplanten Aufgaben.

/goal schreiben, das der Bewerter auch prüfen kann

/goal setzt eine Abschlussbedingung, und nach jedem Zug entscheidet ein kleines schnelles Modell, ob sie erfüllt ist. Standard dafür ist Haiku (claude-haiku-4-5-20251001), einstellbar über ANTHROPIC_DEFAULT_HAIKU_MODEL. Der wichtigste Satz dazu steht klein in der Dokumentation: der Bewerter ruft selbst keine Werkzeuge auf. Er urteilt ausschließlich über das, was Claude im Gesprächsverlauf sichtbar gemacht hat.

Daraus folgt alles Weitere. Eine Bedingung wie „der Code sieht sauber aus“ kippt im ersten Zug. Eine wie diese hält über zwanzig:

/goal alle Tests in test/auth laufen durch und der Lint-Schritt ist sauber,
oder nach 20 Zügen aufhören

Was Sie sonst noch wissen sollten, bevor Sie das produktiv einsetzen: ein Ziel pro Session, ein neues ersetzt das alte, die Bedingung darf 4.000 Zeichen lang sein. Der Bewerter kennt drei Urteile, nicht zwei. Neben „erfüllt“ und „noch nicht erfüllt“ gibt es „unmöglich“, und in dem Fall räumt Claude Code das Ziel von selbst ab. Vier Fehlerarten löschen es ebenfalls: Authentifizierungsfehler, aufgebrauchtes Guthaben, ein Kontext, den die Auto-Kompaktierung nicht mehr aufräumen kann, und ein nicht verfügbares Modell. Alles andere, auch Rate-Limits, lässt das Ziel stehen.

Ein Punkt für alle, die in einem Unternehmen mit strengen Vorgaben arbeiten: /goal ist technisch ein Stop-Hook mit Session-Geltung. Ist disableAllHooks gesetzt oder gilt der Ordner nicht als vertrauenswürdig, fehlt der Befehl. Das ist der Grund, warum er bei einer Kollegin auftaucht und bei Ihnen nicht.

Wo der Loop wirklich läuft: Laptop, Desktop-Task oder Cloud

„Der Agent arbeitet, während Sie schlafen“ ist der meistzitierte und am häufigsten falsch verstandene Satz zum Thema. Lokal stimmt er nicht. Deckel zu heißt Loop tot.

Lesen Sie die Tabelle von der Aufgabe her, nicht vom Werkzeug. Einen lokalen Dev-Server jede Minute beobachten geht nur mit /loop. Um drei Uhr nachts offene Issues sichten und Pull Requests aufmachen gehört in eine Cloud-Routine, weil Laptops aus dem Haus getragen werden.

Vier Details, die in keinem der deutschen Artikel zum Thema stehen und die Sie einplanen müssen:

1. Sieben Tage. Wiederkehrende /loop-Tasks laufen aus, feuern ein letztes Mal und löschen sich.
2. Versatz. Wiederkehrende Tasks feuern bis zu 30 Minuten nach der geplanten Zeit, abgeleitet aus der Task-ID. Wer 0 9 * plant, bekommt irgendetwas bis 9:30. Brauchen Sie exakte Zeiten, nehmen Sie eine Minute, die weder :00 noch :30 ist.
3. Kein Nachholen. Verpasste Feuer werden nicht nachgeholt, sondern genau einmal beim nächsten Leerlauf.
4. 50 Tasks pro Session, danach ist Schluss. Der Not-Aus für alles zusammen ist CLAUDE_CODE_DISABLE_CRON=1.

Und ein Hinweis, der Ihnen mehr spart als jede Optimierung am Loop selbst: Wenn Sie nur auf ein Ereignis warten, brauchen Sie überhaupt keinen Loop. Das Monitor-Werkzeug streamt Ereignisse aus einem Hintergrund-Skript, statt in Intervallen neu zu prompten, und ist dabei deutlich sparsamer im Token-Verbrauch.

Cloud-Routines, seit April 2026 im Research Preview, bringen eigene Regeln mit, die für Ihre IT-Governance relevanter sind als die Technik: Sie laufen ohne Berechtigungsabfragen durch, alle verbundenen Connectors sind standardmäßig eingeschlossen, inklusive Schreibrechten. Sie hängen am persönlichen claude.ai-Konto, nicht am Team, deshalb tragen Commits und Pull Requests Ihren GitHub-Namen. Und Team- oder Enterprise-Owner können Routines organisationsweit abschalten.

Der Prüfer, den fast alle weglassen

Etwas zu bauen, das läuft, ist die leichte Hälfte. Die schwere ist, etwas hineinzubauen, das Nein sagen kann.

Ein Agent, der seine eigene Arbeit bewertet, lobt sie. Das ist kein Intelligenzproblem, sondern ein strukturelles. Im Kontext, in dem der Code entstanden ist, stehen sämtliche Argumente dafür, ihn genau so zu schreiben. Beim Nachlesen sieht der Agent seine eigene Begründung statt des Ergebnisses. Wer schon einmal einen eigenen Text am selben Tag korrekturgelesen hat, kennt den Effekt.

In einer Schleife potenziert sich das. Jede Runde, in der der Autor „gut genug“ entscheidet, ist eine Runde, in der er sich selbst zustimmt.

Hier verhandeln wir nicht: das Gate darf keine Meinung haben. Etwas, das kompiliert oder nicht, das 0 zurückgibt oder etwas anderes. Ein Prüfer mit Meinung argumentiert sich früher oder später in eine Freigabe hinein. Genau deshalb ist /goal als Produktbaustein interessant, dort entscheidet ein frisches Modell über den Abschluss, das an der Arbeit nicht beteiligt war. Banken fahren seit Jahrzehnten nach derselben Regel: Wer eine große Überweisung erfasst, darf sie nicht freigeben.

Der einfachste Weg, das Gate reproduzierbar zu machen, ist eine SKILL.md mit den Prüfschritten, die Sie sonst von Hand gehen:

---
name: verify-frontend-change
description: Jede UI-Änderung end-to-end prüfen, bevor sie als fertig gilt.
---

1. Dev-Server starten, die geänderte Seite öffnen
2. neues Bedienelement klicken, Zustandswechsel bestätigen, Screenshot vorher/nachher
3. Browser-Konsole: keine neuen Fehler oder Warnungen
4. Performance-Trace laufen lassen, Core Web Vitals prüfen

Scheitert ein Schritt: beheben und ab Schritt 1 neu.

Je messbarer diese Schritte sind, desto weniger Spielraum hat Claude, sich früh für fertig zu erklären. Wie solche Skills sauber geschnitten werden und woran die ersten meistens scheitern, gehört zu den Bausteinen, die wir in der Entwicklung eigener Claude Skills mit Teams aufbauen. Wie Sie Hooks, MCP-Server und Sub-Agents darunter konfigurieren, steht in unserem Artikel zu Hooks, Skills und MCP in Claude Code. Die Frage, wie viel Vertrauen KI-generierter Code überhaupt verdient, behandeln wir separat unter Quality Engineering für Agentic Coding.

Ins Gate gehören übrigens auch die Sicherheitsprüfungen. Generierter Code wird schneller gemerged als gelesen, also gehören SAST, Abhängigkeits-Audit und Secret-Scanning in denselben Schritt, der über Annehmen oder Ablehnen entscheidet.

Was ein Loop kostet, und wo die Rechnung entsteht

Die gute Nachricht zuerst, weil sie meistens untergeht. Andrej Karpathy hat am 8. März 2026 einen Agenten auf seinen eigenen Trainingscode angesetzt und den Laptop zugeklappt. Zwei Tage später hatte der Lauf rund 700 Experimente durch, 20 echte Verbesserungen gefunden und die Trainingszeit von 2,02 auf 1,80 Stunden gedrückt, also um 11 Prozent. Darunter ein fehlender Skalar in der QK-Norm der Attention, den kein Linter findet. Die Rechenkosten dafür lagen unter 300 US-Dollar. Das zugehörige Repository karpathy/autoresearch steht heute bei 94.993 Sternen (abgerufen am 31.08.2026).

Ein Loop wird also nicht teuer, weil er läuft. Er wird teuer, weil niemand zählt.

Die Größenordnung für einen einzelnen geplanten Task mit ungefähr 5.000 Token Eingabe und 10.000 Token Ausgabe liegt bei etwa 6 bis 8 US-Dollar im Monat. Das klingt harmlos. Bei 20 Tasks ist es eine Position im Budget, und bei einem Loop, der wegen einer falschen Abbruchbedingung die ganze Nacht dreht, ist es eine Rechnung statt eines Fixes. Wie sich solche Sprünge aufbauen und was Claude Code im Unternehmen realistisch kostet, haben wir in der Rechnung über 2.500 Euro aufgeschlüsselt.

Vier Rechnungen laufen mit, und keine davon meldet sich von selbst:

• Ungeprüfte Ausgabe stapelt sich, Fehler sammeln sich außer Sicht. Gegenmittel ist der Prüfer aus dem vorigen Abschnitt.
• Verständnis-Verfall. Das Repository wächst, Ihre Landkarte im Kopf bleibt stehen. Gegenmittel: wöchentlich ein paar gemergte Diffs lesen und sich selbst erklären.
• Urteils-Aufgabe. Je ruhiger der Loop läuft, desto weniger schauen Sie hin, desto weniger können Sie beurteilen. Ausführung dürfen Sie abgeben, Entscheiden nicht.
• Token-Ausreißer. Deckel pro Lauf, Deckel pro Tag, maximale Wiederholungen. Vor dem Scharfschalten, nicht danach.

Und eine Kennzahl, die alle anderen schlägt: Kosten pro angenommener Änderung. Token-Verbrauch, Anzahl Pull Requests und Anzahl laufender Loops sehen alle nach Fortschritt aus und messen ihn nicht. Wenn weniger als die Hälfte dessen, was Ihr Loop produziert, das Review übersteht, machen Sie genau die Arbeit, die der Loop abnehmen sollte. Die Rohdaten dafür liefert Claude Code selbst: /usage schlüsselt den Verbrauch nach Skills, Sub-Agents und MCP-Servern auf, /goal ohne Argument meldet Züge und Tokens des laufenden Ziels.

Ein Satz zum Aufschreiben: War Ihre Review-Kapazität vorher schon der Engpass, verlängert ein Loop die Warteschlange, statt sie zu kürzen.

Der erste Loop in fünf Schritten

Die Reihenfolge zählt hier mehr als das Werkzeug. Wer sie überspringt, baut den Loop, der nachts Schaden anrichtet.

Vorher der Filter. Vier Bedingungen müssen gleichzeitig gelten, sonst nimmt der Loop mehr, als er zurückgibt: Die Aufgabe kommt mindestens wöchentlich wieder, es gibt einen Befehl, der schlechte Ergebnisse automatisch ablehnt, das Token-Budget verträgt Ausschuss, und der Agent hat ordentliche Werkzeuge, also Logs, eine Umgebung zum Nachstellen und die Möglichkeit, das Geschriebene laufen zu sehen.

Was sich zuerst lohnt, ist unspektakulär: CI-Fehler sortieren, Abhängigkeits-Updates, Lint-und-Fix-Durchläufe, flatternde Tests nachstellen. Was spannend klingt, bleibt manuell. Architektur-Umbauten, Authentifizierung, Zahlungsabwicklung, Produktiv-Deploys und vage Produktarbeit gehören nicht in einen Loop, und daran halten wir uns auch bei uns selbst.

1. Einen manuellen Lauf zuverlässig machen. Erledigen Sie die Aufgabe so lange von Hand mit Claude, bis das Ergebnis reproduzierbar und langweilig ist. Was Sie nicht wiederholen können, können Sie nicht automatisieren.
2. Den Lauf als Skill aufschreiben. Konventionen, Build-Schritte, der Workaround für den einen flatternden Runner. Lassen Sie den Zeitplan einen benannten Skill starten statt einer Wand aus eingefügtem Text. Anweisungen, die in einem Cron-Job stecken, aktualisiert nie wieder jemand.
3. Zustandsdatei anlegen. Eine STATE.md im Repository-Wurzelverzeichnis. Versioniert, im Diff lesbar, langweilig.
4. Gate und Deckel setzen. Eine objektive Prüfung plus ein Zug-Limit. Erst in diesem Schritt bekommt der Loop überhaupt die Fähigkeit zu scheitern.
5. Dann erst takten. /loop, solange Sie danebensitzen. Eine Cloud-Routine erst, wenn Sie ihm unbeaufsichtigt trauen.

Die Zustandsdatei ist der Schritt, den die meisten weglassen, und der Grund, warum der zweite Lauf bei null anfängt:

# Loop-Zustand · ci-triage

## Letzter Lauf
2026-08-30 03:30 UTC · 7 Fehler eingeordnet, 3 Fixes entworfen, 4 eskaliert

## In Arbeit
- claude/fix-auth-token-refresh · Tests lokal grün, CI läuft noch

## An Menschen eskaliert
- src/billing/refund.ts · scheitert auf drei Wegen, Ursache unklar

## Gelernt (hierhin schreiben, nicht in den Chat)
- 2026-08-29: tests/e2e/checkout braucht das Stripe-Webhook-Secret. Ohne: überspringen

Der Kontext ist, was der Agent in dieser Runde sieht. Die Zustandsdatei ist, was das Leeren des Fensters überlebt. Nur eines von beidem gehört Ihnen. Für lange Läufe stellen Sie der STATE.md eine VISION.md an die Seite: die eine hält die Position, die andere das Ziel, und die zweite ist der Grund, warum ein Loop bei Zug 47 nicht abdriftet.

Ein letzter Hinweis aus der Praxis, der Ihnen einen ganzen Tag Fehlersuche spart: Lassen Sie parallel arbeitende Agenten in getrennten Git-Worktrees laufen. Zwei Agenten in derselben Datei sind derselbe Schlamassel wie zwei Entwickler, die ohne Absprache auf dieselben Zeilen pushen. Und geben Sie dem Bauenden das schnelle, günstige Modell und dem Prüfenden das langsamere, strengere, etwa claude-opus-5.

Diese fünf Schritte sind auch der Punkt, an dem Teams bei uns am häufigsten hängen bleiben, meistens zwischen Schritt 2 und 4. Wer den Weg lieber begleitet geht als allein, findet den Einstieg unten.

Häufig gestellte Fragen

Was ist Loop Engineering?

Loop Engineering bedeutet, dass Sie aufhören, die Person zu sein, die den Agenten promptet, und stattdessen das System bauen, das ihn promptet. Das System startet auf einen Auslöser hin, erledigt die Arbeit in einem abgeschotteten Bereich, lässt einen zweiten Agenten schlechte Ergebnisse ablehnen, schreibt auf, was passiert ist, und macht am nächsten Tag dort weiter, wo es aufgehört hat.

Was ist der Unterschied zwischen `/loop` und `/goal`?

/loop läuft auf einer Uhr und wiederholt einen Prompt in einem Intervall. /goal läuft, bis eine Bedingung hält, geprüft von einem eigenen Bewerter-Modell nach jedem Zug. Takten und Aufhören sind zwei verschiedene Aufgaben, und die Verwechslung ist die häufigste Ursache für Loops, die nicht das tun, was ihr Erbauer wollte.

Braucht Loop Engineering einen laufenden Rechner?

Für /loop und Desktop-Tasks ja, für Cloud-Routines nein. /loop verlangt zusätzlich eine offene Session. Cloud-Routines laufen auf der Anthropic-Infrastruktur weiter, sehen dafür aber keine lokalen Dateien, sondern arbeiten auf einem frischen Clone, und ihr Mindestintervall liegt bei einer Stunde.

Was kostet ein Loop, der über Nacht läuft?

Kommt darauf an, wie oft er feuert und wie viel er dabei liest. Ein einzelner täglicher Task mit rund 5.000 Token Eingabe und 10.000 Token Ausgabe liegt grob bei 6 bis 8 US-Dollar im Monat. Der Kostentreiber ist nicht der einzelne Lauf, sondern eine fehlende Abbruchbedingung: Ein Loop ohne Deckel dreht, bis ein Mensch ihn bemerkt.

Ist Loop Engineering dasselbe wie Human-in-the-Loop?

Nein, die beiden haben nur das Wort gemeinsam. Human-in-the-Loop beschreibt einen Freigabeprozess, bei dem ein Mensch an definierter Stelle im Ablauf entscheidet. Loop Engineering beschreibt die Schleife, die ein Agent selbstständig dreht. Ein gut gebauter Loop kann eine menschliche Freigabe enthalten, muss aber nicht.

Ersetzt Loop Engineering Prompt Engineering?

Nein, es setzt darauf auf. Der Prompt bleibt die kleinste Einheit, er steckt nur nicht mehr in Ihrem Terminal, sondern in einem Skill, den der Zeitplan aufruft. Ein schlechter Prompt in einem Loop wird nicht besser, er wird nur häufiger ausgeführt.

Nächster Schritt

Bauen Sie einen Loop auf eine Aufgabe, die Sie ohnehin jede Woche anfassen, und lassen Sie das Ergebnis über das Budget für den zweiten entscheiden. Wenn Ihr Team das gemeinsam und am eigenen Code lernen soll: In unserer Claude Code Schulung arbeiten Teams Loop Engineering praktisch durch, vom ersten Skill über das Gate bis zum getakteten Lauf.

Verwandte Themen