Schluss mit manuellem Prompt-Schreiben: So verwandeln Sie KI-Agenten in eine autonome Fertigungsstraße

Der Leiter der Claude-Code-Entwicklung bei Anthropic, Boris Cherni, gab einmal zu, dass er keine Prompts mehr von Hand schreibt. Stattdessen führt er automatische Loops aus, die Aufgaben für Claude erstellen, es starten und das Ergebnis eigenständig verifizieren. Einen Prompt einmal zu schreiben ist kein Problem. Aber wenn Sie dieselben Anweisungen jeden Tag an einen KI-Assistenten übergeben – ob zur CI-Prüfung oder zum Sortieren von Bugs – dann erledigen Sie Routinearbeit.

Der Entwickler Kobus Greyling veröffentlichte ein Projekt namens loop-engineering auf GitHub, das einen anderen Ansatz vorschlägt. Hören Sie auf, Chat-Operator zu sein, und werden Sie zum Designer autonomer Systeme. Das Projekt hat über 10.000 Sterne gesammelt, und es gibt hier wirklich etwas zum Nachdenken.

Von einmaligen Sitzungen zu geschlossenen Schleifen

Das Hauptproblem bei typischen Interaktionen mit Coding-Agenten wie Claude Code, Grok oder Cursor liegt im Kontext. Sie öffnen einen Dialog, erklären die Projektstruktur, geben eine Aufgabe und warten auf das Ergebnis. Die Sitzung wird geschlossen – der Kontext geht verloren. Am nächsten Tag beginnt alles von vorne.

Das Loop-Engineering-Konzept schlägt vor, den Prozess in eine Endlosschleife zu schließen. Der Agent läuft nach Zeitplan, liest den Repository-Zustand aus einer speziellen Datei, arbeitet in einem isolierten Branch, führt Tests aus und aktualisiert Statusmeldungen.

flowchart LR
    A[Schedule / Automation] --> B[Triage Skill]
    B --> C[Read + Write STATE / Memory]
    C --> D[Isolated Worktree]
    D --> E[Implementer Sub-agent]
    E --> F[Verifier Sub-agent]
    F --> G[MCP / Git / Tickets]

Sie brauchen dafür keine komplexen Python-Frameworks zu schreiben. Die Loop-Architektur besteht aus mehreren verständlichen Elementen:

• Geplante Ausführung via Cron, GitHub Actions oder Systemd.
• Projektzustand in einer normalen Markdown-Datei STATE.md, die im Repository-Root liegt und alle Agent-Neustarts übersteht.
• Isolierte Git-Worktree-Branches, damit Agent-Änderungen die aktuelle Arbeitskopie nicht beeinträchtigen.
• Trennung der Agenten in Executor und Checker (Maker / Checker). Einer schreibt Code, der zweite führt Tests aus und prüft Linter.

Was sich im Repository befindet

Das Projekt besteht aus einer Sammlung von CLI-Tools, die auf npm veröffentlicht wurden, und einem Katalog vorgefertigter Szenarien. Alle Tools sind unter einem einzigen Paket zusammengefasst, sodass nichts geklont werden muss.

Sie können eine Vorlage mit einem einzigen Befehl in ein bestehendes Projekt deployen:

npx @cobusgreyling/loop init . --pattern daily-triage --tool grok

Nach der Initialisierung erstellt das Tool Skill-Dateien, eine State-Storage-Struktur und gibt den Bereitschaftsindex des Projekts aus – den Loop-Ready-Score.

Um die Gesundheit des resultierenden Systems zu überprüfen, verwenden Sie den Doctor:

npx @cobusgreyling/loop doctor .

Dieser Befehl findet Konfigurationsprobleme und gibt drei Hauptschritte zur Verbesserung aus. Zum Beispiel schlägt er vor, Token-Budget-Limits hinzuzufügen oder Pfade zu konfigurieren, die nicht bearbeitet werden dürfen.

Das Toolkit enthält außerdem Utilities loop-cost zur Schätzung der Token-Kosten, loop-sync zum Finden von Diskrepanzen zwischen der Loop-Beschreibung und der State-Datei sowie loop-worktree zum sicheren Erstellen separater Branches für jeden Fix-Versuch.

Sieben fertige Vorlagen

Das Repository enthält Vorlagen für häufige Entwicklungsaufgaben.

Jedes Pattern wird mit einer Aufschlüsselung der Token-Kosten und einem empfohlenen Implementierungsmodus beschrieben:

1. Daily Triage. Einmal täglich wird das Repository gescannt, Issues gesammelt und STATE.md aktualisiert.
2. PR Babysitter. Überwacht offene Pull Requests, prüft Test-Status und hinterlässt Hinweise für Autoren.
3. CI Sweeper. Fängt fehlgeschlagene CI-Builds ab und versucht, fehlschlagende Tests in einem separaten Branch zu beheben.
4. Dependency Sweeper. Aktualisiert abhängige Bibliotheken und verifiziert, dass das Projekt gebaut werden kann.
5. Changelog Drafter. Erstellt einen Entwurf für das Changelog vor einem neuen Release.
6. Post-Merge Cleanup. Entfernt veraltete Branches und temporäre Dateien nach einem Merge.
7. Issue Triage. Überprüft neue Tracker-Einreichungen und schlägt Labels oder erste Antworten vor.

Der Autor empfiehlt, Loops inkrementell zu implementieren. Führen Sie den Agenten zunächst im Read-Only-Modus (L1) aus, wo er nur Berichte erstellt. Wenn Sie von der Genauigkeit seiner Schlussfolgerungen überzeugt sind, können Sie zum Bestätigungsmodus (L2) wechseln, und erst dann übergeben Sie kleinere Routinen an die vollständige Autonomie (L3).

Die unschöne Seite der Autonomie

Kobus Greyling zerlegt ehrlich die Risiken autonomer Agenten. Wenn Sie einen Loop mit Sub-Agenten ohne Einschränkungen starten, wird Ihre LLM-API-Rechnung überraschend unangenehm sein. Wiederholte Anfragen in einer Endlosschleife können innerhalb weniger Stunden Hunderte von Dollar verbrennen.

Das zweite Risiko wird als Comprehension Debt bezeichnet. Wenn der Agent Patches selbst schreibt, Tests selbst ausführt und Code selbst in Main merged, verliert das Team schnell die Kontrolle über die Architektur. Das Projekt wird zur Blackbox.

Zusätzlich bleibt alle Verifizierung Ihre Verantwortung. Dem Agenten fehlt der gesunde Menschenverstand, und er wird versuchen, einen Test um jeden Preis zu schließen – selbst wenn es bedeutet, den Test selbst zu löschen.

Für wen es sich lohnt, es zu versuchen

Das Repository ist nützlich für Teams, die bereits aktiv Kommandozeilen-KI-Tools wie Claude Code oder Grok nutzen und nach einem Weg suchen, diese systematisch in CI/CD zu integrieren.

Beginnen Sie klein. Installieren Sie loop init, wählen Sie ein Szenario daily-triage, und lassen Sie den Agenten eine Woche lang nur tägliche Berichte an STATE.md schreiben. Das ist ein sicherer Weg, um zu verstehen, wie gut das Konzept zu Ihrem Projekt passt, ohne die Stabilität Ihrer Codebasis zu gefährden.