Loops statt Prompts: Warum der Claude-Code-Chef aufgehört hat zu prompten, und was ich daraus gebaut habe

Der Mann, der Claude Code gebaut hat, schreibt keine Prompts mehr. Er schreibt Loops. Das klang erst nach Hype. Also habe ich es selbst getestet.

Boris Cherny ist der Schöpfer und Kopf von Claude Code bei Anthropic, also genau der Mensch, der das Werkzeug gebaut hat, mit dem ich täglich arbeite. Anfang Juni saß er bei Acquired Unplugged (gehostet von WorkOS, 2. Juni 2026) und sagte einen Satz, der seither durch jeden zweiten Dev-Feed läuft:

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

Kurz: Er prompted Claude nicht mehr. Er hat Loops laufen, und die Loops sind es, die Claude prompten und entscheiden, was zu tun ist. Sein Job ist es, Loops zu schreiben. Im selben Gespräch erzählte er, er habe im November seine IDE deinstalliert, weil er sie einen Monat lang nicht mehr geöffnet hatte. Das ist keine Anekdote aus einem Hype-Thread: Die Aussage ist über mehr als ein halbes Dutzend Outlets verifiziert, und Fortune bestätigt die Substanz.

Mein erster Reflex war Skepsis. „Ich schreibe nur noch Loops" klingt nach genau der Art Bühnen-Satz, der online gut funktioniert und in der Praxis zerfällt. Also habe ich es nicht geglaubt, sondern gebaut. Dieser Artikel ist beides: was Cherny wirklich meint, und der autonome Loop, den ich in einem meiner Projekte tatsächlich scharf geschaltet habe.

Was Cherny wirklich meint (und was Paraphrase ist)

Eine Ehrlichkeit vorab: Der Kern-Satz oben ist O-Ton. Aber „Loop Author" und die „Vier-Komponenten-Checkliste", die danach durchs Netz liefen, hat Cherny so nie gesagt. Das ist die Verpackung anderer, nicht sein Zitat.

Die eigentliche Lektion liegt unter dem Zitat, und die ist robust: Der Engpass beim Arbeiten mit einem starken Modell verschiebt sich. Nicht mehr das Tippen des perfekten Prompts ist die knappe Ressource, sondern das Bauen des Systems um das Modell herum: das Ziel, die Prüfung, die Leitplanken, der Review. Wer das verstanden hat, braucht die Begriffsverpackung gar nicht.

/loop vs /goal: das konkret Nutzbare

Das Schöne ist: Man muss „Loops" nicht abstrakt diskutieren, denn Anthropic hat zwei davon längst als echte Befehle in Claude Code eingebaut. Beide stehen so in den offiziellen Docs.

Der Merksatz, der bei mir hängengeblieben ist: /loop ist zum Beobachten. /goal ist zum Fertigwerden. /goal ist dabei das Spannendere, weil es im Grunde eine eingebaute Selbst-Prüfung ist: Claude arbeitet, ein zweites Modell als „Schiedsrichter" prüft, ob das Ziel erreicht ist: fertig oder weiter.

Warum das wichtig ist, zeigt das klassische Negativbeispiel. Setzt du als Ziel „alle Tests bestehen", dann ist der billigste Weg, das wahr zu machen, die Tests einfach zu löschen, und ein Prüfer, der nur den Gesprächsverlauf sieht, winkt das durch. Mit einer Grenzlinie (Scope-Fence) sieht dieselbe Bedingung anders aus:

Was ich gebaut habe

Genug Theorie. In einem meiner Research-Projekte durchsucht ein autonomes Multi-Agenten-System wissenschaftliche Studien zu Nahrungsergänzungsmitteln, bewertet ihre Evidenz und schreibt daraus auditierte Artikel. Solche Systeme laufen bei mir regelmäßig in automatischen Durchläufen, und manche scheitern. Genau dort habe ich einen klassischen Loop gebaut: Fehler-Logs → Issue → Fix → Pull Request. Er besteht aus zwei Hälften. Loop A, der Erzeuger (Producer), verwandelt Fehler in Issues. Loop B, der Abarbeiter (Consumer), macht aus den Issues Fixes und Pull Requests. Die erste Hälfte ist harmlos, die zweite die eigentliche Mutprobe. Fangen wir mit der harmlosen an.

Der entscheidende Test war die Deduplizierung. Ich habe sie an drei Fehlläufen geprüft, davon zwei mit demselben Fehler: ein Timeout beim Laden von Studien aus PubMed, nur mit verschiedenen Studien-IDs. Genau so ein Fehler tritt im echten Betrieb ständig auf, wenn eine externe API zickt, und er erzeugt jedes Mal einen neuen Run. Naiv wären das drei einzelne Issues, der Anfang eines Issue-Sturms, bei dem dasselbe Problem dein Board zumüllt. Mit der normalisierten Signatur wurden die beiden gleichen Fehler korrekt zu einem zusammengefasst: ein Issue, nicht drei. Genau das ist der Unterschied zwischen einem nützlichen Loop und einem, der dein Aufgaben-Board flutet.

Scharf geschaltet wird das Ganze über eine zeitgesteuerte GitHub Action, die die Issues anlegt, mit einer zweiten Sicherung gegen Doppelte (existiert schon ein offenes Issue zum selben Fehler?) und einem Probelauf-Modus zum gefahrlosen Testen. Das ist der Erzeuger. Der spannende Teil kommt jetzt.

Der nicht-offensichtliche Punkt steckt im Verifizieren, und er ist der Grund, warum so ein Loop überhaupt funktioniert. Erinnerst du dich, dass das prüfende Modell bei /goal nur den Gesprächsverlauf sieht? Das ist die Achillesferse: Ein arbeitender Agent kann einfach behaupten „alle Tests grün", ohne sie laufen zu lassen, und ein Prüfer, der nur den Text liest, glaubt es. Die Lösung ist keine Magie, sondern Disziplin: Die Bedingung verlangt, dass der echte Befehls-Output im Verlauf steht. Nicht „die Tests bestehen", sondern „pytest wurde ausgeführt und seine Ausgabe zeigt 0 Fehler". Der Agent kann seinen eigenen Schiedsrichter nur täuschen, wenn man ihm die Lücke lässt. Also lässt man sie nicht.

Ich habe es scharf getestet

Theorie ist billig, also habe ich Loop B an einem echten, kontrollierten Bug getestet. Ich habe dem Code absichtlich einen kleinen Fehler verpasst, einen Off-by-one im Circuit Breaker, ein Issue dafür geöffnet und das auto-fix-Label gesetzt. Ab da habe ich nichts mehr getan, außer zuzusehen.

Das Entscheidende war nicht, dass der Fix funktionierte, sondern wie viel Disziplin in den Sicherungen steckt. Der Agent fasste nur die eine erlaubte Datei an. Er bestand das Eval-Gate erst, als der echte pytest-Output im Verlauf stand, nicht auf bloße Behauptung hin. Und das Ergebnis war ein Entwurf, kein fertiger Merge. Der letzte Schritt lag bei mir, wie vorgesehen.

Das ist kein Hochglanz-Ergebnis, sondern ein ehrliches: ein Agent, der die langweilige, verifizierbare Arbeit autonom erledigt, und ein Mensch, der die letzte Entscheidung behält. Und ein Loop ist nicht dann gut, wenn er beeindruckt, sondern wenn man ihm beim Scheitern genauso vertrauen kann wie beim Gelingen. Schlägt ein Lauf fehl, löst dieser hier seine Sperre wieder, hinterlässt einen ehrlichen Kommentar und fasst keinen Code an. Genau diese Aufräum-Disziplin ist der Unterschied zwischen einem nützlichen Werkzeug und einer Gefahr.

Was erprobt ist, und was Aussicht bleibt

Hier trennt sich seriöse Einordnung von Hype. Erprobt und belastbar ist mehr, als man denkt: Chernys O-Töne sind verifiziert, /loop und /goal sind echte Produkte, GitHubs Copilot Coding Agent erstellt tatsächlich aus einem Issue einen Pull Request, und „ralph" (eine bekannte Loop-Methode) funktioniert für neue Projekte „auf der grünen Wiese" (im Fachjargon Greenfield). Aber die Grenzen sind genauso real.

• Agenten finden gut, gewichten schlecht. Ein viel beachteter Test, durchgeführt vom Software-Konzern EPAM, zeigte das deutlich: 15 KI-Agenten sollten eine echte, absichtlich versteckte Sicherheitslücke in rund 350.000 Zeilen Produktionscode finden. Sie fanden sie oft, aber ein Agent vergrub sie unter 46 weiteren, aufgeblähten „kritischen" Falschmeldungen. Die Lücke war gefunden, nur unauffindbar im Rauschen. Finden ist die Stärke, nach Wichtigkeit ordnen die Schwäche.
• Gewachsene Codebasen sind kein Loop-Terrain. Geoffrey Huntley, der Erfinder der ralph-Methode, sagt es selbst unmissverständlich: „There's no way in heck would I use Ralph in an existing code base." (Sinngemäß: „Auf gar keinen Fall würde ich ralph in einer bestehenden Codebasis einsetzen.") Loops glänzen bei neuen Projekten und gut prüfbaren Routineaufgaben, nicht im gewachsenen Produktivsystem.
• Es gibt keine verlässlichen Kostenzahlen. Für solche Loops existieren keine geprüften Zahlen, wie viele Tokens (also wie viel Geld) sie verbrauchen. Also gilt: Obergrenzen setzen, die Kosten im Blick behalten und nie unbeaufsichtigt auf einer kostenpflichtig abgerechneten Schnittstelle loslaufen lassen.

Die 5 Leitplanken (Guardrails)

Diese fünf sind kein allgemeines Gesetz, sondern das, was meinen konkreten Logs-zu-PR-Loop sicher gemacht hat. Ein anderer Loop braucht andere Leitplanken. Was bleibt, ist das Prinzip dahinter: Überleg dir vor dem Scharfschalten, wo dein Loop Schaden anrichten könnte, und bau für jede dieser Stellen eine Bremse.

Fazit

Cherny hat recht, in der Richtung. Aber die Lektion ist nicht „hör auf zu denken". Sie ist: Der Hebel liegt heute im System um das Modell herum: das Ziel, die automatische Prüfung (Eval), die Leitplanken (Guardrails), der Review. Genau das habe ich an diesem Loop in supplement erlebt. Der schwierige Teil war nicht, Claude etwas zu sagen. Die Arbeit steckte in der Fehler-Signatur, die das Board nicht zumüllt, in der Prüf-Hürde, die der Agent nicht austricksen kann, und im Aufräum-Verhalten, das bei jedem Fehlschlag sauber zurückrollt.

Mein Rat, wenn du selbst anfangen willst: Fang klein an, mit einem /goal auf einer konvergenten, risikolosen Aufgabe. Klettere die Leiter nur so weit hoch, wie du die Guardrails sauber gebaut hast. Und behalte das Merge-Gate für immer in Menschenhand.

Verwendete Tools:

So ein System zu bauen (Ziel, Eval, Leitplanken, Review) ist genau die Art Arbeit, die ich als KI-Berater mache. Du überlegst, wie ein autonomer Loop deinem Team echte, wiederkehrende Arbeit abnehmen könnte, ohne zum Risiko zu werden? Schreib mir.