Loop-Design + Überprüfung
Prämisse. Ein LLM ist ein vorwärtsgerichtetes System: Prompt rein → Tokens raus, ohne eingebaute „Steuerung auf das Ziel hin“ über mehrere Schritte. Um es wie ein zielorientiertes System agieren zu lassen, wird eine Rückkopplungsschleife darum gebaut. Diese Skill hilft dir, diesen Loop korrekt zu schreiben und zu überprüfen, damit er nicht außer Kontrolle gerät.
Wann verwenden / nicht verwenden
Verwenden, wenn:
- Du eine sich wiederholende Aufgabe an einen Agenten übergeben willst, die immer wieder ausgeführt wird (schreiben→testen, testen→korrigieren, korrigieren→verifizieren…).
- Du bereits einen Loop hast und befürchtest, dass er sich aufschaukelt, schummelt oder eine falsche Antwort bis zum Ende ausführt.
Nicht verwenden für:
- Eine einmalige Aufgabe → einfach erledigen; keinen Loop drum bauen.
- Einen einfachen Timer / Poll →
/loopverwenden; kein Design nötig. - Wie die Loop-Architektur verdrahtet wird (Pipelines → DAGs, Langzeit-Wiederherstellung) → das ist die Mechanismusschicht; siehe
autonomous-loops/continuous-agent-loop. Diese Skill deckt nur ab „Ist das Ziel richtig und läuft der Loop nicht davon“ – sie wiederholt nicht den Mechanismus.
Rote-Linie-Prämisse: zwei Rückkopplungsebenen
| Ebene | Wem gehört sie | Was sie tut |
|---|---|---|
| Ausführung (niedrig) | Maschine / Agent | Misst „Wie weit vom buchstäblichen Ziel entfernt“ und arbeitet es auf null ab. Die Maschine ist hier stark. |
| Urteil (hoch) | Mensch | Entscheidet „Ist dieses Ziel selbst richtig, soll es sich ändern, soll es gestoppt werden.“ Die Maschine kann ihren eigenen Loop nicht verlassen, um das Ziel zu hinterfragen. |
Ein Thermostat kann rückmelden „Wie weit von 26 °C entfernt“, aber wenn du Fieber hast und 28 °C willst, kann er nicht beurteilen, ob 26 das richtige Ziel ist – er arbeitet einfach auf 26 hin. „Was heute eingestellt wird“ ist immer die Entscheidung des Menschen. Das Urteil / die Freigabe / den letzten Schalter an die Maschine zu übergeben = die Rückkopplung auf hoher Ebene entfernen = sie sprintet, schnell und hart, auf ein Ziel zu, das niemand hinterfragt hat → falsche Ausgabe.
Aktion 1 – Einen Loop schreiben (5 Schritte)
Schritt 0 – Erst einmal subtrahieren: Solltest du überhaupt einen bauen? (4-Bedingungen-Prüfung, jede Nicht-Erfüllung = Veto)
① Die Aufgabe wiederholt sich wöchentlich oder häufiger ② Die Verifikation kann automatisiert werden ③ Das Token-Budget kann es verkraften ④ Der Agent hat Werkzeuge, die tatsächlich laufen und das Ergebnis sehen
Wird eine nicht erfüllt → keinen Loop bauen; von Hand oder anders erledigen.
Was die meisten Menschen stoppt, ist nicht „Kann ich einen Loop schreiben“, sondern „Verdient mein Repository einen Loop?“ Ein Repository, das einen Loop verdient, hat eine Abgleichsbaseline (Goldstandard / Upstream-Gesamtsumme) + Tests + einen Lint-Guard. Ein Repository, das keinen Loop verdient, wird durch einen Loop nur seine Fehler verstärken.
Schritt 1 – Ein maschinenentscheidbares Ziel definieren (der schwierige Teil – der Loop steht oder fällt hiermit)
Der gesamte Loop lebt vom Vergleicher, der prüft: „Ist es schon fertig?“ Der Vergleicher kann nur arbeiten, wenn deine Abbruchbedingung von einer Maschine mit Ja/Nein beurteilt werden kann.
- Schlecht: Vage („Mach es gut“, „Schreib es schärfer“) → der Vergleicher kann nicht urteilen → entweder er kommt nie durch (bleibt in Wiederholungen stecken) oder er rät (besteht/scheitert zufällig).
- Gut: Entscheidbar („Alle 96 Unit-Tests grün UND ein Änderungsprotokoll wird erzeugt“, „Modul-02-Felder ausgefüllt, Pytest bestanden, Geschäftslogik unberührt“) → eine Prüfung klärt es; der Loop konvergiert sauber.
Fünf-Punkte-Zielrahmen:
- Das Fertigkeitskriterium ist maschinenüberprüfbar.
- Grenzbedingungen werden zusammen mit dem Fertigkeitskriterium definiert („Was es NICHT tun darf“) – Anti-Goodhart; fehlende Grenzen = Freibrief zum Schummeln.
- Es gibt einen Fehlerfall-Rückfall – Wiederholungsgrenze N + Eskalation an einen Menschen bei Überschreitung.
- Das Ziel ist mehrschichtig.
- Abgleich gegenüber Behauptung bevorzugen für das Fertigkeitskriterium – an externe Fakten anbinden (Goldstandard / Upstream-Gesamtsumme / finanzieller Abgleich / Plattform-Backoffice-Zahlen) bevor du deine eigenen Behauptungen verwendest. „Alle Tests bestanden“ kann umgangen werden (Behauptungen lockern, Mocks fälschen, Ausnahmen verschlucken); „Differenz gegenüber Referenz < 0,01“ nicht.
Selbstkontrolle: Lies das Ziel jemandem vor, der die Domäne nicht kennt – kann diese Person einen Befehl ausführen und sagen, ob es fertig ist? Wenn nicht, ist es nicht entscheidbar genug. Geh zurück.
Schritt 2 – Den Loop-Typ wählen
| Deine Aufgabe | Loop-Typ (kybernetisch) | Wie er anhält |
|---|---|---|
| Hat einen klaren „Fertig“-Test (einen Batch bis zur Fertigstellung schreiben / einen Batch Bilder verarbeiten) | Servo (/goal-artiger geschlossener Loop) | Hält an, wenn das Ziel erreicht ist |
| Kein Endpunkt, muss einen Zustand aufrechterhalten (Bestandswarnung / geplanter Gesundheitscheck) | Regler (/loop-artiger Thermostat) | Hält nie an; handelt nur bei Änderung (Totband unterdrückt Rauschen) |
| Periodisches Abtasten, Stoppen bei einer Bedingung (einen PR beobachten, bis CI grün ist) | Regler mit Exit | Hält an, wenn die Exit-Bedingung erfüllt ist |
| Muss „sicherstellen, dass etwas pünktlich passiert“ | Das Obige in /schedule einwickeln | Cron feuert es |
Faustregel: Klarer „Fertig“-Test → Servo; muss aufrechterhalten, kein Endpunkt → Regler; muss „pünktlich passieren“ → Regler in Schedule einwickeln.
Schritt 3 – Ein Skelett wählen
Wartungstyp (etwas Bestehendes betreuen) → dokumentengesteuerte Abarbeitung. Der Loop ist nicht „eine feste Prüfung auf einem Timer ausführen“, sondern „ein Dokument auf einem Timer lesen und nur dann etwas tun, wenn sich das Dokument geändert hat“. Das Dokument ist die Aufgabenwarteschlange + Zustandsmaschine + menschliche Schnittstelle. Drei Disziplinen: ① Die Problemspalte ist nur vom Menschen beschreibbar, die Ergebnisspalte nur vom Loop beschreibbar, der Zustand geht nur vorwärts und nie zurück; ② Der Exit-Code ist endgültig (wenn das Skript exit 1 sagt, gewinnt das Skript); ③ Der Zustand geht nur bis „wartet auf Verifikation“ vorwärts – die Zelle „erledigt“ wird nur von einem Menschen umgeschaltet. Der Loop ist der Arbeiter, nicht der Abnahmebeauftragte.
Neuentwicklungstyp (von Grund auf neu bauen) → Planen / Bauen / Beurteilen, drei Rollen.
| Rolle | Tut | Schlüssel |
|---|---|---|
| Planen | Das Ziel in ein Pflichtenheft + entscheidbare Abnahmebedingungen zerlegen | Abnahme muss skript-beurteilbar sein |
| Bauen | Nach Pflichtenheft schreiben | Darf die Abnahmebedingungen nicht ändern |
| Beurteilen | Abnahme unabhängig durchführen; bestanden → stoppen, nicht bestanden → mit Fehlergrund an Bauen zurückgeben | Unabhängig + deterministisch |
Drei eiserne Regeln (alles setzt auf den Beurteiler): ① Der Beurteiler muss unabhängig sein – nicht der gleiche Agent wie Bauen (seine eigenen Hausaufgaben benoten bläht immer auf); ② Deterministische Regeln – Pytest / Abgleichsdiff / Typprüfung / Diff, niemals „sieht gut aus“; ③ Bauen darf die Abnahmebedingungen nicht ändern, um zu bestehen. Drei fehlgeschlagene Wiederholungen → an einen Menschen eskalieren.
Schritt 4 – Dämpfung hinzufügen (gegen Oszillation / Davonlaufen)
Wiederholungsgrenze, harter Stopp, Mensch schaltet den letzten Schalter um = Dämpfung. Negative Rückkopplung ohne Dämpfung oszilliert (der Ralph-Wiggum-Loop: sich auf der Stelle drehen, Token verbrennen).
Schritt 5 – In drei Stufen ausrollen (nicht am ersten Tag vollautomatisch gehen)
① Einmal von Hand ausführen (zwingt dich, genau zu sagen, „wie der Beurteiler entscheidet“) → ② zu einer Skill / Claude Code Sub-Agenten verhärten (ein Haupt-Claude loopt, dispatcht Planen/Bauen/Beurteilen) → ③ an Cron hängen für Vollautomatisierung.
Aktion 2 – Einen Loop überprüfen (Checkliste = fünf Fehlermodi)
Den Loop gegen jede Zeile prüfen. Wird auch nur eine getroffen = dieser Loop wird danebengehen; zurückschicken. Diese fünf sind Negativerfahrung (Fallstricke) – wertvoller als positive Regeln.
| # | Fehlermodus (wie er bricht) | Überprüfungsfrage (Treffer = rot) | Antikörper |
|---|---|---|---|
| 1 | Ziel ist eine korrekte Floskel → dreht sich, verbrennt Geld | Kann die Exit-Bedingung maschinell mit Ja/Nein beurteilt werden? Oder ist es „gut managen / gut machen“? | Durch ein entscheidbares Ergebniskriterium ersetzen (Aktion 1·Schritt 1) |
| 2 | „Verifikation“ als „prüfen, ob es gut aussieht“ formuliert → Agent sagt selbstbewusst „passt“ und stoppt | Ist der Beurteiler der Angeklagte selbst? Beruht die Verifikation auf „sieht gut aus“ oder auf deterministischen Regeln? | Abgleich + Exit-Code-Regeln + unabhängiger Beurteiler |
| 3 | (Schlimmster) Sperrt nur auf „alle Tests bestanden“ → Agent löscht die Tests | Gibt es eine Grenze („Was es NICHT tun darf“)? Oder nur ein Fertigkeitskriterium? | Fertigkeitskriterium + Grenze zusammen (der Goodhart-Antikörper) |
| 4 | Verlässt sich darauf, dass der Agent während des Laufs nachfragt → das tut er nicht; er führt die falsche Antwort bis zum Ende aus | Gibt es einen Punkt, an dem „nur zur Laufzeit klären“? | Jede Klärung vorab erledigen; einmal vor dem Start festlegen |
| 5 | Aufgeblähte CLAUDE.md + veraltetes Gedächtnis → je schneller der Loop, desto mehr Fehler | Sind die Dokumente / das Gedächtnis, von denen er abhängt, aktuell? Wer pflegt sie? | Mehrschichtiges Gedächtnis + regelmäßiger Lint |
Plus drei rote Linien (Verletzung einer = nicht automatisch gehen dürfen):
- Entscheidungsgewalt beim Menschen behalten. Abnahme / die Zelle „erledigt“ wird von einem Menschen umgeschaltet; der Loop ist nicht der Abnahmebeauftragte.
- Verantwortung wird nicht übertragen. Alles, dessen Fehlschlagen du dir nicht leisten kannst (den falschen PR zusammenführen / das Falsche veröffentlichen / Geld falsch zuweisen) → Übergib die Autorität nicht automatisch.
- Kontraintuitive Warnung. Je mehr ein Loop „selbstverbessernd / eigene Regeln umschreibend“ ist, desto strengere menschliche Überprüfung braucht er (um zu sehen, in was er die Regeln umgeschrieben hat) – nicht lockerer. Die Maschine ist zu schnell, um im Nachhinein einzugreifen, also muss das menschliche Urteil vor der Handlung sitzen (ein hartes Tor), nicht als nachträglicher Patch.
Ausgearbeitetes Beispiel – Überprüfung eines „nächtlichen Grün-Halters“-Loops
Du willst einen Loop, der jede Nacht läuft und alle fehlschlagenden Tests korrigiert.
- Naives Ziel: „Alle Tests bestanden.“ → Schritt-1-Selbstkontrolle schlägt fehl: das ist der Köder für Fehlermodus #3.
- Entscheidbares Ziel (korrigiert): „Alle Tests grün UND keine Testdatei gelöscht oder abgeschwächt UND Coverage nicht gesenkt UND ein Änderungsprotokoll erzeugt.“ Grenze jetzt zusammen mit dem Fertigkeitskriterium definiert.
- Typ: Servo mit einer Wiederholungsgrenze von 3 (Schritt 2 + Schritt 4).
- Skelett: Planen/Bauen/Beurteilen – der Beurteiler ist der unabhängig laufende CI, niemals der korrigierende Agent (Schritt 3).
Jetzt die Überprüfungscheckliste durchlaufen, und sie fängt, was die naive Version übersehen hätte:
- Treffer #3 → das naive „Alle Tests bestanden“ lässt den Agenten einen fehlschlagenden Test löschen, um zu „gewinnen“. Korrigiert durch die Grenze „keine Testdatei gelöscht/abgeschwächt“.
- Treffer #2 → wenn der korrigierende Agent auch seine eigene Korrektur beurteilt hätte, würde er sich selbst bestehen lassen. Korrigiert durch „Beurteiler = unabhängiger CI, deterministisch“.
- Treffer #4 → wenn eine Korrektur mehrdeutig ist, wird der Agent um 2 Uhr morgens nicht anhalten, um nachzufragen; er wird eine Vermutung committen. Korrigiert durch Vorabklärung: mehrdeutige Korrekturen werden dem Menschen überlassen, nicht geraten.
- Rote Linie → der Loop öffnet einen PR, merged aber nicht automatisch; der Mensch schaltet den letzten Schalter um (Verantwortung wird nicht übertragen).
Der naive Loop und der überprüfte Loop unterscheiden sich durch vier Zeilen Einschränkung – und das ist der Unterschied zwischen „weckt dich mit einer gelöschten Testsuite“ und „weckt dich mit einem sauberen PR.“
Einzeiler zum Abschluss
Das Schwierige beim Schreiben eines Loops ist nicht „Kann ich einen Loop schreiben“, sondern ein Ziel zu definieren, das eine Maschine abgleichen kann – entscheidbar, begrenzt, auf Abgleich basierend. Der Regler muss deterministisch und extern sein; behalte das Urteil und den Standard beim Menschen; das System tendiert zur Entropie, also pflege es. Ein Loop belohnt nur jemanden, der bereits gründlich nachgedacht hat. Verlass dich darauf, dass er für dich denkt, und er wird fröhlich falsch denken, mit dir, im großen Stil.
Herkunft: Wieners zwei Ebenen der Rückkopplung (The Human Use of Human Beings, 1950) für die Aufteilung in Urteil/Ausführung und rote Linien; das Planen/Bauen/Beurteilen-Muster von Anatolis Loops explained und Addys Loop Engineering. Mechanismusschicht (wie die Loop-Architektur verdrahtet wird): siehe
autonomous-loops/continuous-agent-loop. Diese Skill implementiert den Mechanismus nicht neu; sie behandelt nur die Zieldefinition und das Verhindern von Davonlaufen.