Der Chef von Claude Code hat aufgehört zu prompten. Das ist kein Tipp. Das ist ein Zeitplan.

Du solltest nicht mehr mit Coding-Agenten chatten. Du solltest Schleifen entwickeln, die deine Agenten für dich promten.

Das hat mich zum Lachen gebracht, als ich es sah. Peter Steinberger hat diese 12 Worte am 7. Juni auf X gepostet, und 6,5 Millionen Menschen haben sie in 24 Stunden gelesen. Und 5 Tage davor hatte Boris Cherny, der Chef von Claude Code, exakt dasselbe auf der Bühne eines WorkOS-Events gesagt. Fast Wort für Wort.

Es hat mich zum Lachen gebracht, weil ich das schon monatelang gemacht hatte, ohne einen Namen dafür zu haben.

Ich Nannte Es "Klär-Das-Selbst-Modus"

Der Workflow war simpel, vielleicht peinlich simpel. Ich setzte ein Ziel in /goal, legte eine CLAUDE.md mit den Projektregeln ab, gab Claude Code den Repo-Kontext und ging weg. Kam 20 Minuten später zurück, manchmal nach 2 Stunden. Entweder da war ein funktionierendes Feature oder ein Chaos, das repariert werden musste. Beide Ergebnisse brachten das Projekt voran.

Ich machte das nicht aus irgendeiner prinzipiellen Überzeugung heraus. Es passierte einfach, als ich aufhörte, den Output-Stream zu beobachten und anfing, Claude Code wie einen Junior-Entwickler zu behandeln, an den ich delegieren konnte. Ziel setzen, Kontext geben und weggehen.

Kein Label für irgendwas davon.

Dann postete Steinberger, und die Hälfte meines Feeds nickte zustimmend, während die andere Hälfte darüber stritt, ob das tatsächlich neu war oder nur Prompting mit Extra-Schritten. Und Chernys Clip von 5 Tagen früher machte die Runde. "Ich prompte Claude nicht mehr. Ich habe Schleifen laufen, die Claude promten und herausfinden, was zu tun ist. Mein Job ist es, Schleifen zu schreiben."

Wiedererkennung, nicht Entdeckung. Ich machte bereits eine Version davon. Es bekam nur einen Namen.

Diese Benennung ist wichtiger, als es auf den ersten Blick aussieht. Ohne einen Begriff für eine Praxis kannst du dich nicht darüber austauschen, du kannst das Muster nicht bewusst verbessern, und du kannst nicht sagen, ob du es gut oder schlecht machst. "Klär-das-selbst-Modus" funktionierte gut als persönliche Abkürzung. "Loop Engineering" ist etwas, um das herum du eine Methodologie aufbauen kannst. Das Konzept änderte sich nicht zwischen dem 2. und 7. Juni. Was sich änderte: Jetzt verwenden alle im selben Gespräch dasselbe Wort, und die Leute, die es noch nicht machten, wissen jetzt, was ihnen fehlt.

Auf Welcher Stufe Stehst Du?

Was Cherny bei WorkOS Acquired Unplugged am 2. Juni beschrieb, lässt sich in 3 Evolutionsstufen aufteilen, wie Entwickler mit einem Coding-Agenten arbeiten.

Stufe 1: Du verwendest Claude wie Autocomplete. Schlauer als Copilot, aber du schreibst immer noch Code, überprüfst jede Zeile, hältst das Tool in der Hand. Der Agent assistiert. Du leitest jeden Schritt.

Stufe 2: Du promptest 5 oder 10 Claudes parallel. Übergibst Aufgaben, überprüfst Outputs, routest manuell zwischen ihnen. Du bist immer noch in der Schleife, nur ein beschäftigterer Verkehrsmanager statt ein Fahrer. Viele Leute, die denken, sie seien "fortgeschritten mit KI", sind hier und nehmen an, sie wären auf Stufe 3.

Stufe 3: Du bist überhaupt nicht in der Schleife. Du hast das System gebaut, das die Schleife für dich ausführt. Claude wartet nicht auf deine nächste Nachricht. Es arbeitet gegen Bedingungen, Verifikations-Gates und Retry-Logik ab, die du einmal definiert hast und die jetzt ohne dich läuft. Dein Job wechselte von "schreib den Prompt" zu "entwirf, was passiert, wenn der Agent scheitert, erfolgreich ist oder auf etwas trifft, was du nicht vorhergesehen hast."

Der Unterschied zwischen Stufe 2 und Stufe 3 liegt nicht an der Prompting-Fähigkeit. Er ist architektonisch. Du kommst nicht zu Stufe 3, indem du besser promptest. Du kommst dahin, indem du aufhörst zu promten und die Logik in etwas kodierst, das eigenständig läuft. Stell es dir als Tower-Defense-Problem vor: Hör auf, jede Position manuell zu verteidigen und fang an, Strukturen zu platzieren, die ohne dich halten. Prompting ist direkter Kampf. Loop Engineering ist das Bauen deiner Türme, bevor du die Basis verlässt.

Die Lücke Ist Jetzt Sichtbar

Der Post vom 7. Juni war kein Trend-Report. Es war eine Messung.

Wenn die besten Praktiker eines Bereichs öffentlich eine Änderung in ihrer eigenen Praxis ankündigen, kippt die Lücke zwischen Leuten, die es bereits machen, und allen anderen von unsichtbar zu sichtbar. Das ist passiert. Die Praxis lief schon monatelang. Was sich änderte: Die Anzeigetafel wurde öffentlich.

Karpathys AutoResearch-Projekt ist der klarste konkrete Beweis. Er führt 50 ML-Experimente über Nacht auf einer einzigen GPU aus. Der Agent modifiziert den Trainings-Code, führt ihn aus, liest die Ergebnisse, iteriert, keine menschlichen Entscheidungen in der Schleife. Er prägte "Loopy Era of AI" genau dafür, in einer No Priors Podcast-Episode, die 875K Views gegen einen Kanal-Durchschnitt von etwa 8.500 erreichte. Das ist ein 100x-Ausreißer bei einem Research-Level AI-Pod. Der Appetit, das zu verstehen, ist nicht mehr theoretisch.

Chernys eigene Zahl ist direkter: 100% seines persönlichen Codes für die 30 Tage vor Dezember 2025 wurden von Routinen geschrieben, die er aufgesetzt hatte, nicht durch direktes Prompting von Claude. Und Branchenberichte vom Juni 2026 setzen Claude Code bei fast 4% aller öffentlichen Commits auf GitHub an. 4% des gesamten öffentlichen GitHub-Graphen ist ein massiver Fußabdruck, und das passiert nicht durch manuelle Prompting-Sessions. Das sind laufende Schleifen. Zu diesem Zeitpunkt ist das Ausführen einzelner Prompts zum Ausliefern von Produktions-Code das "läuft auf meiner Maschine" der agentischen Entwicklung.

Der Grund, warum das Timing wichtiger ist als das Konzept, ist die Compound-Logik, und das ist der Teil, den die meisten Erklärer-Threads komplett überspringen. Ein Entwickler, der manuell promptet, wird besser im Prompting, mit schnelleren Iterationen und gezielteren Ergebnissen über die Zeit. Es ist lineare Verbesserung auf einer linearen Aufwandskurve, und es ist wirklich wertvoll. Ein Entwickler, der Schleifenlogik kodiert, operiert in einem strukturell anderen Modell. Jede Schleife, die er entwirft, läuft ohne ihn. Jede Verbesserung dieser Schleife gilt automatisch für jeden zukünftigen Lauf. Eine Trajektorie verbessert die Arbeit, die sie bereits machen. Die andere baut ein System, das diese Kategorie handhabt, während sie die nächste Schleife entwerfen. Diese 2 Trajektorien sehen am Anfang fast identisch aus. Du kannst sie in Woche 1 nicht unterscheiden. Der Unterschied wird über Wochen sichtbar, er verstärkt sich in Richtung der Person, die die Schleife gebaut hat, und er ist nicht durch schnelleres Prompting aufholbar. Genau das machte der Moment vom 7. Juni sichtbar: Die Anzeigetafel wurde öffentlich, und du kannst jetzt grob sagen, auf welcher Trajektorie du bist, indem du dir deinen Output des letzten Monats anschaust.

Die Schleife, Die Du Nicht Benannt Hast

Etwas, das mir auffiel, als der Steinberger-Post zu zirkulieren begann: Viele Entwickler, die zustimmend nickten, hatten keine Ahnung, dass sie bereits auf Stufe 3 für manche Aufgaben waren.

/goal ist bereits eine geschlossene Schleife. Du definierst eine Stopp-Bedingung. Claude iteriert, bis sie erfüllt ist oder einen harten Fehler trifft. Du triffst keine Entscheidungen zwischen Iterationen. Das Feature wurde in Claude Code v2.1.139 im Mai 2026 ausgeliefert, und die Entwickler, die es früh herausfanden, die das Ziel setzten, weggingen und zu Ergebnissen zurückkamen, machten technisch bereits Loop Engineering. Ich führte das aus, bevor /goal überhaupt existierte, nur mit langen Sessions mit detailliertem Kontext und der Hoffnung, dass Claude bei der Aufgabe blieb. Hatte es nur nicht benannt.

Die 3 Dinge, die "Ich verwendete /goal und ging weg" von einer echten Produktionsschleife trennen: eine Skill-Datei, die die Qualitätsregeln kodiert, ein Verifikationsschritt, der den Output gegen diese Regeln prüft, und ein Review-Agent, der das Ergebnis frisch sieht, bevor etwas ausgeliefert wird. Du hast vielleicht bereits 1 davon, ohne zu wissen, dass die anderen 2 existieren. Viele Entwickler haben eine CLAUDE.md. Nicht viele haben sie mit einer Verifikationsschicht verbunden. Und noch weniger haben den Review-Agent hinzugefügt, wo die Schleife die Dinge abfängt, die der Build-Agent als akzeptabel rationalisiert hat.

Die vollständige Anatomie, wie Anthropic in ihrem Verifikations-Video zeigt: eine SKILL.md, die die Non-Negotiables deines Projekts kodiert, ein Browser-Verifikationsschritt, der den gerenderten Output gegen diese Regeln prüft, und ein zweiter Agent, der überprüft, bevor etwas gemergt wird. Die CLAUDE.md, die du bereits geschrieben hast, ist das Fundament, /goal läuft dagegen, und der Review-Agent kontrolliert den Output, bevor er ausgeliefert wird. Verbinde diese 3 und du hast eine Schleife, die ohne dich im Raum läuft.

Für alle, die bereits den Wechsel vom Vibe-Coding zur Kodierung von Projektlogik in Prompts gemacht haben, ist die Schleife die nächste Schicht derselben Architektur. Der Instinkt, implizite Projektregeln explizit zu machen und aufzuhören, den Output im Nachhinein zu begutachten. Die Schleife führt diese Logik nur im autonomen Modus aus.

Nebenbemerkung, die kaum zusammenhängt, aber ich setze sie trotzdem hier hin. Als ich in den 90ern programmieren lernte, hatten wir einen gemeinsamen Bull DPS 7000 in der Schule. Alter Mainframe. 1 Kompilierungs-Slot zur Zeit, wer zuerst kommt, mahlt zuerst. Was ich herausfand, war ein dummes Shell-Script zu schreiben, das die Compiler-Queue alle 15 Sekunden abfragte und meinen Job sofort wieder einreichte, sobald ein Slot frei wurde. Mein Code wurde immer kompiliert. Meine Klassenkameraden aktualisierten manuell. Ich gab ihnen das viel später zu. Sorry Leute. Nicht wirklich sorry, ehrlich gesagt.

Der Instinkt, den Retry zu kodieren, anstatt es selbst von Hand zu machen, ist 30 Jahre alt. Das Branding ist neu.

Deine Erste Schleife Braucht Keine Flotte

Stufe 3 erfordert nicht 100 Agenten und eine Orchestrierungs-Schicht. Das ist die Version, die Karpathy für nächtliche ML-Experimente ausführt. Deine erste Schleife ist einfacher, und du kannst sie wahrscheinlich heute starten.

Die minimale Produktionsschleife:

/goal "Implementiere das Produktfilter-Feature aus der Spezifikation. Fertig, wenn die Test-Suite durchläuft und es keine TypeScript-Fehler gibt."

Das ist bereits Stufe 3 für diese Aufgabe. Claude läuft, bis die Bedingung erfüllt ist oder es einen Fehler trifft, den es nicht lösen kann. Du bist nicht dazwischen. Der Schlüssel ist das Wort "wenn" im Ziel, weil die Stopp-Bedingung etwas sein muss, das der Agent automatisch verifizieren kann, nicht etwas, das du anschauen und nachher beurteilen musst.

Eine Schleife ohne Verifikationsschicht ist nur automatisiertes Raten. Das Upgrade, das sie produktionstauglich macht:

Schritt 2. Füge eine SKILL.md mit den Non-Negotiables deines Projekts hinzu: deine tatsächlichen Regeln, für dein tatsächliches Projekt, geschrieben so, wie du einen neuen Entwickler am Tag 1 briefen würdest. Die Konventionen, die du durchsetzt, die Edge Cases, die immer zurückkommen, die Dinge, die du im Code Review 3 Tage später abfangen würdest, wenn sie niemand aufgeschrieben hätte. Je spezifischer die Regel, desto mehr verhält sich die Schleife wie jemand, der tatsächlich deine Docs gelesen hat, bevor er anfing.

Schritt 3. Füge einen Browser-Verifikationsschritt hinzu. Claude in Chrome oder die Chrome DevTools MCP prüft den gerenderten Output gegen deine Qualitätskriterien: Layout-Shifts, Core Web Vitals, visuelle Regressionen. Dinge, die nicht in Test-Suites auftauchen, aber in der Produktion. Anthropics Demo zeigt einen automatisch abgefangenen Layout-Shift, außerhalb des Umfangs der ursprünglichen Aufgabe, weil Core Web Vitals bereits in der SKILL.md standen. Das ist die Schleife, die Arbeit macht, um die du nicht explizit gebeten hast, weil du kodiert hast, wie "gut" aussieht, im Voraus.

Schritt 4. Füge einen /code-review Agent als zweiten Durchgang hinzu. Dieser Agent sieht den Output frisch, ohne die Geschichte, wie er gebaut wurde. Er fängt die rationalisierten Entscheidungen ab, die der Build-Agent an sich selbst vorbeigeschoben hat, was er tun wird, weil der Build-Agent den ganzen Lauf lang auf denselben Kontext gestarrt hat.

Fang mit Schritt 1 und 2 an, wenn du heute etwas laufen lassen willst. Füge 3 und 4 hinzu, wenn die Basis-Schleife stabil ist.

Ich denke, der Schritt, der die meisten Leute stolpern lässt, und vielleicht liege ich falsch, aber es passt zu jedem Schleifenfehler, den ich gesehen habe, ist die Stopp-Bedingung. Spezifisch: eine zu setzen, die nicht automatisch verifiziert werden kann. "Mach das UI poliert" ist keine Stopp-Bedingung. Es ist ein Gebet. "Kein Layout-Shift über 0,1 CLS" ist eine Stopp-Bedingung. Speicherpunkt vor der Boss-Tür, nicht danach. Setze das Gate, bevor die Schleife startet, oder du läufst den ganzen Dungeon nochmal. Das Gate muss entworfen werden, bevor du anfängst, nicht geprüft, wenn es fertig ist.

Eine Schleife ohne Verifikations-Gate spart keine Zeit. Sie automatisiert das Falschliegen.

Bevor irgendetwas davon konsistent funktioniert, muss das Gerüst darunter solide sein. Vage Spezifikation, keine Test-Abdeckung, Dependencies, die du geerbt, aber nicht wirklich verstanden hast (die Schleife wird selbstbewusst dagegen laufen und Müll ausliefern). Der 8-Schritt-Blueprint in Vibe Coding, For Real wurde genau dafür gebaut: von kaputtem Demo zu deployed App zu kommen, bevor du die Iteration an ein autonomes System übergibst. Die Schleife braucht etwas Echtes, gegen das sie laufen kann.

Und wenn du bereit bist, die Schleife auf externe Systeme zu erweitern (einen Deploy auslösen, einen Service-Check ausführen, eine API aufrufen), diese Schicht mit CLIs statt MCP-Connectors zu bauen verändert, wie debuggbar und zuverlässig diese Erweiterung in der Produktion wird.

Als Die Anzeigetafel Öffentlich Wurde

Ich wusste nicht, dass "Klär-das-selbst-Modus" einen Namen hatte. Wusste nicht, dass es mich auf Stufe 3 für manche Aufgaben setzte. Wusste nicht, dass die Bull DPS 7000-Ära und die Boris Cherny-Ära denselben Instinkt 30 Jahre auseinander ausführten.

Was der Moment vom 7. Juni tatsächlich war: nicht der Beginn des Loop Engineering für die Leute, die es bereits machten. Der Moment, als die Lücke zwischen Praktikern und allen anderen für beide Seiten sichtbar wurde. Cherny hatte seit Dezember 2025 100% seines Codes durch Routinen laufen lassen. Karpathy hatte monatelang nächtliche Experimente gestartet. Die Lücke war bereits da. Steinbergers Post machte die Anzeigetafel nur öffentlich.

Die Leute, die es bereits machten, lernten am 7. Juni nichts Neues. Die Leute, die es nicht machten, wissen jetzt, dass die Uhr läuft.

Die Compound-Rate ist real und sie wartet nicht. Jede Schleife, die du entwirfst, läuft ohne dich. Jede Verbesserung der Schleife gilt für jeden zukünftigen Lauf. Das ist eine strukturell andere Trajektorie als schneller im Prompting zu werden, und die Lücke zwischen den beiden wird schneller messbar, als die meisten Leute erwarten.

Auf welcher Stufe bist du gerade, und ist das die, auf der du bleiben willst?

---

Quellen

• Peter Steinberger (@steipete), X, 7. Juni 2026
• Addy Osmani, "Loop Engineering," addyosmani.com, 7. Juni 2026
• Andrej Karpathy, Skill Issue: Code Agents, AutoResearch, and the Loopy Era of AI, No Priors Podcast
• explainx.ai, "Loop Engineering: The Claude Code Guide," Juni 2026
• datasciencedojo.com, "Agentic Loops: From ReAct to Loop Engineering," Juni 2026
• Anthropic, How to get Claude Code to verify its own work, YouTube

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).