Der „No-Prompt“-Workflow: Boris’ Loop-basierte Theorie für Entwickler-Produktivität

„Ich tippe keine Prompts mehr in Claude ein. Es ist die Schleife, die läuft, und es ist die Schleife, die entscheidet, was als Nächstes zu tun ist, indem sie Claude auffordert. Meine Aufgabe ist es, die Schleifen zu schreiben."

Dies sind die Worte, die Boris Cherny öffentlich gesprochen hat, der Leiter von Claude Code (vorgestellt in The New Stack und Artikeln von Addy Osmani).

Während viele von uns immer noch Prompts verfeinern, um die Genauigkeit zu verbessern, hat die Person, die das Tool baut, bereits den Schritt weg vom „Prompt-Schreiber" gemacht.

Wenn man darüber nachdenkt: Solange der „menschliche Durchgang" – vor einem Bildschirm sitzen, auf eine KI-Antwort warten, sie überprüfen und erneut Anweisungen geben – involviert ist, wird die Geschwindigkeitsbegrenzung durch die Geschwindigkeit der eigenen Hände bestimmt.

Loop Engineering ist die Idee, diesen menschlichen Durchgang aus der Struktur zu entfernen. Boris ist dem voll und ganz verpflichtet; er sagt, er habe seine IDE im November 2024 gelöscht und seitdem nicht wieder geöffnet. Er behauptet, dass fast alle seine Beiträge zu Claude Code im letzten Monat von Claude Code selbst geschrieben wurden (angeblich über 200 PRs).

Der Entwickler des Tools schreibt selbst keinen Code, sondern ist auf die Seite des „Beobachtens, ob die Schleife richtig läuft" gewechselt. Heute werde ich dies auf der Ebene technischer Spezifikationen aufschlüsseln, nicht nur als Stimmungsbild. Ich bin selbst dabei, mich auf die Schleifenseite zu bewegen, und ich spüre, wie meine Hände freier werden, je mehr ich mich verlagere.

Verwandter Artikel: Einführung in Vibe Coding: 6 Schritte für Menschen, die nicht coden können, um Apps mit Claude zu bauen. Die Ära der hauseigenen Produktion am Wochenende ist angebrochen

https://note.com/nobel/n/n8192ec07d689

Loop Engineering bedeutet einen Rollenwechsel

Mit anderen Worten, deine Position ändert sich. Bisher saß der Mensch in der Mitte eines Hin und Her, bei dem der Mensch Anweisungen gab, die KI antwortete und der Mensch überprüfte und korrigierte. Beim Loop-Design ist der Mensch dafür verantwortlich, den Kreislaufmechanismus (die Schleife) zu entwerfen, während das Ausprobieren und die Überprüfung der Ergebnisse auf die KI-Seite verlagert werden. Du wartest einfach auf eine Benachrichtigung, wenn es fertig ist.

Google's Addy Osmani schrieb dasselbe in einem Artikel mit dem Titel Loop Engineering und beschrieb es als „Ersetzen der Person, die Prompts eintippt, durch einen Mechanismus, der Prompts in ihrem Namen eintippt." Der Hebelpunkt hat sich von der Fähigkeit, gute Prompts zu schreiben, hin zur Frage verlagert, wie man ein System entwirft, das KI in die Lage versetzt, Prompts für dich zu schreiben. Das ist der Kern.

Allerdings warnt Addy selbst: „Es ist noch in der Anfangsphase, und ich bin etwas skeptisch. Man muss wirklich vorsichtig mit den Token-Kosten sein." Wir werden in der zweiten Hälfte auf diese Falle zurückkommen.

Die technischen Spezifikationen von /loop

Claude Code hat eine integrierte Fähigkeit namens /loop (ab Version v2.1.72). Dies ist der einfachste Einstiegspunkt für Loop Engineering. Da Online-Erklärungen oft mit Fehlern durchmischt sind, werde ich mich basierend auf der offiziellen Dokumentation für zeitgesteuerte Aufgaben auf die Kernpunkte konzentrieren.

Das Verhalten ändert sich je nachdem, was du übergibst:

• Sowohl Intervall als auch Prompt: /loop 5m check if the deployment is finished and let me know läuft in festen Abständen.
• Nur Prompt: /loop check if the CI passed and respond to review comments. Claude entscheidet selbst über das Intervall zwischen 1 Minute und 1 Stunde (selbstgesteuert).
• Nichts übergeben /loop: Der integrierte Wartungs-Prompt (Fortsetzen unerledigter Arbeit, Kümmern um PRs, leichte Aufräumarbeiten) oder eine von dir abgelegte loop.md-Datei wird ausgeführt.

Das Intervall kann am Anfang wie 30m oder am Ende wie every 2 hours platziert werden. Einheiten sind s / m / h / d. Du kannst auch andere Befehle übergeben, wie z.B. /loop 20m /review-pr 1234, um jedes Mal gespeicherte Fähigkeiten auszuführen. Zum Stoppen drückst du Esc, während du wartest (Aufgaben, die über natürlichsprachliche Anfragen erstellt wurden, stoppen nicht mit Esc; du musst bitten, sie zu löschen). Im selbstgesteuerten Modus beendet Claude die Aufgabe ohne die nächste Ausführung zu planen, wenn er feststellt, dass die Aufgabe wirklich abgeschlossen ist.

Der selbstgesteuerte Modus hat einen subtilen Vorteil: Er passt sich automatisch an, wartet kurz, wenn ein Build fast fertig ist, und länger, wenn nichts passiert. Manchmal wird ein Mechanismus namens „Monitor" verwendet, um Hintergrundausgaben zu streamen, anstatt zu polln, was oft günstiger ist als das Auslösen eines Prompts in festen Abständen.

Lass mich ein häufiges Missverständnis korrigieren, das in Quellartikeln gefunden wird. Es wird manchmal geschrieben, dass Aufgaben „automatisch 3 Tage nach der Erstellung gelöscht werden", aber genau genommen laufen wiederkehrende Aufgaben 7 Tage nach der Erstellung ab (sie werden ein letztes Mal ausgeführt und verschwinden). Außerdem ist /loop sitzungsgebunden und verschwindet, wenn du eine neue Unterhaltung beginnst. Wenn du sie schließt, kannst du mit --resume zurückkehren, wenn sie noch nicht abgelaufen ist.

Es gibt drei Planungsmethoden, die je nach Anwendungsfall ausgewählt werden:

• Cloud (Routines): Läuft auf der Anthropic-Seite. Es läuft auch, wenn dein Rechner zugeklappt ist. Mindestintervall ist 1 Stunde.
• Desktop Scheduled Tasks: Läuft auf deinem Rechner und kann auf lokale Dateien zugreifen.
• /loop: Nur solange die Sitzung geöffnet ist. Mindestens 1 Minute, praktisch zum Pollen während einer Sitzung.

Die Aufgabenteilung ist: Verwende Routines oder GitHub Actions für den dauerhaften Betrieb ohne menschliches Eingreifen und /loop für die Überwachung während einer Sitzung.

Standardaufgaben, bei denen Loops effektiv sind

Aufgaben in deiner Routine, bei denen du „prüfen und ein wenig korrigieren" wiederholst, sind generell für Loops geeignet. Es gibt drei häufige Muster:

• Bug Patrol: Erkenne Probleme oder Testfehler, lese die Ursache, behebe sie, führe Tests durch und erstelle in regelmäßigen Abständen einen PR.
• Continuous Review: Überwache Codeänderungen und weise immer wieder auf Problembereiche hin. Der Mensch entscheidet nur, ob er die Vorschläge annimmt.
• Document Sync: Erkenne Quelländerungen und halte die README oder Spezifikationen auf dem neuesten Stand.

Die Gemeinsamkeit dieser drei ist, dass das Ziel klar beurteilt werden kann, wie z.B. „Tests bestanden" oder „PR erstellt." Umgekehrt sind Aufgaben mit unklaren Kriterien nicht für Loops geeignet. Wenn der Endpunkt nicht klar ist, läuft es einfach weiter und verbraucht Tokens. Für deine erste Aufgabe ist es sicherer, eine zu wählen, bei der Erfolg oder Misserfolg auf einen Blick offensichtlich sind.

Verhindern von Ausbrechern und Vergesslichkeit mit „State Files"

Es gibt zwei Ängste bei Loops: denselben Fehler zu wiederholen und endlos Tokens zu verbrauchen.

Hier ist es effektiv, mit einer einzigen Zustandsdatei im Projekt zu entwerfen. Ob STATE.md oder todo.md, die KI liest und schreibt während jedes Schleifendurchlaufs das aktuelle Ziel / erledigte Punkte / nächste Schritte / festgefahrene Punkte. Selbst wenn die Sitzung unterbrochen wird, verliert die KI nicht den Überblick darüber, „wo sie ist und was sie anstrebt."

Dies ist nicht nur eine willkürliche Praxis; Anthropic selbst ist in Effective harnesses for long-running agents (November 2024) fast zum gleichen Schluss gekommen. Ihre Konfiguration verwendet zwei Rollen: einen Initialisierungsagenten zum Einrichten der Umgebung und einen Codierungsagenten, der pro Sitzung eine Funktion voranbringt. Der Fortschritt wird zwischen den Sitzungen über Git-Commits und eine claude-progress.txt-Datei übergeben. Für lange Jobs reicht die Komprimierung durch Zusammenfassung nicht aus. Die Richtlinie ist, einmal in eine strukturierte Datei zu schreiben und den Kontext neu aufzubauen.

In meinem eigenen Betrieb verwende ich tasks/state.md als Drehscheibe für den gemeinsamen Zustand, den sowohl die Brainstorming-Seite als auch die Implementierungsseite lesen, bevor sie handeln. Es ist dasselbe wie in dem Papier: „Vertraue nicht dem Kontext, vertraue der Datei." Es ist einfach, aber ohne dies verliert die Schleife in der zweiten Runde die Orientierung.

Die Ralph-Methode und Trennung von Maker und Checker

Es gibt eine extreme Version der Schleife, die „Ralph"-Methode. Popularisiert von Geoffrey Huntley, die ursprüngliche Quelle ist nur eine einfache Bash-Schleife:

Durch das endlose Füttern desselben Prompts und die Verwendung einer Markdown-Datei mit dem Plan als gemeinsamem Zustand auf der Festplatte, liest die KI ihn jedes Mal und entscheidet selbst, „was als Nächstes zu tun ist." Es sieht rücksichtslos aus, aber wegen der Zustandsdatei bewegt es sich mit jeder Runde vorwärts. Claude Code hat auch ein offizielles ralph-loop-Plugin, das denselben Prompt so lange erneut einreicht, bis eine Abschlussbedingung (completion promise) erfüllt ist. Es gibt die Einschränkung, dass die Erklärung des Abschlusses nur dann abgegeben werden darf, wenn er wirklich erreicht ist.

Wenn man jedoch alles einer einzigen KI überlässt, wird sie zu dem von ihr selbst geschriebenen Code „OK" sagen. Hier ist es effektiv, die KI, die erstellt (Maker), und die KI, die prüft (Checker), zu trennen. In meinem eigenen Betrieb trenne ich Implementierung und Verifizierung in verschiedene Agenten, und ich gebe der Verifizierungsseite nicht die Implementierungsabsicht – ich zeige nur die Anforderungen und lasse sie unabhängig bewerten. Ich habe auf die harte Tour gelernt, dass Selbstüberprüfungen in derselben Sitzung zwangsläufig nachsichtig sind.

Die Integration eines „reinen Review-Agenten mit einer anderen Perspektive" in die Schleife – das Entwerfen dieser mehrschichtigen Prüfung ist eine der Aufgaben, die der Mensch behalten sollte.

Gestaltungsautonomie in drei Stufen

Alles auf einmal anzuvertrauen, führt zu Unfällen. Es ist sicherer, das Maß an Beteiligung in Schichten zu unterteilen:

• L1 (Manuell): Menschen tippen Prompts und überprüfen jeden einzelnen. Die traditionelle Art.
• L2 (Halbautonome Schleife): Folge einer Zustandsdatei und beobachte eine bestimmte Reihe von Aufgaben bis zum Abschluss mit /loop.
• L3 (Resident): Laufe kontinuierlich über Routines oder GitHub Actions ohne menschliches Eingreifen.

Es ist realistisch, mit L2 zu beginnen. Führe eine Aufgabe mit /loop bis zum Abschluss aus und beobachte das Verhalten. Gehe zu L3 über, sobald du die Zuverlässigkeitsspanne siehst. In den ersten paar Malen habe ich die Logs auf einem Nebenbildschirm verfolgt, um zu sehen, „wo es eine falsche Entscheidung getroffen hat."

Fallstricke (Kennt man diese zuerst)

Da ich nur über die guten Seiten geschrieben habe, hier drei Punkte, an denen man hängen bleiben kann:

1. Token-Kosten: Loops verbrauchen umso mehr, je länger sie laufen. Das hat Addy betont; wenn das Intervall zu kurz eingestellt ist, kann es über Nacht ein hübsches Sümmchen kosten. Selbstgesteuert ist besser als feste Intervalle, da es wartet, wenn es sollte, und so Verschwendung reduziert.
2. Unumkehrbare Operationen: Der integrierte Wartungs-Prompt führt nur irreversible Aktionen wie Pushen oder Löschen innerhalb des „in der Unterhaltung bereits erlaubten Rahmens" durch. Wenn du deine eigenen Prompts schreibst, ist es sicherer, die Grenzen für destruktive Operationen selbst zu definieren.
3. Verschwindet in 7 Tagen: Wiederkehrende /loop-Aufgaben laufen 7 Tage nach der Erstellung ab. Wenn du sie länger laufen lassen möchtest, wechsle zu Routines oder Desktop-Aufgaben.

Hinweise für fortgeschrittene Benutzer

• /loop und /goal sind unterschiedlich. /loop läuft nach Intervall. Wenn du bis zum Erreichen einer Bedingung in jeder Runde weitermachen möchtest, verwende /goal. Wenn es in dem Moment reagieren soll, in dem ein Ereignis eintritt, verwende Push über Channels.
• Das Ablegen einer loop.md (.claude/loop.md oder ~/.claude/loop.md) ermöglicht es dir, den Standard-Prompt eines nackten /loop durch deinen eigenen zu ersetzen. Es ist nützlich für Routineaufgaben wie „reparieren, wenn der Release-Branch-CI rot ist."
• Bis zu 50 geplante Aufgaben pro Sitzung. Die Liste kannst du mit CronList sehen und nach ID mit CronDelete löschen.

Zusammenfassung

Bisher war die Zeit, die ich vor dem Bildschirm verbrachte, die obere Grenze des Fortschritts. Jetzt bringt eine Schleife, die eine Zustandsdatei liest, während ich schlafe, nach und nach ein Feature voran, und mein Morgen beginnt mit der Überprüfung dieses Fortschritts.

Bevor du den Inhalt (Prompt-Genauigkeit) verbesserst, gestalte die Art und Weise, wie es läuft (Trennung von Schleifen, Zustandsverwaltung und Verifizierung). Der Hebel hat sich dorthin verlagert – das ist der gemeinsame Punkt in den Geschichten von Boris, Addy und Anthropic's Harness. Ich glaube, es ist keine schwierige Theorie, sondern eine stetige Anhäufung einfacher Designs, wie die Entscheidung, wann man aufhört, bevor man die Schleife startet.

Nützliche Informationen, die nicht auf X geteilt werden können, werden im LINE OpenChat geteilt. Wenn du daran interessiert bist, Claude Code/Codex zu nutzen oder KI für X-Operationen einzusetzen, mach bitte mit.

https://t.co/9LOoUYvCbO