Was ist Loop Engineering? Definition einfach erklärt

Was Loop Engineering bedeutet

Loop Engineering bezeichnet die Entwicklung des wiederholten Zyklus, den ein AI-Agent ausführt: Was ihn startet, worauf er zugreifen darf, wie seine Ausgabe geprüft wird und wodurch er beendet wird. Prompt Engineering gestaltet eine einzelne Nachricht an ein Modell. Loop Engineering gestaltet den Prozess, der Tausende Nachrichten sendet, während Sie schlafen. Die Arbeitseinheit verschiebt sich vom Prompt zur Schleife.

Kurz gesagt: Sie schreiben nicht mehr nur Anweisungen, sondern ein Steuersystem. Der Agent benötigt weiterhin gute Anweisungen. Sie werden jedoch zu einer Komponente innerhalb eines Zyklus, der nach einem Zeitplan ausgeführt wird, in einer isolierten Kopie Ihres Codes arbeitet, sein eigenes Ergebnis mit einem Test nachweist und beendet wird, sobald ein Budget aufgebraucht ist.

Warum der Begriff 2026 aufkam

Die Bezeichnung wird gerade öffentlich etabliert. Das GitHub-Repository cobusgreyling/loop-engineering erreichte innerhalb von zwei Monaten nach seinem ersten Erscheinen 9,600 Sterne (Stand: Juli 2026) unter dem Leitsatz „Keine Prompts mehr. Entwerfen Sie die Schleife. Erreichen Sie eine Bewertung.“ Es fasst den Wandel in sechs Bausteine: Scheduling, Worktrees, Skills, Plugins und Connectoren, Sub-Agents sowie dauerhaften Speicher außerhalb der Konversation.

Darin wird Boris Cherny zitiert, der bei Anthropic Claude Code leitet:

Ich erstelle keine Prompts mehr für Claude. Ich habe Schleifen laufen, die Prompts für Claude erstellen.

Ein zweites Repository, AI-Builder-Club/skills, liegt bei knapp 1,100 Sternen (Stand: Juli 2026) und benennt die beiden Rollen direkt: Ein „Codebase-Harness“ sorgt dafür, dass ein Repository für einen Agenten sicher zum Ausführen von Tests und für Deployments ist. Ein „Loop Engineer“ erstellt Workflows, die durch einen Trigger gestartet werden, die Aufgabe ausführen und ihre Erkenntnisse in eine gemeinsame Datei schreiben, damit die nächste Schleife sie lesen kann.

Keines der beiden Repositories hat diese Praxis erfunden. Wer bereits einen nächtlichen Build, einen Linter in Continuous Integration oder einen Cron-Job ausgeführt hat, der ein Ticket erstellt, kennt dieses Grundmuster. Neu ist, dass der Worker innerhalb der Schleife jetzt nicht deterministisch arbeitet. Dadurch ändern sich die Anforderungen an die umgebende Infrastruktur.

Die vier Bestandteile einer Schleife

Jede funktionierende Schleife besteht aus diesen vier Bestandteilen. Eine Schleife, bei der einer davon fehlt, weckt Sie um 3am.

• Trigger. Das Ereignis, das einen Lauf startet: ein Timer, ein Webhook, ein neuer Pull Request oder ein Alert.
• Begrenzung. Die Dateien, Zugangsdaten und Netzwerke, auf die der Agent während dieses Laufs zugreifen darf.
• Verifizierung. Eine Prüfung mit einem Exit-Code, der entscheidet, ob die Ausgabe des Laufs behalten oder verworfen wird.
• Budget. Die Begrenzung für Tokens, Zeit und Kosten, die einen Lauf unabhängig vom Erfolg beendet.

Lesen Sie diese vier Punkte erneut als Fragen. Damit erhalten Sie eine Designprüfung für jeden Agenten, den Sie unbeaufsichtigt weiterlaufen lassen möchten.

Trigger: Was den Agenten startet

Ein Timer ist der einfachste Trigger. Auf einem Linux-Server ist ein systemd-Timer dafür besser geeignet als cron. Er protokolliert die Ausführung, wiederholt sie nach Ihren Vorgaben und startet keine zweite Instanz einer Unit, die noch läuft. Diese letzte Eigenschaft verhindert den häufigsten Überschneidungsfehler in Agentenschleifen: Zwei Ausführungen bearbeiten denselben Branch.

Erstellen Sie die Unit unter /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Erstellen Sie den Timer unter /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers sollte eine Spalte NEXT mit einem Zeitpunkt in der Zukunft und eine Spalte LEFT mit einem Countdown anzeigen. Ein leeres Ergebnis bedeutet, dass der Timer nicht aktiviert ist. enable plant ihn ohne --now nur für den nächsten Bootvorgang ein. TimeoutStartSec=1800 ist wichtiger, als es zunächst scheint: Ein Agent, der bei der Eingabe wartet, hält die Unit sonst dauerhaft aktiv. Der Timer wird dann nie wieder ausgelöst. Lesen Sie eine Ausführung mit journalctl -u agent-loop.service -n 50 aus.

Wenn Sie die Schleife stattdessen über cron steuern, müssen Sie selbst eine Sperre gegen Überschneidungen einbauen. cron startet andernfalls problemlos eine zweite Instanz:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n wird mit Status 1 sofort beendet, wenn die Sperre bereits gehalten wird. Dadurch endet die zweite Ausführung unauffällig, statt mit der ersten zu konkurrieren. Dieselbe systemd-Konfiguration für Service und Timer gilt für jeden lang laufenden Job auf dem Server, unabhängig davon, ob es sich um einen Agenten handelt.

Abgrenzung: Jeder Lauf erhält eine eigene Kopie

Ein Agent, der Ihren Arbeitsbaum bearbeitet, kann nicht festgeschriebene Änderungen verlieren. Git worktrees lösen dieses Problem mit geringem Aufwand: Jeder Lauf erhält ein eigenes Verzeichnis und einen eigenen Branch. Alle worktrees verwenden denselben Object Store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list gibt für jeden Tree eine Zeile mit Pfad, Commit und Branch aus. Wenn der Lauf endet, löscht git worktree remove /srv/agent/work/triage-01 das Verzeichnis. git worktree prune entfernt Einträge, deren Verzeichnis nicht mehr vorhanden ist. Parallele Schleifen sind ab diesem Punkt sicher, weil zwei Agenten auf zwei Branches in zwei Verzeichnissen einander nicht überschreiben können.

Die Abgrenzung betrifft auch Zugangsdaten. Eine unbeaufsichtigte Schleife enthält langlebige Tokens. Jeder Lauf kann dazu führen, dass ein Token in ein Log, einen Commit oder einen Model Context gelangt. Beschränken Sie das Token auf das eine Repository, das die Schleife verwendet. Halten Sie es nach Möglichkeit aus der Umgebung fern, die die eigene Shell des Agenten sieht. Lesen Sie wie Sie Secrets von AI Agents fernhalten, bevor Sie einer Schleife Zugriff auf Produktionssysteme geben. Für eine stärkere Isolation können Sie die gesamte Schleife auf einer temporären VM ausführen, die Sie nach jedem Lauf löschen können. Auch das verwendete Tool legt einen Teil der Abgrenzung fest, bevor Sie die Schleife schreiben. Lesen Sie daher wie sich Coworks verwaltete Sandbox mit Claude Code auf Ihrem eigenen Rechner vergleicht, bevor Sie entscheiden, wie viel Isolation Sie selbst einrichten müssen.

Verifikation: Das Gate, das die Schleife sicher macht

Hier zeigt sich der Unterschied zwischen einer Schleife und einem Cronjob, der Eingaben simuliert. Die Ausgabe des Agents ist ein Vorschlag. Das Gate entscheidet.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail übernimmt in diesem Skript eine wichtige Aufgabe. Ohne -e wird ein fehlgeschlagenes git fetch ignoriert, und der Lauf wird mit einem veralteten origin/main fortgesetzt. Ohne -u wird ein Tippfehler in einem Variablennamen zu einer leeren Zeichenfolge aufgelöst. Die Bereinigung läuft dann mit dem falschen Pfad weiter, statt mit einer eindeutigen Fehlermeldung abzubrechen.

Der Block if ! npm test enthält das gesamte Konzept. Der Exit-Code einer bereits vertrauenswürdigen Prüfung, Ihrer Testsuite oder Ihres Typecheckers, entscheidet, ob der Branch gepusht oder gelöscht wird. Eine Schleife ohne Gate erzeugt Arbeit, für deren Prüfung niemand Zeit hat. Das ist schlechter als keine Arbeit. Eine Schleife mit Gate erzeugt einen Branch, der bereits dieselben Anforderungen erfüllt wie der Branch eines menschlichen Contributors. Ein erfolgreiches Gate sagt nichts darüber aus, wie viel Code der Agent dafür geändert hat. Deshalb sollte die Prüfung mit einer dauerhaften Anweisung wie der Regel für die kleinste funktionierende Änderung durch einen Agent kombiniert werden. So bleibt der Diff klein genug, um ihn kostengünstig zu prüfen.

Wählen Sie ein Gate, das Fehler zuverlässig erkennt. Eine Testsuite, die bei einem leeren Diff erfolgreich ist, bringt der Schleife bei, dass Nichtstun ein Erfolg ist. Repositories mit schwachen Tests erzeugen schwache Schleifen. Deshalb setzen beliebte Repositories „die Codebasis für Agents geeignet machen“ vor „die Schleife schreiben“. Wenn Sie wissen möchten, ob Ihre Testsuite tatsächlich eine Regression erkennen würde und nicht nur die betreffenden Zeilen ausführt, liefert Mutation Testing die passende Antwort. Ein Agent, der einen erneut ausführbaren Nachweisbericht zurückgibt, statt Sie zum Lesen seines Diffs aufzufordern, macht diese Antwort für Sie überprüfbar.

Budget: Was einen Lauf stoppt

Ein Agent, der endlos wiederholt, verursacht eine unbegrenzte Rechnung. Geben Sie jeder Schleife eine zeitliche Obergrenze, die durch TimeoutStartSec erzwungen wird, eine maximale Anzahl von Wiederholungen in Ihrem Skript und ein vom Provider-Konto durchgesetztes Ausgabenlimit. Protokollieren Sie anschließend die Kosten jedes Laufs. So erkennen Sie, dass eine Schleife aus dem vorgesehenen Rahmen läuft, bevor dies auf der Rechnung sichtbar wird. Kostenkontrolle für eine ständig laufende Agent-VM behandelt die Abrechnungsseite. Verwalten des Kontexts, den ein Agent zwischen Durchläufen mitführt behandelt den größten einzelnen Hebel für die Kosten pro Lauf. Eine Schleife, die alle 30 Minuten dasselbe Repository erneut einliest, verursacht diese Kosten ebenfalls alle 30 Minuten.

Die Kosten sind der Grund, warum Schleifen meist besser sind als eine einzige lange Sitzung. Ein Lauf, der frisch startet, eine klar begrenzte Aufgabe erledigt und beendet wird, hält seinen Kontext klein. Eine Sitzung, die acht Stunden geöffnet bleibt, enthält in ihrem Verlauf jeden früheren Fehler und berechnet bei jedem Durchlauf das gesamte Transkript erneut.

Die Muster, die angesagte Repositories festschreiben

Das Repository loop-engineering listet sieben Muster für den Produktionseinsatz auf. Sie sind eher als Menü denn als Manifest lesenswert. Tägliche Triage. Ein Pull-Request-Betreuer, der auf Review-Kommentare wartet und sie beantwortet. Ein Continuous-Integration-Bereinigungslauf, der fehlgeschlagene Builds übernimmt. Eine Bereinigung der Abhängigkeiten. Ein Entwurf für das Changelog. Aufräumen nach dem Merge. Triage von Issues.

Gemeinsam ist diesen Mustern eine eng umrissene Aufgabe mit einer eindeutig erkennbaren Prüfstelle. „Den fehlgeschlagenen Build reparieren“ hat eine Erfolgsbedingung, die die Maschine auswerten kann. „Die Codebasis verbessern“ hat das nicht und wird daher nie zu einer Schleife. Daraus wird ein unübersichtlicher Prozess mit einem Zeitplan.

Gemeinsam ist ihnen außerdem eine schriftliche Aufzeichnung. Beide Repositories verlagern den Status aus der Unterhaltung in Dateien im Repository: was ausgeführt wurde, was gefunden wurde und welche Entscheidung getroffen wurde. Diese Datei ist das Gedächtnis der Schleife. Deshalb kann eine zweite Schleife auf der Arbeit der ersten aufbauen, statt sie erneut zu ermitteln. Auf diese Weise können Sie einen Agenten auch nachträglich prüfen, da sein Kontext mit dem Ende des Laufs verloren geht. Die Live-Koordination erfolgt über einen separaten Kanal. Eine Claude-Code-Sitzung kann auf demselben Rechner Arbeit an eine andere übergeben, solange beide noch laufen. Nichts aus diesem Austausch bleibt jedoch über das Ende einer der beiden Sitzungen hinaus erhalten. Daher ist die Datei der Teil, den Sie später erneut lesen.

Wenn Schleifen scheitern

Die Fehler sind banal und treten in verschiedenen Teams immer wieder auf.

• Kein Gate. Die Ausgabe sammelt sich an, niemand prüft sie, das Vertrauen sinkt, und die Schleife wird deaktiviert.
• Überschneidungen. Zwei Läufe auf einem Branch oder zwei Agents in einem Arbeitsbaum erzeugen Konflikte, die der Agent anschließend zu beheben versucht.
• Unbemerkte Abweichungen. Die Schleife läuft weiterhin erfolgreich durch, weil die Prüfung zu schwach ist, um einen Fehler zu erkennen.
• Unbegrenzter Umfang. Ein Trigger, der in einem stark ausgelasteten Repository bei jedem Commit auslöst, wird innerhalb eines Tages zu einem Kostenproblem.

Für alle gilt dieselbe Lösung: Verkleinern Sie den Auftrag, schärfen Sie die Prüfung und protokollieren Sie den Lauf. Wenn Sie die Bedingung für einen erfolgreichen Durchlauf nicht in einem Satz beschreiben können, ist der Auftrag noch nicht für die Automatisierung geeignet.

Erste Schritte ohne die Fachbegriffe

Sie benötigen kein Framework. Ein kleiner, dauerhaft laufender Linux-Server, ein Git-Repository, dessen Testsuite bei Fehlern tatsächlich fehlschlägt, ein systemd-Timer und ein Shell-Skript mit einem if darin bilden bereits einen vollständigen Ablauf. Genau damit sollten die meisten beginnen, weil sich die Designfragen durch das Ausführen des Systems beantworten und nicht durch die Auswahl eines Tools. Sobald ein Ablauf stabil ist, lässt sich ein zweiter meist mit einem weiteren Timer und einem weiteren Worktree einrichten. Eine grundlegende Einrichtung finden Sie unter einen Coding-KI-Agenten auf einem VPS ausführen. Wenn der Agent selbst auf Hardware laufen soll, die Sie kontrollieren, lesen Sie die aktuellen Optionen für selbst gehostete KI-Agenten.

FAQ

Ist Loop Engineering etwas anderes als Prompt Engineering?

Prompt Engineering optimiert eine einzelne Nachricht: Formulierung, Beispiele und Ausgabeformat. Loop Engineering optimiert den Ablauf rund um diese Nachricht: den Trigger, der einen Lauf startet, die Sandbox, in der er ausgeführt wird, die Prüfung, die seine Ausgabe akzeptiert oder ablehnt, und das Budget, das den Lauf beendet. Innerhalb der Schleife benötigen Sie weiterhin einen guten Prompt. Der Prompt ist jedoch nicht mehr das, was Sie täglich anpassen, weil Gate und Trigger das Ergebnis stärker beeinflussen.

Benötige ich ein Framework, um eine Agent-Schleife zu erstellen?

Nein. Ein systemd-Timer, ein git worktree pro Lauf, ein Shell-Skript, das mit einem Testbefehl endet, und ein Ausgabenlimit für das Provider-Konto decken alle Bestandteile der Definition ab. Frameworks ergänzen Scheduling-Schnittstellen, Formate für gemeinsamen Speicher und Multi-Agent-Routing. Das ist nützlich, sobald Sie mehrere Schleifen ausführen. Für die erste Schleife sind sie jedoch nicht erforderlich.

Was ist ein Codebase-Harness?

Damit ist die Gesamtheit der Komponenten gemeint, mit denen ein Agent ohne anwesenden Menschen in einem Repository arbeiten kann: eine Einrichtung mit einem Befehl, nicht interaktiv ausgeführte Tests mit eindeutigem Fehlschlag, ein Linter sowie eine Möglichkeit, eine Änderung bereitzustellen oder als Vorschau anzuzeigen. Der Begriff stammt aus derselben Welle von Repositories aus dem Jahr 2026 wie Loop Engineering. Der praktische Test ist einfach: Wenn ein neuer menschlicher Mitwirkender nicht mit einem Befehl vom Klonen bis zu erfolgreichen Tests gelangt, kann ein Agent das ebenfalls nicht.

Wie verhindere ich, dass eine Agent-Schleife eine hohe Rechnung verursacht?

Begrenzen Sie sie an drei Stellen. Setzen Sie TimeoutStartSec für die systemd-Unit, damit ein hängender Lauf beendet wird. Begrenzen Sie die Anzahl der Wiederholungen im Skript, statt so lange zu wiederholen, bis der Lauf erfolgreich ist. Setzen Sie ein hartes Ausgabenlimit für das API-Konto. Das ist die einzige Obergrenze, die der Agent nicht durch Argumente umgehen kann. Protokollieren Sie anschließend die Kosten jedes Laufs. Wenn sich die Kosten einer Schleife verdoppeln, hat sich ihr Umfang meist unbemerkt vergrößert.

Welche Aufgaben eignen sich zuerst für eine Schleife?

Wählen Sie eine Aufgabe mit einer maschinenlesbaren Erfolgsbedingung und einem kleinen Schadensradius. Einen fehlgeschlagenen Build zu reparieren, eine Abhängigkeit zu aktualisieren und ein Changelog neu zu erzeugen, erfüllen diese Kriterien. Eine Testsuite oder ein Diff kann das Ergebnis nachweisen. Offene Aufgaben wie Refactoring oder Design eignen sich noch nicht, weil es nichts gibt, was das Gate prüfen kann. Eine Schleife ohne Gate ist eine teure Möglichkeit, Review-Rückstände zu erzeugen.