Loop-Engineering: Wie KI-Agenten selbständig weiterarbeiten

Ziel

Nach diesem Artikel wissen Sie, was Loop-Engineering ist, wie ein Loop aufgebaut ist und welche vier Grundtypen es gibt. Sie können einschätzen, wann sich ein Loop lohnt — und woran Loops in der Praxis scheitern.

Voraussetzungen

Sie haben schon einmal mit einem KI-Assistenten gearbeitet, etwa um sich Code erklären oder eine Funktion schreiben zu lassen. Mehr ist nicht nötig: Alle Begriffe rund um Agenten und Loops erklären wir hier von Grund auf.

Als durchgehendes Beispiel begleitet uns die Bohnenkiste, ein kleiner Kaffeeversand mit einem Web-Shop. Stellen Sie sich vor, Sie sind dort Junior-Entwickler und pflegen den Backend-Service.

Vom Prompt zur Schleife

Die vertraute Arbeitsweise mit einer KI ist ein Gespräch. Sie stellen eine Frage, Sie bekommen eine Antwort, Sie lesen sie, Sie stellen die nächste Frage. Zwischen zwei Antworten passiert nichts. Sie sind der Motor: Ohne Ihre nächste Eingabe steht alles still.

Ein Agent ist eine KI, die nicht nur antwortet, sondern handelt. Er liest Dateien, ändert Code, führt Befehle aus, startet Tests. Aber auch ein Agent hält an, sobald er seine Aufgabe einmal abgearbeitet hat — selbst dann, wenn das Ergebnis noch gar nicht taugt.

Loop-Engineering ist das Handwerk, einen Auftrag so zu formulieren, dass der Agent nach jedem Arbeitsschritt selbst erkennt, ob er weitermachen muss. „Loop“ ist das englische Wort für Schleife: Derselbe Ablauf wiederholt sich, bis eine Bedingung ihn beendet.

Der Unterschied in einem Satz: Beim Prompting bestimmen Sie den nächsten Schritt. Beim Loop-Engineering bestimmen Sie, woran der Agent erkennt, dass er fertig ist.

Hinweis: Loop-Engineering ist keine neue Technik, sondern eine andere Art, den Auftrag zu schneiden. Es funktioniert mit den Agenten-Werkzeugen, die Sie ohnehin schon benutzen.

Wie ein Loop funktioniert

Jeder Loop besteht aus fünf Bausteinen. Fehlt einer davon, wird aus der Schleife entweder ein Strohfeuer oder eine Endlosschleife.

Das Ziel — der Zustand, den der Agent herstellen soll. Nicht die Tätigkeit, sondern das Ergebnis.
Der Arbeitsschritt — was in einem Durchlauf passiert. Je kleiner der Schritt, desto besser prüfbar ist er.
Die Prüfung — woran der Agent erkennt, ob das Ziel erreicht ist. Am besten etwas, das sich ausführen lässt.
Die Entscheidungsregel — was bei „nicht erreicht“ passiert: noch einmal, anders herum, oder Übergabe an Sie.
Das Abbruchkriterium — die harte Grenze: Anzahl der Durchläufe, Zeit oder Kosten.

Ziele, die ein Agent prüfen kann

Ein Ziel taugt für einen Loop, wenn eine Maschine entscheiden kann, ob es erreicht ist.

Untauglich	Tauglich
„Mach den Checkout-Code besser.“	„`npm test` läuft ohne Fehler durch.“
„Räum die Warnungen auf.“	„`npm run lint` meldet keine Warnung mehr.“
„Schreib eine gute Doku.“	„Jede exportierte Funktion in `src/api/` hat einen Doc-Kommentar.“

Die rechte Spalte lässt sich ausführen. Der Agent muss nicht raten, ob er fertig ist — er kann es messen.

Die Prüfung ist der eigentliche Trick

Die häufigste Enttäuschung mit Loops entsteht dort, wo der Agent sich selbst prüft und sich dabei zu leicht durchwinkt. „Sieht gut aus“ ist keine Prüfung.

Gute Prüfungen sind Werkzeuge, die Sie ohnehin haben: die Testsuite, der Linter, der Compiler, ein Schema-Validator, ein HTTP-Statuscode. Wo es kein Werkzeug gibt, hilft ein Blick von außen — ein eigener Durchlauf, in dem der Agent ausdrücklich versucht, das eigene Ergebnis zu widerlegen.

Achtung: Ein Loop macht eine schlechte Prüfung nicht besser. Er wiederholt sie nur öfter.

Die vier Loop-Typen

Alle vier Typen benutzen dieselben fünf Bausteine. Sie unterscheiden sich nur darin, was den nächsten Durchlauf auslöst.

1. Schrittweise Loops

Sie geben eine Liste vor, der Agent arbeitet sie Punkt für Punkt ab und prüft nach jedem Punkt. Auslöser ist der nächste offene Punkt, Ende ist die leere Liste.

Beispiel Bohnenkiste: 23 Dateien sollen von var auf const und let umgestellt werden. Der Agent nimmt eine Datei, ändert sie, lässt die Tests laufen und geht zur nächsten.

Stärke: gut nachvollziehbar und leicht zu unterbrechen. Grenze: Sie müssen die Liste vorher kennen.

2. Ziel-Loops

Sie geben ein Kriterium vor, der Agent wählt seine Schritte selbst. Auslöser ist „Ziel noch nicht erreicht“, Ende ist das erfüllte Kriterium oder das aufgebrauchte Budget.

Beispiel: „Die Testabdeckung in src/orders/ liegt bei mindestens 80 Prozent. Prüfe mit npm test -- --coverage. Höchstens 8 Durchläufe.“

Stärke: Sie müssen den Weg nicht kennen. Grenze: ohne Budget wird es teuer.

3. Zeit-Loops

Der Takt kommt von der Uhr: stündlich, nächtlich, wöchentlich. Auslöser ist das Intervall, Ende gibt es keines — Sie schalten den Loop ab.

Beispiel: Jede Nacht prüft der Agent, ob Abhängigkeiten veraltet sind, aktualisiert die unkritischen und öffnet einen Pull Request, wenn die Tests grün bleiben.

Stärke: Routine verschwindet aus Ihrem Kopf. Grenze: Der Loop läuft auch dann, wenn es nichts zu tun gibt.

4. Proaktive Loops

Der Auslöser ist ein Ereignis: eine neue Fehlermeldung im Protokoll, ein neuer Pull Request, ein eingehendes Ticket. Der Agent entscheidet zuerst selbst, ob überhaupt etwas zu tun ist.

Beispiel: Sobald im Fehlerprotokoll dieselbe Ausnahme dreimal innerhalb einer Stunde auftaucht, sammelt der Agent die Details, sucht die verantwortliche Codestelle und legt ein Ticket mit Vorschlag an.

Stärke: reagiert schneller, als ein Mensch hinschauen könnte. Grenze: Der Loop braucht eine gute Regel dafür, wann nichts zu tun ist — sonst wird er zur Lärmquelle.

Hinweis: In der Praxis werden die Typen kombiniert. Ein Zeit-Loop stößt nachts einen Ziel-Loop an, der intern schrittweise arbeitet.

Loops in der Praxis

Nehmen wir die Bohnenkiste. Drei Aufgaben, drei passende Loops:

Der Testschulden-Loop (Ziel-Loop). Ziel: alle Tests grün. Prüfung: npm test. Grenze: 20 Durchläufe. Sie starten ihn, gehen Mittagessen und lesen danach das Protokoll.
Der Nacht-Loop (Zeit-Loop). Jede Nacht um drei: Abhängigkeiten prüfen, Sicherheitsupdates einspielen, Tests laufen lassen, Pull Request öffnen. Am Morgen finden Sie entweder einen fertigen Pull Request oder eine Notiz, warum keiner entstanden ist.
Der Log-Wächter (proaktiver Loop). Läuft ständig mit, meldet sich aber nur, wenn ein Fehlermuster auffällt.

Was sich dadurch für Sie ändert: Sie schreiben weniger Anweisungen und mehr Abnahmekriterien. Die wichtigste Fähigkeit ist nicht mehr, den nächsten Schritt zu formulieren, sondern zu beschreiben, wie ein gutes Ergebnis aussieht — und wie man das misst.

Woran Loops scheitern

Das Ziel ist nicht prüfbar. „Besser machen“ hat kein Ende. Der Agent hört irgendwann auf, ohne dass jemand sagen kann, ob es gereicht hat.
Die Prüfung ist zu weich. Der Agent bewertet sich selbst wohlwollend. Ohne ausführbare Prüfung wiederholt der Loop nur die eigene Selbsttäuschung.
Es fehlt eine Grenze. Ohne Obergrenze für Durchläufe, Zeit oder Kosten kann ein Loop stundenlang im Kreis laufen.
Der Schritt ist zu groß. Wenn ein Durchlauf zwanzig Dateien anfasst, sagt eine fehlgeschlagene Prüfung nicht, welche Änderung schuld war.
Der Kontext geht verloren. Nach vielen Durchläufen weiß der Agent nicht mehr, was er in Durchlauf drei entschieden hat, und dreht sich im Kreis.
Der Agent darf zu viel. Ohne Sandbox, eingeschränkte Rechte und die Möglichkeit zum Zurückrollen wird aus einem Fehler im Loop schnell ein Schaden in der Produktion.
Niemand schaut ins Protokoll. Ein Loop, dessen Ergebnisse nie jemand liest, erzeugt Arbeit statt sie abzunehmen.

Zusammenfassung

Loop-Engineering heißt: nicht den nächsten Schritt vorgeben, sondern Ziel, Prüfung und Grenze, damit der Agent selbst weiterarbeiten kann.
Ein Loop besteht immer aus fünf Bausteinen: Ziel, Arbeitsschritt, Prüfung, Entscheidungsregel, Abbruchkriterium.
Die vier Typen — schrittweise, Ziel, Zeit, proaktiv — unterscheiden sich nur im Auslöser des nächsten Durchlaufs.
Loops scheitern fast nie an der KI, sondern an unprüfbaren Zielen, weichen Prüfungen und fehlenden Grenzen.