Loop Engineering – Vom Prompting zum Looping

Ich habe mich entschieden, diesen Artikel dem Thema zu widmen, wie du deinen eigenen programmierbaren Agenten erstellst, der die Arbeit für dich erledigt, damit du nicht jeden Morgen deinen Computer einschalten und ihm immer wieder die gleichen Befehle geben musst.

Er wird von selbst aufwachen, eigenständig Aufgaben finden, eigenständig Probleme identifizieren und die Ergebnisse auf deinem Schreibtisch zur Überprüfung speichern und präsentieren.

Vorwort

Die Idee für Loop kam nicht aus dem Nichts – in einer einzigen Woche im Juni 2026 äußerten drei Branchenexperten fast gleichzeitig denselben Gedanken: Es sei an der Zeit, mit der Entwicklung dieser Ebene zu beginnen.

Eine Woche später ordnete Andrew Ng dieses Gespräch in den größeren Kontext von „Building Products from 0 to 1" ein und lieferte so ein umfassenderes Bild.

Dieser Artikel beginnt mit dieser Geschichte und führt dich dann Schritt für Schritt durch den Aufbau eines minimalen, aber vollständigen Loops von Grund auf: 5 Schritte, 6 Teile, eine Tür, die „nein" sagt, und eine menschliche Tür – alles läuft auf deinem eigenen Rechner und ist für jedes Softwareprojekt wiederverwendbar.

Quelle: HuaShu Orange Book, Loop Engineering: Stop Asking Me What It Is (v260615, Juni 2026)

Die Woche, in der 3 Personen die Lunte zündeten

Juni 2026: Drei Personen, die sich nicht absprachen, sagten innerhalb weniger Tage fast dasselbe.

Peter Steinberger, der Entwickler von OpenClaw, postete auf X zwei Sätze, die 8,9 Millionen Aufrufe erzielten:

https://x.com/steipete/status/2063697162748260627

Dieser Beitrag war der eigentliche Startpunkt der Diskussion. Es war kein Manifest oder langer Essay, sondern nur zwei Zeilen, die etwas benannten, was die Leute bereits still und leise taten.

Boris Cherny: Ich gebe Claude keine Prompts mehr, ich habe Loops, die laufen. Sie sind es, die Claude prompten und herausfinden, was zu tun ist.

Addy Osmani: Loop Engineering bedeutet, sich selbst als die Person zu ersetzen, die den Agenten promptet. Du entwirfst stattdessen das System, das dies tut.

Die Praxis war dem Namen um Monate voraus. Jeder schrieb bereits Loops, niemand hatte dem Ganzen bisher einen Namen gegeben.

Loops sind also jetzt ein Schlüsselelement dafür, wie wir KI-Agenten befähigen, langfristig iterativ zu arbeiten, um Software zu erstellen.

Andrew Ng ordnete die drei Loops nach ihren Zeitskalen von innen nach außen: Der innerste Loop ist der schnellste, der äußerste Loop ist der langsamste. Außerdem kommt die Eingabe für den äußersten Loop aus der Ausgabe des innersten Loops:

Loop

Wer führt ihn aus

Zyklusdauer

Was er an die äußere Schicht ausgibt

Agentic Coding Loop

der Agent selbst

Sekunden - Minuten

eine lauffähige Version

Developer Feedback Loop

Mensch + Agent

Zehner Minuten - Stunden

eine klarere Produktvision und Spezifikation

External Feedback Loop

Benutzer + Team

Stunden - Wochen

echte Daten, die die Vision weiterentwickeln

Andrew Ng gab uns die Karte nach Zeit: drei Loops, die mit unterschiedlichen Geschwindigkeiten laufen. Addy Osmani zeichnete eine zweite Karte nach Abstraktionsebenen: Prompt -> Context -> Harness -> Loop.

Loop Engineering sitzt an der Spitze und fügt drei Verben hinzu, die der Harness nicht hat. Es läuft nach einem Timer, erzeugt Helfer und füttert sich selbst – die heutige Ausgabe wird zur morgigen Eingabe. Das letzte ist es, was es zu einem Loop macht, nicht die gleiche Aufgabe N-mal auszuführen.

Die wichtigste Erkenntnis: Derselbe Fehler kostet auf jeder Ebene einen anderen Betrag:

Ebene

Worum es ihr geht

Kernfrage

Prompt Eng.

einen Prompt schreiben

Was soll dem Modell gesagt werden?

Context Eng.

was im Fenster geladen ist

Was soll abgerufen, zusammengefasst, gelöscht werden?

Harness Eng.

einen einzelnen Durchlauf bewaffnen

Welche Tools, welche Aktionen, was gilt als erledigt?

Loop Eng.

Planung auf dem Harness

Wie bringt man es dazu, Runde um Runde von selbst zu laufen?

Ein Loop ist von Natur aus eine Maschine, die die „Anzahl der Durchläufe" groß macht. Jede Entscheidung von hier an – Evaluator, menschliche Tür, Token-Limit, Zustandsdatei – existiert, um die Distanz zwischen „Fehler passiert" und „jemand sieht ihn" zu verkürzen.

Was innerhalb eines Durchlaufs passiert:

„Loop" wird oft falsch als „sich im Kreis drehen" verstanden. Das ist es nicht. Jeder Durchlauf hat 5 konkrete Schritte. Entferne einen, und der Loop wird entweder nicht laufen – oder er läuft, ohne voranzukommen.

1. Verifikation ist der Schritt, der „nein" sagt.
2. Planung ist der Schritt, der diesen Durchlauf in den nächsten speist.

Genau das ist der Teil, der ihn zu einem Loop macht.

Übertragen auf das Projekt, das wir gleich bauen werden: ein Morgen-Triage-Loop für ein kleines Team:

Aktion

Was sie tut

Im TRIAGE-LOOP

Discovery

Herausfinden, was dieser Durchlauf tun soll

Ein Skill liest CI / Issues / aktuelle Commits

Handoff

Die Aufgabe delegieren und isolieren

Jeder Fund bekommt seinen eigenen Worktree

Verification

Einen anderen Agenten einschalten, der nein sagt

Ein zweiter Sub-Agent als Reviewer, der Tests und Skills prüft

Persistence

Den Zustand außerhalb des Gesprächs speichern

PR + Linear-Ticket + ./state/triage.md

Scheduling

Den Loop Durchlauf um Durchlauf laufen lassen

GitHub Actions Cron-Job um 06:00 Uhr

Jede der folgenden 5 Lektionen erweitert genau einen Schritt.

Fünf Lektionen = ein vollständiger Loop.

Und wir beginnen mit dem ersten: Discovery, denn wenn der Loop nicht entscheiden kann, was heute zu tun sich lohnt, ist alles Weitere irrelevant.

Lektion 1 Discovery: Schreibe eine SKILL.md für die Morgen-Triage

Skills, keine Textwand als Prompt.

Stell dir vor, es ist Montag, 6 Uhr morgens. Dein Laptop ist zu, und ein GitHub Action wacht auf und feuert claude --skill morning-triage: Was er liest, was er als handlungsrelevant beurteilt, wo er die Ergebnisse hinschreibt – all das lebt in der SKILL.md, die du gleich schreiben wirst.

Osmanis Kernaussage: Automatisierung sollte einen Skill auslösen – dokumentiertes, aktualisierbares Projektwissen, keine Textwand, die in einen Cron-Job eingefügt wurde. Der eingefügte Prompt verrottet dort nur, weil niemand jemals zurückgeht, um etwas zu aktualisieren, das tief in einem Zeitplan vergraben ist.

Deine Aufgabe für diese Lektion: Schreibe einen Skill unter .claude/skills/morning-triage/SKILL.md, der selbstständig drei Quellen liest (CI / Issues / Commits), selbstständig entscheidet, was sich zu tun lohnt, die Ergebnisse in ./state/triage.md schreibt – und einen expliziten Stop-Abschnitt hat, der klarstellt, was der Loop NICHT tun darf.

Hier ist der Startcode – ändere drei Dinge, und er gehört dir:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (Discovery-Eingaben — gegen QUELLEN austauschen, die DEIN Repo hat)
8- CI-Läufe, die seit dem letzten Lauf fehlgeschlagen sind      # gh run list --status failure
9- Issues, die in den letzten 24h eröffnet wurden               # gh issue list --search "created:>=…"
10- Commits, die seit gestern gemergt wurden                     # git log --since=yesterday
11- Die vorherige ./state/triage.md                              # die Übergabe "gestern → heute"
12
13## Judge  (die Obergrenze — lass den Loop wählen, gib ihm keine Liste)
14Für jeden Kandidaten entscheiden:
15- Ist es JETZT handlungsrelevant oder Rauschen?
16- Blockiert es einen Release? → Priorität = P0
17- Wird es bereits verfolgt? → überspringen
18Behalte nur, was HEUTE einen Worktree wert ist.
19
20## Write  (Persistenz — in Markdown ablegen, nicht im Chat)
21An ./state/triage.md anhängen:
22| fund | quelle | priorität | status |
23Datei committen, damit morgen darauf zugegriffen werden kann.
24
25## Handoff  (Vorbereitung für Lektion 2)
26Für jeden behaltenen Fund eine Aufgabenzeile ausgeben:
27  worktree=fix/<slug>
28  goal=<stop-condition>
29
30## Stop   (der EINZIGE nicht standardisierte Abschnitt — hier genau nachdenken)
31Niemals mergen. Niemals löschen.
32Alles, bei dem du dir unsicher bist → ./inbox/ für einen Menschen.
33KEIN PR.

Drei Abschnitte leisten hier die eigentliche Arbeit:

Read: Dies ist die Eingabe für Discovery – liste konkrete Quellen auf, bis hin zum tatsächlichen Befehl. Denk daran: „Lies den Kontext" ist keine Quelle, aber gh run list --status failure ist eine Quelle.

Judge: Dies ist die Obergrenze deines gesamten Loops. Der Loop entscheidet selbst über „handlungsrelevant vs. Rauschen" – er bekommt keine Liste von dir, denn wenn du ihm immer noch jeden Morgen eine Liste gibst, hast du zwar das Ausführen automatisiert, aber nicht das Auswählen. Und das Auswählen ist in der Regel der teurere Schritt. Egal wie gut deine Quellen sind, wenn dieser Abschnitt Müll auswählt, drehen sich die anderen vier Schritte um wertlose Arbeit.

Stop: Der einzige Teil dieser Datei, der nicht standardisiert ist. Der Loop wird alles tun, was der Skill sagt, und nur das, was der Skill sagt. Wenn du nicht „niemals mergen" schreibst – wird er eines Tages für dich mergen.

Schreibe die roten Linien auf: niemals mergen, niemals löschen, niemals auf main pushen, alles Unsichere geht in ./inbox/ für einen Menschen, nicht in einen PR.

Noch etwas Wissenswertes: Dieselbe Skill-Struktur funktioniert auch über die Morgen-Triage hinaus: Tausche den Read-Abschnitt gegen „die Zugriffsprotokolle von gestern + neue Issues + aktuelle Deploy-Version" aus, und es wird zu einem abendlichen Site-Health-Loop. Füge eine Zeile zu Judge hinzu – „Ist das eine Regression von gestern?" – und es ermöglicht einen Vergleich über mehrere Tage.

Die Krankheit, die diese Lektion verhindert – Blinder Loop:

Der häufigste „sieht aus wie ein Loop, ist aber keiner": Der Loop läuft, aber du weist die Arbeit immer noch jeden Morgen zu („Hey, sieh dir diese drei Bugs an"). Das ist Automatisierung der Ausführung, nicht Automatisierung der Entdeckung.

Symptom: Der Loop überrascht dich nie, weil er nur das tut, von dem du bereits wusstest, dass es getan werden muss.

Fix: Setze Judge in den Skill und lass ihn die heutige Arbeit selbst auswählen.

Bevor du fortfährst, beantworte diese drei Fragen:

1/ Wie viele Zeilen hat dein Stop-Abschnitt?

Wenn es nur „niemals mergen" ist – füge eine weitere hinzu: Was sollte dieser Loop sonst noch nie für dich tun? (niemals Issues schließen / niemals auf main pushen / niemals mehr als 3 Funde auf einmal bearbeiten...)

2/ Schreibe die erste Zeile von Read in einen Befehl um, der TATSÄCHLICH in DEINEM Projekt läuft.

3/ Wenn dieser Skill ein Jahr lang unverändert bleibt – was passiert?

Vergleiche nun: Was passiert mit einer Textwand, die ein Jahr lang in einem Cron-Job eingefügt ist?

Lektion 2 Handoff: Verteile die Arbeit und isoliere sie

Der Skill aus Lektion 1 ist gerade fertig gelaufen. ./state/triage.md enthält nun 5 handlungsrelevante Funde. Der natürlichste nächste Gedanke – feuere 5 Agenten gleichzeitig ab, mach schnell. Genau dieser Schritt ist der Weg zu einem Tangled Loop: Mehrere Agenten bearbeiten dieselben Dateien im selben Verzeichnis, und der Merge-Tag wird zur archäologischen Ausgrabung.

Das Gegenmittel ist eine Zeile: Jeder Fund bekommt seinen eigenen Worktree.

git worktree ist ein eingebauter Git-Mechanismus: Ein Repository, mehrere unabhängige Arbeitsverzeichnisse, jedes auf seinen eigenen Branch ausgecheckt. git worktree add ../fix-auth fix/auth öffnet einen vollständig isolierten Arbeitsbereich unter ../fix-auth. Builds, Bearbeitungen, Tests – nichts berührt irgendetwas anderes. Ein Worktree pro Fund = Agenten physisch getrennt.

Deine Aufgabe für diese Lektion: Schreibe ein Skript, das jeden Fund aus ./state/triage.md liest, einen isolierten Worktree pro Fund öffnet (benannt nach fix/<slug>), einen Agenten zum Entwurf einer Lösung darin schickt – und eine Parallelitätsgrenze setzt, damit es nicht unendlich viele erzeugt.

1# state/triage.md lesen, ein Worktree pro Fund
2# ÄNDERN: MAX_PARALLEL auf das, was dein Rechner / dein Budget verkraftet
3MAX_PARALLEL=3
4
5# ÄNDERN: Parsing an die tatsächlichen Spalten deiner triage.md anpassen
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # Die entscheidende Zeile: physische Isolation pro Agent
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # ÄNDERN: goal ist die Stopp-Bedingung, die der Evaluator aus Lektion 3 lesen wird
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "draft a fix for: $finding" &
19done
20
21wait   # Alle parallelen Agenten beenden lassen
22
23# Abschlussregel: Agenten mergen niemals automatisch — Worktrees warten
24# auf die menschliche Tür in Lektion 5
25echo "Alle Worktrees bereit zur Überprüfung:"
26git worktree list

Die Regeln, die hier zählen: Arbeite niemals auf main.

Main ist die Landebahn für die menschliche Überprüfung – nicht der Schreibtisch der Agenten. Alle Agenten arbeiten auf fix/*-Worktrees.

Begrenze die Parallelität: Unbegrenztes Erzeugen ist die Einladung zu einem Token-Desaster (Lektion 5 kommt darauf zurück). Wähle MAX_PARALLEL basierend auf einer ehrlichen Frage: nicht „wie viele kann mein Rechner ausführen", sondern „wie viele PRs kann ich tatsächlich überprüfen."

Merge ist eine menschliche Entscheidung: Stripe wickelt wöchentlich über 1.000 PRs durch solche Loops ab, und Menschen überprüfen immer noch jeden einzelnen. Der Mensch hat den Prozess nicht verlassen – er hat den Schreibtisch gewechselt: vom Schreiben von Code zum Überprüfen von Code.

Und ein Detail aus dem Stripe-Fall, das es wert ist, übernommen zu werden: Sie verwendeten kontraintuitiv ein kleineres Modell mit strengen deterministischen Toren anstelle des größten verfügbaren Modells.

Die Lektion: Ein strenges Verifikationstor schlägt rohe Modellleistung für Loop-Arbeit.

Die Krankheit, die diese Lektion verhindert – Tangled Loop:

Ein Einzel-Agenten-Loop sieht völlig gesund aus. Das Problem zeigt sich erst an dem Tag, an dem du parallelisierst – fünf Agenten laufen, fünf Diffs kollidieren in derselben Datei, der Merge wird zum Chaos.

Fix: Jede Aufgabe bekommt ihren eigenen Worktree, teile niemals ein Arbeitsverzeichnis zwischen Agenten.

Bevor du fortfährst, beantworte diese drei Fragen:

1/ Auf welche Zahl hast du MAX_PARALLEL gesetzt – und warum?

(Geld? Rechnerleistung? Oder „wie viele PRs kann ich ehrlich überprüfen"?)

2/ Wenn ein Worktree abstürzt – der Agent beendet sich, ohne etwas zu berühren –

was sollte die morgige Zustandsdatei darüber aufzeichnen?

3/ Stripe verwendete ein kleineres Modell + strenge deterministische Tore

anstelle des größten Modells. Was bedeutet diese Wahl für DEINEN Loop?

Lektion 3 Verification: Installiere eine Tür, die „nein" sagt (die schwerste Lektion)

Dies ist der schwierigste Schritt im Loop Engineering, und er verdient mehr Aufmerksamkeit als jede andere Lektion.

Der Anthropic-Ingenieur Prithvi Rajasekaran, der an langlebigen agentischen Anwendungen arbeitet, bemerkte etwas: Bitte einen Agenten, den Code zu bewerten, den er gerade geschrieben hat, und er wird sich fast immer selbst loben – selbst wenn ein Mensch auf den ersten Blick sieht, dass es mittelmäßig ist.

Das liegt nicht daran, dass das Modell dumm ist: Die eigenen Hausaufgaben zu benoten ist strukturell kaputt. Wenn der Code fertig ist, ist der Kontext des Agenten vollgestopft mit der Kette der Selbstrechtfertigung, warum er die Dinge so geschrieben hat. Wenn er seine eigene Ausgabe betrachtet, sieht er nicht das Ergebnis – er sieht das Argument für das Ergebnis.

Setze das in einen Loop, und es verstärkt sich zu einer Katastrophe: Jeder Durchlauf fragt „Ist das gut genug?" und wird von dem Agenten beantwortet, der es gerade geschrieben hat. Jeder Durchlauf nickt sich selbst zu. Je länger es läuft, desto weiter entfernt es sich von echter Qualität. Das ist der Nodding Loop – und es ist die teuerste Krankheit auf der Liste.

Rajasekarans Lösung, in seinen eigenen Worten:

„Einen eigenständigen Evaluator so zu tunen, dass er skeptisch ist, ist weitaus handhabbarer, als einen Generator dazu zu bringen, seine eigene Arbeit kritisch zu betrachten."

Dies ist ein strukturelles Problem, kein Formulierungsproblem. Du kannst einen Autor nicht bitten, aus seinem eigenen Kopf herauszutreten, aber du kannst einen anderen Agenten hinzuziehen, mit völlig anderen Anweisungen, der den Code von Null aus betrachtet – ohne angehängte Selbstrechtfertigungskette.

Die Analogie stammt von GANs: Ein Netzwerk baut auf, ein anderes greift an: Macher und Prüfer. Dieselbe alte Bankenregel: Die Person, die das Geld überweist, und die Person, die es genehmigt, müssen verschiedene Personen sein.

Deine Aufgabe für diese Lektion – schreibe zwei Dinge:

1. Einen Evaluator-System-Prompt unter .claude/agents/reviewer.md mit fünf Abschnitten: ROLLE + ANNAHME + PRÜFE + VERWENDE + URTEIL.
2. Ein /goal-Kommando, das die Stopp-Bedingung dieses Loops deklariert – beurteilt von einem separaten, frischen Modell, nicht vom Generator.

1# .claude/agents/reviewer.md  (3 Dinge ändern)
2ROLLE: Adversarialer Code-Reviewer.
3ANNAHME: Dieser Code ist KAPUTT, bis das Gegenteil bewiesen ist.
4LOBEN NICHT. Finde, was fehlschlägt.
5
6# ÄNDERN: PRÜFE nach den tatsächlichen Fehlermodi DEINES Projekts ordnen,
7# zuerst ausführbare Prüfungen
8PRÜFE, in dieser Reihenfolge:
9  1. Läuft es?  (ausführen, nicht lesen)
10  2. Tests: ausführen, echte Ausgabe einfügen.
11  3. Randfälle, die der Autor übersprungen hat.
12  4. Entspricht das Verhalten dem Ticket?
13
14# ÄNDERN: Welches MCP verwendet wird, hängt davon ab, was getestet wird —
15# Frontend → Playwright, API → curl/httpie
16VERWENDE Playwright MCP: Seite öffnen, klicken,
17Screenshot machen, DOM inspizieren.
18Beurteile das Verhalten, nicht die Absicht.
19
20URTEIL: BESTANDEN nur, wenn jede Prüfung hält.
21         Andernfalls ABGELEHNT + jeden Grund auflisten.

1# Stopp-Bedingung — beurteilt von einem frischen kleinen Modell, NICHT vom Generator
2# ÄNDERN: Gegen die tatsächliche überprüfbare Bedingung deines Funds austauschen
3/goal all tests in test/auth pass and the lint step is clean
4
5# Vorsicht: /goal und /loop sind NICHT dasselbe
6#   /loop = in Intervallen wiederholen (keine Stopp-Beurteilung — gefährlich)
7#   /goal = laufen, bis ein frisches Modell die Bedingung als wahr beurteilt

Zwei Agenten, idealerweise zwei Modelle: „Gleiches Modell, anderer Prompt" bewahrt oft dieselben blinden Flecken. Tausche auch das Modell aus, wenn du kannst.

Standardskepsis: Die Grundannahme des Evaluators ist ANNAHME KAPUTT – Vertrauen muss durch das Bestehen von Prüfungen verdient werden, nicht standardmäßig gewährt werden.

Beurteile das Verhalten, nicht die Absicht: „Dieses JSX sieht gut aus" und „Ich habe auf den Button geklickt, die Seite navigierte, hier ist der Screenshot" sind zwei verschiedene Universen. Der Evaluator muss handeln – die Tests ausführen, auf die Seite klicken, nicht den Code lesen und ein Bauchgefühl haben.

Mit Gründen ablehnen: Eine ABLEHNUNG ohne aufgeführte Gründe ist keine Ablehnung – der Generator hat keine Ahnung, was er reparieren soll.

Und der Säuretest: Hat dein Evaluator in den letzten 5+ Durchläufen tatsächlich etwas abgelehnt? Ein Loop, der bei Hunderten von Durchläufen noch nie „nein" gesagt hat, ist bei jeder realen Arbeitslast statistisch unmöglich. Es beweist also, dass der Evaluator nicht funktioniert.

Die Krankheit, die diese Lektion verhindert – Nodding Loop:

Der Loop läuft, der Agent schreibt Code, derselbe Agent sagt „sieht gut aus." Jeder Durchlauf genehmigt sich selbst, stapelt plausibel aussehende Fehler mit Maschinengeschwindigkeit. Lösung: diese gesamte Lektion: strukturelle Trennung + Standardskepsis + Beurteilung durch Handlung + eine Stopp-Bedingung durch Dritte.

Bevor du fortfährst, beantworte diese drei Fragen:

1/ Ist dein Evaluator dasselbe Modell mit einem anderen Prompt oder ein anderes Modell? Warum?

2/ Übersetze „beurteile das Verhalten, nicht die Absicht" in einen konkreten Satz

für dein Projekt: „Mein Evaluator liest keinen Code, er führt _____ aus und BESTEHT nur, wenn er _____ sieht"

3/ Wie wahrscheinlich ist es, dass ein „ungefähr richtiges" frisches Modell deine /goal-Bedingung fälschlicherweise als BESTANDEN bewertet?

Wenn dein schlimmster Fehlermodus X ist – füge jetzt eine Prüfung auf X zur Stopp-Bedingung hinzu

Lektion 4 Persistence: Sorge dafür, dass die heutige Arbeit bis morgen überlebt

Lektion 3 ist abgeschlossen. Dein Evaluator hat drei Funde beurteilt – zwei BESTANDEN, einer ABGELEHNT. Frage: Wo leben diese drei Urteile jetzt?

Wenn die Antwort „im Kontextfenster" ist – dann wacht der Loop morgen um 6 Uhr mit einem geleerten Kontext auf und erinnert sich an nichts. Er beginnt die Triage von vorne, stolpert über die unreparierte ABLEHNUNG von gestern, weist vielleicht einen weiteren Agenten zur erneuten Reparatur zu, übersieht sie vielleicht ganz, fällt vielleicht in dasselbe Loch.

Das ist der Amnesiac Loop – jeder Tag beginnt am selben Punkt.

Das Gegenmittel in einem Satz: Gedächtnis ist der auf die Festplatte geschriebene Zustand, nicht der Kontext. Eine Markdown-Datei, ein Linear-Board, eine Datenbank – sobald es aufgeschrieben ist, spielt es keine Rolle, wie gründlich der Agent vergisst.

Diese beiden werden ständig verwechselt, also merke dir den Unterschied:

KONTEXT = das Fenster, das der Agent in DIESEM Durchlauf sieht -> wird bei jeder Aktualisierung gelöscht.

GEDÄCHTNIS = der Zustand, der über Durchläufe und Tage hinweg bestehen bleibt -> auf die Festplatte geschrieben (Markdown / DB / Board).

Ein Loop überbrückt heute -> morgen nur durch GEDÄCHTNIS.

Deine Aufgabe für diese Lektion:

1. Erstelle ./state/triage.md mit mindestens 4 Spalten (Fund / Quelle / Priorität / Status) – der Skill aus Lektion 1 schreibt hinein, die Worktrees aus Lektion 2 lesen daraus.
2. Verkabeln einen Connector (MCP): Ein BESTANDEN-Urteil öffnet automatisch einen PR, ein ABGELEHNT-Urteil aktualisiert automatisch das Ticket.
3. Überprüfe, ob der morgige Loop den heutigen Zustand tatsächlich lesen kann.

1# ./state/triage.md  (das Gedächtnis des Loops — nach Bedarf ändern)
2
3| fund            | quelle       | priorität | status     |
4|-----------------|--------------|-----------|------------|
5| auth test flaky | CI #4821     | P0        | fixing     |
6| null deref      | issue 92     | P1        | PR open    |
7| stale dep       | commit a3f9c | P2        | inbox      |
8
9# Spalten nach Bedarf erweitern: last_seen, retry_count, assigned_to
10# Diese Datei MUSS in das Repo committet werden —
11# sonst kann der morgige Cloud-Runner sie nicht sehen

1// .mcp/connectors.json — den Loop mit der Außenwelt verbinden
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← MUSS false sein. Menschliche Tür = Lektion 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

Warum jede Spalte wichtig ist: Keine Quelle -> du kannst nicht überprüfen, woher ein Fund kam. Keine Priorität -> du kannst die Arbeit nicht ordnen. Kein Status -> morgen kann den Staffelstab nicht übernehmen.

Und die Überprüfung für diese Lektion ist die einzige, die du nicht vortäuschen kannst: Warte bis morgen. Wache auf, überprüfe – ist der Posteingang noch da? Haben unerledigte Funde ihren Status behalten? Hat der 6-Uhr-Lauf dort weitergemacht, wo gestern aufgehört wurde, anstatt neu zu beginnen? Das findest du heraus, indem du es ausführst, nicht indem du darüber nachdenkst.

Eine stille Disziplin, die mit der Persistenz einhergeht – lies immer ein Beispiel.

Sobald die Persistenz funktioniert, öffnet sich eine Falle: Der Loop verschickt PRs mit hoher Geschwindigkeit, du fühlst dich produktiv – und deine mentale Karte der Codebasis driftet still und leise aus dem Datum. Die Regel: Lies nicht alles (das würde den Zweck des Loops zunichtemachen), aber lies einen Beispiel-PR pro Tag und zwinge dich zu erklären, was der Loop geändert hat und warum.

In dem Moment, in dem du es nicht erklären kannst – ist deine Karte zurückgefallen. Das an einem ruhigen Morgen zu beheben, kostet zehn Minuten. Es während eines Produktionsvorfalls zu beheben, kostet viel mehr.

Die Krankheit, die diese Lektion verhindert – Amnesiac Loop:

Der Loop findet gute Arbeit, erledigt sie und vergisst dann, dass er sie erledigt hat – weil das Ergebnis nur in einem geleerten Kontext lebte. Im nächsten Durchlauf entdeckt er dieselbe Arbeit neu oder, schlimmer noch, macht sie erneut und überschreibt den ersten Versuch.

Symptom: Kein kumulativer Fortschritt, jeder Tag beginnt am selben Ort. Fix: Zustandsdatei auf der Festplatte.

Bevor du fortfährst, beantworte diese drei Fragen:

1/ Übersetze „Gedächtnis ≠ Kontext" in einen konkreten Satz

aus deinem eigenen Projekt: „Mein _____ ist Gedächtnis, mein _____ ist Kontext"

2/ Der morgige Loop wacht auf – welche SPALTE von state.md liest

er zuerst, um seinen ersten Schritt zu entscheiden? Hast du diese Spalte richtig benannt, oder hast du gerade eine Zeitbombe für ihn vergraben?

3/ Disziplin: Zu welcher Tageszeit wirst du deinen einen

Beispiel-PR lesen? Setze jetzt die Kalendererinnerung – das ist ein Vertrag mit dir selbst.

Lektion 5 Scheduling: Mach es real, mach es sicher, behalte eine Tür offen

Die Lektionen 1-4 sind installiert, aber der Loop stoppt immer noch in dem Moment, in dem du aufhörst, den Knopf zu drücken. Der letzte Schritt ist ein einziges Verb: Hänge ihn an einen Auslöser.

Aber der gefährlichste Teil dieser Lektion ist nicht, Cron falsch einzustellen. Es ist, Cron richtig einzustellen – denn dann läuft der Loop wirklich allein, und ein einziger Fehler kann ihn die ganze Nacht durchdrehen lassen, Helfer, die Helfer erzeugen, bis du zu einer Rechnung aufwachst, die du nicht wiedererkennst.

Also macht diese Lektion eigentlich drei Dinge: Hänge den Auslöser ein, setze die Begrenzungen, behalte eine menschliche Tür.

Zuerst – wähle deinen Planer:

1Cloud (GH Actions)   Desktop geplant   /loop (in CC)
2Läuft wo             Cloud             dein Rechner        dein Rechner
3Rechner an?          nicht nötig       nötig               nötig
4Sitzung offen?       nicht nötig       nicht nötig         nötig
5Min. Intervall       1 Stunde          1 Minute            1 Minute
6Sieht lokale Dateien? nein              ja                  ja

Die entscheidende Frage: Kann diese Arbeit deinen Laptop verlassen?

1"Überprüfe jede Minute meinen lokalen Dev-Server"
2   → muss lokal + /loop sein (Clouds 1-Stunden-Intervall kann ihn nicht erreichen)
3
4"Scanne GitHub Issues um 3 Uhr morgens und öffne PRs"
5   → muss Cloud sein (dein Laptop ist zu — der Loop kann
6     nicht darauf warten)

Und die heimtückischste Selbsttäuschung in der gesamten Praxis: Einen lokalen Timer als „läuft, während du schläfst" zu behandeln. Tut er nicht. Es ist „läuft ein paar zusätzliche Durchläufe, während ich noch da bin."

Deine Aufgabe für diese Lektion:

1. Schreibe .github/workflows/triage.yml mit einem Cron-Trigger, der die Morning-Triage-Skill ausführt.
2. Setze drei Limits: Budget pro Durchlauf, Tagesbudget, maximale Wiederholungen.
3. Beende den Workflow mit der Regel: PRs werden niemals automatisch gemergt, alles Unklare landet in ./inbox/.

1# .github/workflows/triage.yml  (ändere 3 Dinge)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # ändere: deine 06:00 Uhr in UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← Limit pro Durchlauf · ändere
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← Tageslimit · ändere
22          MAX_RETRIES: '3'          # ← Wiederholungslimit · ändere
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: PRs öffnen (NIEMALS automatisch mergen)
29        run: |
30          # PRs werden automatisch geöffnet. Mergen bleibt menschlich.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # es gibt hier absichtlich kein `gh pr merge`
35
36      - name: Unklares an den Posteingang weiterleiten
37        run: |
38          ls ./inbox/ && echo "Elemente warten auf menschliche Prüfung"

Die drei Regeln, die den Loop nach sechs Monaten am Leben erhalten:

Setze Limits, bevor du auslieferst: drei Ebenen - Timeout pro Durchlauf, Tagesbudget, maximale Wiederholungen - werden vor dem ersten autonomen Durchlauf festgelegt, nicht nach der ersten erschreckenden Rechnung. Ein Token-Limit geht nicht darum, Geld zu sparen. Es ist ein Schutzschalter, der offenes Risiko in begrenztes Risiko verwandelt. Ein Loop ohne Limits hat seine Ausgabenhoheit an seine eigenen Fehler delegiert.

Zur Einordnung: Uber hat die Ausgaben der Ingenieure auf 1.500 $ pro Person und Tool pro Monat gedeckelt, nachdem das KI-Budget in vier Monaten aufgebraucht war. Dein Limit pro Loop ist die granulare Version dieser Lektion.

Halte eine Tür offen: PRs werden nicht automatisch gemergt. Unklare Elemente landen im Posteingang. Du liest eine Stichprobe pro Tag. Die Tür ist nicht da, weil ein Mensch immer hindurchgehen wird, sondern weil die Existenz der Tür dich in einer Position hält, in der du es kannst. Schweiße jede Tür zu, und an dem Tag, an dem du hineinmusst, hast du den Schlüssel verloren.

Überprüfe, ob er tatsächlich aufwacht. Führe ihn mindestens 3 Runden lang aus (Trockenläufe zählen). Der häufigste Fehler: am Demotag blendend, bis Donnerstag tot. "Letzter Durchlauf war am Tag der Demo" ist die diagnostische Signatur eines manuellen Loops.

Funktioniert auch außerhalb von Claude Code - die Fähigkeiten sind nicht an einen Anbieter gebunden, sondern nur umbenannt:

1FÄHIGKEIT             Claude Code          Codex
2Zeitplanung           /loop · worker       Automations-Tab
3Ausführung bis        /goal                automation rerun + judge
4Bedingung
5Parallele Isolation   --worktree           background worktree
6Unter-Agenten         .claude/agents/      .codex/agents/
7Externe Verbindung    MCP + Plugins        MCP-Connector
8Explizite Skill       SKILL.md             $skill-name
9Läuft ohne Rechner    Cloud Routines       Cloud (geplant)

Die Frage war nie "welcher Anbieter". Sondern: "Sind alle sechs Fähigkeiten installiert?"

Die Krankheit, die diese Lektion verhindert - der manuelle Loop:

Vier Schritte wunderschön gebaut, kein Cron. Es ist kein Loop - es ist ein Skript, das du einmal ausgeführt und dann vergessen hast.

Lösung: Hänge einen Auslöser an, der nicht davon abhängt, dass du dich erinnerst.

Beantworte diese drei Fragen, bevor du auslieferst:

1/ Welche genauen Zahlen haben deine drei Limits?

Wenn ein Fehler die ganze Nacht läuft - welches Limit fängt den Sturz zuerst ab? Wenn keines es tun würde... Was sagt dir das?

2/ Wie sieht deine menschliche Tür aus?

(PR-Review / Posteingang / tägliche Stichprobe / wöchentlicher Abgleich?) Schreibe es auf = unterschreibe den Vertrag mit dir selbst.

3/ Die abschließende Frage: Wird dieser Loop dich in sechs Monaten stärker gemacht haben (Verständnis, Urteilsvermögen, Gespür für das System) - oder dich zum Verwalter einer Maschine gemacht haben, die du nicht lesen kannst? Was ist dein Plan, um das Zweite zu vermeiden?

Die 4 Schulden und der Ingenieur bleiben

Dein Loop ist gebaut: Er wacht auf, findet Arbeit, kritisiert sich selbst, erinnert sich und plant seinen eigenen morgigen Tag.

Während ein Loop läuft, häufen sich vier Dinge leise an - und ihre gemeinsame Eigenschaft ist, dass keines von ihnen einen Alarm auslöst.

1VERIFIKATIONSSCHULD     nicht zurückgewiesene Ausgabe stapelt sich
2VERSTÄNDNISVERFALL      die Codebasis wächst, deine mentale Landkarte nicht
3KOGNITIVE KAPITULATION  "Ich habe keine Lust mehr, genau zu prüfen"
4TOKEN-EXPLOSION         ein Fehler läuft die ganze Nacht → du siehst ihn als Rechnung

Sie nähren sich gegenseitig: ungeprüfte Ausgabe untergräbt dein Verständnis -> untergrabenes Verständnis lädt zur Kapitulation ein -> Kapitulation lässt den Loop länger laufen und mehr ausgeben -> was mehr ungeprüfte Ausgabe produziert.

Prüfe deinen frischen Loop vor seinem ersten Solo-Lauf gegen alle vier:

• Mein Evaluator lehnt tatsächlich ab - er ist keine Dekoration.
• Ich lese eine Stichprobe von PRs pro Tag und kann erklären, was sich geändert hat.
• Ich habe mir die Angewohnheit bewahrt, zu sagen "das ist falsch".
• Meine Limits wurden VOR dem ersten Lauf gesetzt, nicht nach der ersten Rechnung.

Und hier ist der Teil, der alles entscheidet:

Derselbe Loop, von zwei Personen gebaut, kann an entgegengesetzten Orten enden. Der eine nutzt ihn, um schneller zu arbeiten, während er trotzdem den Code liest und die Richtung vorgibt - der Loop verstärkt das Urteilsvermögen, das er bereits hat.

Der andere nutzt denselben Loop gezielt, um nie wieder etwas verstehen zu müssen - sechs Monate später ist der erste schärfer, und der zweite ist ein Verwalter für eine Maschine, die er nicht lesen kann.

Addy Osmani: "Baue den Loop, aber baue ihn wie jemand, der vorhat, der Ingenieur zu bleiben - nicht nur die Person, die auf Start drückt."

Loops machen die Generierung nahezu kostenlos, was knapp bleibt, ist das Urteilsvermögen: welcher Plan richtig ist, an welcher Stelle man aufhören muss, was läuft, aber im Kern falsch ist. Der Loop entwertet das Urteilsvermögen nicht - er streift alles ab, was nicht Urteilsvermögen ist, und lässt nur das übrig.

Ein Loop ist ein treuer Multiplikator:

Bringe Verständnis - er verstärkt Verständnis.

Bringe Faulheit - er verstärkt Faulheit.

Entscheide, was du verstärkt haben willst - bevor du es baust.

Bleib dran!

Viel Glück :)