Ich ließ Claude 4 Stunden lang programmieren. Es baute etwas, das niemand wollte.

Ich öffne das Terminal. 4 Stunden später. Das Dashboard läuft auf dem privaten Server, die API-Schicht ist immer noch öffentlich. Ungefähr das, was ich wollte. 😬

Außerdem im Diff: 2 Komponenten extrahiert und in eine Datei verschoben, die niemand zu öffnen gebeten hatte, ein Runtime-Version-Bump, der stillschweigend die Cloud-Build-Pipeline verändert, und ein Commit auf main gepusht, bevor das Deployment als stabil bestätigt war.

Nichts davon ist katastrophal. Die Session hat funktioniert. Aber die 3-stündige Debug-Phase, die den Großteil der Rechenzeit verbrannt hat, kam von einer Einschränkung, die in meiner ersten Nachricht fehlte. Die Aufgabe: das Order-Management-Dashboard vom öffentlichen Hosting auf einen privaten Server verschieben, nur intern. Was ich vergessen hatte zu erwähnen: die API-Schicht musste öffentlich zugänglich bleiben. Externe Partner rufen sie auf. Sie zu verschieben würde alles downstream kaputt machen.

Claude fragte nach, ich antwortete, es passte sich an. Aber zu dem Zeitpunkt war die Architektur bereits in die falsche Richtung skizziert, und der Build-Konflikt mit dem Integration-Handler, der folgte, brauchte über 200 Tool-Calls zum Entwirren. In der Post-Mortem-Analyse nannte Claude selbst die Grundursache: "Wenn die erste Nachricht gesagt hätte 'Dashboard wird intern, aber die API-Schicht bleibt öffentlich', hätte ich den Build-Konflikt antizipiert. Diese Divergenz war nicht im Brief."

~600k Token. Das Briefing waren 6 Nachrichten, die in 10 Minuten gesendet wurden, während ich etwas anderes veröffentlichen musste.

Warum Loops anders brechen als Prompts

Jeder in der aktuellen Loop-Hype-Welle redet über /goal, Sub-Agenten, max-turns-Flags, Token-Kosten. Niemand redet über das Briefing.

In einem Gespräch führt Mehrdeutigkeit zu einer Rückfrage. Claude sagt "meintest du X oder Y?" und du korrigierst in 10 Sekunden. In einer autonomen Schleife führt dieselbe Mehrdeutigkeit zu stundenlanger Arbeit in die falsche Richtung. Das Modell stockt nicht, wenn es auf eine unklare Einschränkung trifft. Es löst die Mehrdeutigkeit selbst auf und macht weiter, was eigentlich das Feature ist, bis es zum Bug wird.

Ein LogRocket-Test von Claude Code mit Ralph machte das konkret. Brief: "Baue ein GitHub-Stats-CLI-Tool. Mach es gut." Die Schleife lief 5 Minuten 41 Sekunden und lieferte ein funktionales Tool mit Benutzerprofil-Abruf, Sprach-Breakdown-Analyse und Rate-Limit-Prüfung. Nichts davon war angefordert. Dieselbe Aufgabe mit einer expliziten Exit-Bedingung und Scope-Fence: saubere Ausführung, kein Scope-Creep, auf jedem Punkt mit den definierten Kriterien abgestimmt. Der einzige Unterschied war das Briefing.

Eine kürzliche Medium-Analyse der /goal-Mechaniken benannte genau dieses Muster. Du gibst Claude eine lange Refactoring-Aufgabe, es läuft dutzende Schritte, alles wird ausgeführt. Dann schaust du dir an, was gebaut wurde. Technisch korrekt. Nur nicht das, was du wolltest. "Es ist gedriftet." Drift kommt nicht vom Modell. Es kommt vom Briefing.

Der Fehler, den ich immer wieder machte, war anzunehmen, dass meine Prompting-Fähigkeiten automatisch auf Loop-Sessions übertragen werden. Das Vertrauen, dass sie es tun, ist der gefährliche Teil, weil sich die 2 Fähigkeiten von innen identisch anfühlen. Es ist im Grunde das "läuft auf meiner Maschine" der Agent-Tools: jede überwachte Session läuft sauber, du hast die Commit-History als Beweis, und dann feuerst du ein Loop-Brief mit demselben Vertrauen ab und gehst weg.

Prompting geht darum, Claude genug Kontext zu geben, um die nächsten paar Austausche zu navigieren, während du zuschaust, nah genug, um zu korrigieren, wenn es in die falsche Richtung geht. Loop-Briefing geht darum, Claude genug Einschränkungen zu geben, um 50 oder 80 Schritte ohne deine Anwesenheit zu navigieren, wo jede Mehrdeutigkeit durch die beste Vermutung des Modells statt durch deine echte Absicht gelöst wird, und diese Vermutungen sich über dutzende Tool-Calls zu etwas zusammensetzen, das oberflächlich völlig korrekt aussehen kann, während es strukturell falsch für deine tatsächlichen Bedürfnisse ist. Die Vagheit, die in einem Prompt tolerierbar ist (die Art, die du in 1 Folgenachricht auflöst), ist fatal in einem Loop-Brief, wo es keine Folgenachricht gibt, und die Session bereits 400k Token verbrannt hat, bis du dir anschaust, was es gebaut hat.

3 Drift-Modi, 3 Zeilen, die sie beheben

Es gibt 3 verschiedene Arten, wie Loop-Briefings scheitern. Jede entspricht einer fehlenden Komponente.

Scope-Creep: fehlende Scope-Fence

Claude interpretiert qualitative Anweisungen ("gut", "sauber", "vollständig") als Einladung zur Expansion. Es halluziniert nicht, es optimiert. Das Problem ist, dass seine Definition von "gut" Entscheidungen einschließt, die du nicht autorisiert hast.

In meiner Session: 2 Komponenten refactored und während der Debug-Phase verschoben, nicht weil es im Brief stand, sondern weil die Dateistruktur einen Build-Export-Fehler verursachte und es zu beheben war adjacent zum eigentlichen Problem. Das Modell löste ein echtes Problem. Eines, nach dem ich es nicht gebeten hatte zu schauen.

Die Lösung ist eine Scope-Fence: eine explizite Liste dessen, was nicht angefasst wird, so spezifisch wie das, was angefasst wird.

Schlecht: "Refactore das Auth-Modul."

Gut: "Refactore das Auth-Modul. Füge keine neuen Funktionen hinzu. Modifiziere keine Tests. Berühre keine Datei außerhalb von /src/auth."

Die negative Einschränkung leistet genauso viel Arbeit wie die positive. Ich bin tiefer in den Aufbau einer CLI-Enforcement-Schicht für autonome Agenten in einem früheren Stück eingegangen, und das Verifikationsmuster entspricht direkt der Loop-Scope-Kontrolle.

Drift: fehlende Exit-Bedingung

Die Ausführung läuft sauber, 30+ Schritte, keine Fehler. Aber irgendwo um Schritt 12 nimmt die Schleife eine Abzweigung, die du nicht beabsichtigt hattest, und bis sie liefert, hast du eine technisch korrekte Lösung für das falsche Problem. In meiner Session wurde die Architektur-Abzweigung (API-Schicht bleibt öffentlich) im Gespräch während der ersten 15 Minuten gelöst. Aber keine Exit-Bedingung kodierte diese Einschränkung explizit, also gab es keine Ground Truth für einen unabhängigen Checker zur Verifikation.

Grundursache: keine Exit-Bedingung, oder eine zu vage, um die falsche Abzweigung zu fangen.

MindStudios Agentic-Loop-Guide bringt es in 1 Satz: "Schreibe die Erfolgsbedingung, bevor du den Prompt schreibst. Wenn du sie nicht in 1 Satz definieren kannst, verkleinere den Aufgabenbereich." Ihre Begleitregel: übergib immer --max-turns bei autonomen Aufgaben als mechanischen Fallback, wenn die Exit-Bedingung nicht sauber erreicht wird.

Schlecht: "Wenn es gut aussieht."

Gut: "Wenn alle 47 bestehenden Tests bestehen, das Dashboard auf Port 3013 im internen Netzwerk antwortet und keine Datei außerhalb von /src/dashboard modifiziert wurde."

Offensichtlich kann "wenn es gut aussieht" von nichts verifiziert werden, was nicht du bist. Ein Agent, der parallel läuft, hat keinen Zugang zu deinem ästhetischen Urteil. Die Exit-Bedingung muss binär und ohne Kontext prüfbar sein.

Vielleicht liege ich falsch, aber ich denke, die Exit-Bedingung ist schwerer zu schreiben als die Scope-Fence. Sie zwingt dich dazu, dich darauf festzulegen, was "fertig" tatsächlich bedeutet, bevor du angefangen hast. Meiner Erfahrung nach ist es das Stück, das zuerst übersprungen wird, und das, was am meisten kostet, wenn es fehlt.

Silent Loop: keine Eskalationskriterien

Scope-Fence definiert, Exit-Bedingung definiert. Trotzdem möglich, dein Budget stillschweigend zu verbrennen, wenn die Schleife einen Zustand trifft, den sie nicht auflösen kann und weiter versucht. Ein Builder auf X nach 6 Wochen Produktions-Loops: "Die Macht ist real, aber auch die Kosten, wenn ein Agent stillschweigend in einen schlechten Loop-Zustand eintritt... bis deine API-Rechnung ankommt."

In meiner Session zeigte sich das als Zombie-Prozess, der einen alten Build servierte und eine Phase von falsch-negativen Testläufen produzierte, bevor Claude korrekt einen Blocker meldete. Der Zombie reagierte nicht auf pkill. HAL 9000-Energie: ruhige Bestätigung jeder Diagnose-Anfrage, aktiver Widerstand gegen das Herunterfahren. Außer es war ein Unix-Socket und keine mörderische KI, was es irgendwie schwerer zu beheben machte. Mit einer Eskalationsregel im Brief stoppt es und meldet, anstatt zu beharren.

Schlecht: nichts. Claude managed.

Gut: "Wenn das Dashboard nach 3 Deploy-Versuchen nicht lädt, stoppe sofort. Melde den letzten Fehler und die letzten 3 modifizierten Dateien. Versuche keinen 4. Deploy."

Diese letzte Zeile ist wichtig. Ohne sie versucht Claude es erneut, berührt dabei mehr Dateien außerhalb der Scope-Fence, und du kommst zu einer Codebasis zurück, die weiter gedriftet ist als dort, wo du sie verlassen hast.

Der Andere-Zimmer-Test

Vor dem Start jeder autonomen Schleife, 1 Frage: könnte ein Agent, der meinen Code nie gelesen hat, verifizieren, dass diese Aufgabe erledigt ist?

Wenn nein, ist die Exit-Bedingung zu vage.

Lance Martin von Anthropics Thread über Loop-Design machte das Prinzip explizit: der Bewerter muss unabhängig vom Ausführer sein. Claude kann seine eigene Arbeit nicht bewerten. Der Verifizierer-Sub-Agent erhält die Exit-Bedingung und gibt ein binäres Urteil zurück. Kein Zugang zu Kontext, Absicht oder Gesprächshistorie. Nur die Bedingung und den aktuellen Zustand. Bestanden oder durchgefallen. Darauf ist /goal aufgebaut: ein separater Bewerter, der prüft, ob die definierte Erfolgsbedingung erfüllt wurde, ohne deine Absicht hineinzulesen. Die Exit-Bedingung ist die einzige Schnittstelle zwischen deiner Absicht und dem Verifizierer. Wenn sie mehrdeutig ist, kann der Verifizierer dir nicht helfen. (Das RPG-Äquivalent: den Krieger bitten, seine eigene Dungeon-Räumung zu bewerten. Er wird immer ja sagen.)

Es lohnt sich, eine Unterscheidung vom Prompt-Contracts-Ansatz für überwachte Claude Code-Sessions zu ziehen, wo ein präzises Briefing eine Session strukturiert, die du beobachtest und in Echtzeit steuern kannst. Loop-Briefings sind für Sessions, bei denen du nicht da sein wirst, um zu steuern. Die Contract-Gewohnheit kommt zuerst. Das Loop-Briefing erweitert sie auf autonome Sessions mit einer anderen Einschränkung: keine Steuerung erlaubt.

Kurzer Exkurs, der nichts mit all dem zu tun hat: Ich führe seit ein paar Monaten denselben Post-Mortem-Prompt mit menschlichen Mitarbeitern durch und frage sie "was in meinem Briefing, wenn anders, hätte deine Ausführung verändert?" Die Antworten sind durchweg nützlicher als jede Retro, die ich durchgeführt habe. Menschen melden den Übergabefehler nicht natürlich. Sie beschreiben, was sie gebaut haben. Sie dazu zu bringen, die fehlende Einschränkung zu benennen, produziert etwas, das einem echten Audit nahekommt.

Brief zuerst, Loop danach

Die Session-Kosten: ~600k Token, ein Runtime-Version-Bump, der die Cloud-Build-Umgebung ohne meine Überprüfung veränderte, 2 Komponenten in einer Codebasis verschoben, die ich nicht zu öffnen plante, ein Commit auf main, bevor das Deployment stabil war, und 3 Stunden Debug von einer Einschränkung, die ich aus der ersten Nachricht weggelassen hatte. Nichts davon ist ein Modellfehler. Alles war aus dem Briefing vorhersagbar. Die Schleife lief gut. Das Briefing nicht, und diese Lücke ist es, was die 3 Stunden verbrannt hat.

Die 3 Stücke, die fehlten: eine Scope-Fence, die auflistet, was nicht angefasst wird, eine Exit-Bedingung, die von einem unabhängigen Agenten verifizierbar ist, und eine Eskalationsregel, die die Schleife stoppt, bevor sie durch einen schlechten Zustand brennt. Nicht in CLAUDE.md, was persistentes Verhalten über Sessions hinweg behandelt. Im Briefing selbst, vor jedem autonomen Lauf.

Ein Builder auf X nach dem Verbrennen einer ganzen Session: "Viele Token... Ergebnis war totaler Mist. Musste von vorne anfangen." Das ist es, was ein fehlendes Briefing im großen Maßstab kostet.

Wenn du an dem Punkt bist, wo Loops laufen, aber nicht immer landen, behandelt Vibe Coding, For Real (Amazon Kindle, kostenlos mit Kindle Unlimited) die Grundlage: die Methode, um von "es läuft" zu "es liefert zuverlässig" zu kommen.

---

Die 4 Stunden bauten ungefähr das, was ich wollte, plus einige Dinge, die ich nicht wollte, und verbrannten 3 Stunden Rechenzeit für eine Einschränkung, die nicht in der ersten Nachricht stand. In der Post-Mortem-Analyse sagte mir Claude genau, welcher Satz es verändert hätte.

Ich habe diesen Satz jetzt. Ich werde ihn beim nächsten Mal zuerst schreiben.

Geh und schreibe die Exit-Bedingung vor dem Prompt.

---

Quellen

• How Ralph makes Claude Code actually finish tasks, LogRocket Blog
• How to Build an Agentic Loop with Claude Code, MindStudio
• Dynamic Workflows vs /goal in Claude Code, Medium / No Time
• @RLanceMartin (Lance Martin, Anthropic), X, June 9, 2026
• @saen_dev (Saeed Anwar), X, June 7, 2026
• @atlanticesque, X, June 11, 2026
• Vibe Coding, For Real, Amazon Kindle

Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).