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

Der Name wird derzeit öffentlich festgelegt. Das GitHub-Repository cobusgreyling/loop-engineering erreichte innerhalb von zwei Monaten nach seinem ersten Auftreten 9,600 Sterne (Stand Juli 2026) und zeigte am 2026-10-27 etwa 11,600 Sterne. Darunter steht die Zeile „Hör auf zu prompten. Entwirf die Schleife. Erhalte eine Bewertung.“ Im Juli 2026 fasste die README die Änderung in sechs Bausteinen zusammen: Scheduling, Worktrees, Skills, Plugins und Connectors, Sub-Agents sowie dauerhaft außerhalb der Konversation gespeicherter Speicher. Die aktuelle README enthält diese Liste nicht mehr (geprüft am 2026-10-27), speichert den Zustand der Schleife aber weiterhin in einer Datei außerhalb der Konversation.

Das Repository nennt Boris Cherny, der bei Anthropic Claude Code leitet, als eine seiner Inspirationen. Seine vielfach zitierte Aussage lautet:

Ich prompt Claude nicht mehr. Ich habe Schleifen laufen, die Claude prompten.

Ein zweites Repository, AI-Builder-Club/skills, liegt bei fast 1,300 Sternen (Stand 2026-10-27) und benennt die beiden Rollen direkt: ein „Codebase-Harness“, das ein Repository für einen Agenten sicher zum Ausführen von Tests und Deployments macht, und ein „Loop Engineer“, der Workflows erstellt, 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 Muster. Neu ist, dass der Worker innerhalb der Schleife nun 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.

Auslöser: Was den Agent startet

Ein Timer ist der einfachste Auslöser. Auf einem Linux-Server ist ein systemd-Timer dafür besser geeignet als cron, weil er protokolliert, nach Ihren Vorgaben erneut versucht und keine zweite Kopie einer Unit startet, die noch läuft. Diese letzte Eigenschaft verhindert den häufigsten Überschneidungsfehler in Agent-Schleifen: zwei Läufe bearbeiten denselben Branch.

Richten Sie zuerst einen eigenen Benutzer für den Agent ein. Dieser Benutzer ist Teil der Abgrenzung. Er besitzt /srv/agent und nichts anderes:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Schreiben Sie die Unit anschließend nach /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

Und den Timer nach /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 NEXT-Spalte mit einer zukünftigen Uhrzeit und eine LEFT-Spalte mit einem Countdown anzeigen. Ein leeres Ergebnis bedeutet, dass der Timer nicht aktiviert ist, weil enable ohne --now nur für den nächsten Boot-Vorgang geplant wird. TimeoutStartSec=1800 ist wichtiger, als es zunächst scheint. Ein Type=oneshot-Dienst gilt als gestartet, bis sein Skript beendet wird. systemd deaktiviert das Start-Timeout für oneshot-Units standardmäßig. Ohne diese Zeile bleibt eine Einheit, die bei der Eingabe wartet, daher dauerhaft im Status „activating“ hängen. Jeder spätere Timer-Aufruf erkennt dann, dass sie noch läuft, und startet nichts. Mit dieser Zeile beendet systemd den Lauf nach 30 Minuten und markiert ihn als fehlgeschlagen. Wenn Sie die Unit später auf den Standardwert Type=simple ändern, deckt TimeoutStartSec den eigentlichen Lauf nicht mehr ab. Die Laufzeit wird dann durch RuntimeMaxSec= begrenzt. Mit journalctl -u agent-loop.service -n 50 können Sie einen Lauf auswerten.

Wenn Sie die Schleife stattdessen über cron starten, benötigen Sie selbst eine Sperre gegen Überschneidungen, weil cron problemlos eine zweite Kopie startet:

*/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 gehalten wird. Der zweite Lauf endet dadurch still, statt mit dem ersten Lauf zu konkurrieren. Dieselbe Einrichtung von systemd-Service und -Timer gilt für jeden lang laufenden Job auf dem Server, unabhängig davon, ob es sich um einen Agent handelt.

Abgrenzung: jeder Lauf erhält eine eigene Kopie

Ein Agent, der Ihren Arbeitsbaum bearbeitet, kann nicht committete Änderungen verlieren. Git worktrees lösen dieses Problem kostengünstig: Jeder Lauf erhält ein eigenes Verzeichnis und einen eigenen Branch. Dabei wird derselbe Object Store gemeinsam verwendet.

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, entfernt git worktree remove /srv/agent/work/triage-01 den Worktree, aber nur, wenn er sauber ist. Enthält der Tree nicht nachverfolgte Dateien, geänderte nachverfolgte Dateien oder Submodule, verweigert Git den Vorgang, bis Sie --force hinzufügen. Deshalb erzwingt das folgende Gate-Skript die Entfernung nur für den Pfad, der den Lauf verwirft. git worktree prune entfernt Einträge, deren Verzeichnis nicht mehr vorhanden ist. Parallele Schleifen sind ab diesem Punkt sicher, weil zwei Agents auf zwei Branches in zwei Verzeichnissen einander nicht überschreiben können.

Bei der Abgrenzung geht es auch um Zugangsdaten. Eine unbeaufsichtigte Schleife verwendet 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, auf das die Schleife zugreift. Halten Sie es nach Möglichkeit aus der Umgebung heraus, die die eigene Shell des Agents 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 wegwerfbaren VM ausführen, die Sie nach jedem Lauf zerstören können. Auch das verwendete Tool bestimmt bereits einen Teil dieser Abgrenzung. 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.

Verifizierung: das Gate, das die Schleife sicher macht

Das ist der Teil, der eine Schleife von einem Cronjob unterscheidet, der nur Befehle absetzt. 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 erfüllt in diesem Skript eine wichtige Funktion. Ohne -e wird ein fehlgeschlagenes git fetch ignoriert, und die Ausführung arbeitet mit einem veralteten origin/main weiter. Ohne -u wird ein Tippfehler in einem Variablennamen zu einer leeren Zeichenfolge erweitert. Die Bereinigung läuft dann mit dem falschen Pfad weiter, statt mit einer eindeutigen Fehlermeldung abzubrechen. Die letzte Zeile enthält absichtlich kein --force: Wenn die Ausführung nicht erfasste oder nicht committete Dateien im Arbeitsbaum hinterlassen hat, verweigert git deren Entfernung. -e beendet die Ausführung nach dem Push mit einem Fehler, statt die Arbeit, die niemand committet hat, stillschweigend zu löschen.

Der Block if ! npm test enthält die gesamte Idee. Der Exit-Code einer Prüfung, der Sie bereits vertrauen, also Ihrer Testsuite oder Ihres Typecheckers, entscheidet, ob der Branch gepusht oder gelöscht wird. Eine Schleife ohne Gate erzeugt Arbeit, für deren Review niemand Zeit hat. Das ist schlechter als überhaupt keine Arbeit. Eine Schleife mit Gate erzeugt einen Branch, der bereits dieselbe Hürde genommen hat wie ein Branch eines menschlichen Contributors. Ein erfolgreiches Gate sagt nichts darüber aus, wie viel Code der Agent dafür geändert hat. Deshalb lohnt es sich, die Prüfung mit einer dauerhaften Anweisung wie der Regel zu verbinden, die einen Agent dazu bringt, die kleinste funktionierende Änderung vorzunehmen. Dadurch bleibt der Diff klein genug, damit das Review wenig Aufwand verursacht.

Wählen Sie ein Gate, das Fehler ehrlich erkennt. Eine Testsuite, die bei einem leeren Diff erfolgreich ist, bringt der Schleife bei, dass Nichtstun ein Erfolg ist. Repositories mit schwachen Tests führen zu schwachen Schleifen. Deshalb setzen die derzeit gefragten Repositories „die Codebasis für Agents vorbereiten“ vor „die Schleife schreiben“. Wenn Sie wissen möchten, ob Ihre Testsuite tatsächlich eine Regression erkennen würde, statt die betreffenden Zeilen nur auszuführen, liefert Mutation Testing die passende Prüfung. Ein Agent, der einen erneut ausführbaren Belegbericht zurückgibt, statt Sie zum Lesen seines Diffs aufzufordern, macht dieses Ergebnis für Sie selbst ü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 die angesagten Repositories festschreiben

Das Repository zum Loop Engineering listet acht Produktionsmuster auf (Stand 2026-10-27). Diese Muster sollte man eher als Auswahlmenü denn als Manifest lesen. Tägliche Triage. Eine schlanke Schleife, die als GitHub Action läuft und keine Zustandsdatei speichert. Ein Pull-Request-Betreuer, der auf Review-Kommentare wartet und sie beantwortet. Ein Continuous-Integration-Sweeper, der fehlgeschlagene Builds übernimmt. Ein Dependency-Sweeper. Ein Changelog-Entwurf. Aufräumen nach dem Merge. Issue-Triage.

Allen gemeinsam ist eine klar abgegrenzte Aufgabe mit einer eindeutigen Prüfschranke. „Den fehlgeschlagenen Build reparieren“ hat eine Erfolgsbedingung, die die Maschine auslesen kann. „Die Codebasis verbessern“ hat keine solche Bedingung und wird daher nie zu einer Schleife. Es wird zu einem Durcheinander mit einem Zeitplan.

Allen gemeinsam ist außerdem ein schriftlicher Datensatz. Beide Repositories verlagern den Zustand aus der Konversation in Dateien im Repository: was ausgeführt wurde, was gefunden wurde und was entschieden wurde. Diese Datei ist der Speicher der Schleife. Sie ermöglicht es einer zweiten Schleife, auf der Arbeit der ersten aufzubauen, statt sie erneut zu ermitteln. Außerdem können Sie damit einen Agenten nachträglich prüfen, weil der Kontext des Modells verschwindet, sobald der Lauf endet. Die Live-Koordination erfolgt über einen separaten Kanal. Eine Claude-Code-Sitzung kann Arbeit an eine andere Sitzung auf demselben Rechner übergeben, solange beide noch laufen. Nichts aus diesem Austausch überlebt jedoch das Ende einer der beiden Sitzungen. Deshalb bleibt 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

Unterscheidet sich Schleifenentwicklung von Prompt-Engineering?

Prompt-Engineering optimiert eine einzelne Nachricht: Formulierung, Beispiele und Ausgabeformat. Schleifenentwicklung optimiert den Ablauf rund um diese Nachricht: den Auslöser, 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 ihn beendet. Innerhalb der Schleife benötigen Sie weiterhin einen guten Prompt. Der Prompt ist jedoch nicht mehr das Element, das Sie täglich anpassen, weil Gate und Auslöser 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 beim Anbieter decken alle Bestandteile der Definition ab. Frameworks ergänzen Scheduling-Schnittstellen, Formate für gemeinsam genutzten Speicher und das Routing zwischen mehreren Agents. Das ist nützlich, sobald Sie mehrere Schleifen betreiben. Für die erste Schleife sind sie jedoch keine Voraussetzung.

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 einzigen Befehl, Tests, die nicht interaktiv laufen und Fehler deutlich melden, ein Linter sowie eine Möglichkeit, eine Änderung bereitzustellen oder als Vorschau anzuzeigen. Der Begriff stammt aus derselben Welle von Repositories im Jahr 2026 wie die Schleifenentwicklung. Der praktische Test ist einfach: Wenn ein neuer menschlicher Beitragender nicht mit einem einzigen Befehl vom Clone bis zu erfolgreichen Tests gelangt, kann ein Agent das ebenfalls nicht.

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

Begrenzen Sie die Kosten an drei Stellen. Setzen Sie bei einer Type=oneshot-systemd-Unit wie der obigen TimeoutStartSec, damit ein hängender Lauf beendet wird. Bei einem Type=simple-Dienst ist RuntimeMaxSec das entsprechende Gegenstück. Begrenzen Sie Wiederholungsversuche im Skript, statt so lange zu wiederholen, bis der Vorgang erfolgreich ist. Setzen Sie außerdem ein hartes Ausgabenlimit für das API-Konto. Das ist die einzige Obergrenze, die der Agent nicht durch Argumentation umgehen kann. Protokollieren Sie anschließend die Kosten jedes Laufs. Wenn sich die Kosten einer Schleife verdoppeln, ist ihr Umfang meist unbemerkt gewachsen.

Welche Jobs eignen sich zuerst für eine Schleife?

Wählen Sie einen Job mit einer maschinenlesbaren Erfolgsbedingung und einem kleinen Schadensradius. Das Beheben eines fehlgeschlagenen Builds, das Aktualisieren einer Abhängigkeit und das erneute Erzeugen eines Changelogs sind dafür geeignet, weil eine Testsuite oder ein Diff das Ergebnis nachweisen kann. Offene Aufgaben wie Refactorings oder Designarbeiten eignen sich zunächst nicht, weil es für das Gate nichts zu prüfen gibt. Eine Schleife ohne Gate ist eine teure Möglichkeit, zusätzlichen Prüfaufwand zu erzeugen.