LOOP ENGINEERING: DER 20-SCHRITTE-WEG VOM PROMPTER ZUM SYSTEMDESIGNER

Im Juni 2026 kamen innerhalb einer einzigen Woche drei Personen unabhängig voneinander auf dieselbe Idee.

Peter Steinberger, der Entwickler von OpenClaw, erklärte öffentlich, dass man aufhören sollte, Coding-Agenten zu prompten, und stattdessen die Loops entwerfen sollte, die sie prompten. Fast zur gleichen Zeit sagte Boris Cherny, der Leiter von Claude Code bei Anthropic, dass er Claude nicht mehr direkt prompter, sondern Loops laufen hat, die Claude prompten und herausfinden, was zu tun ist, und dass seine eigentliche Aufgabe darin besteht, Loops zu schreiben. Wenige Tage später schrieb Addy Osmani, ein Ingenieur bei Google, den Begriff auf und gab ihm einen Namen: Loop Engineering.

Keiner von ihnen hat die Praxis aus dem Nichts erfunden. Sie haben etwas benannt, das bereits geschah, weil die darunterliegenden Werkzeuge leise eine Schwelle überschritten hatten. Coding-Agenten waren zuverlässig genug geworden, um eine reale Aufgabe unbeaufsichtigt zu erledigen. Die Terminplanung war billig genug geworden, dass es nicht mehr verschwenderisch wirkte, eine Aufgabe wiederholt, per Timer, auszuführen. Die Kosten für einen einzelnen Agenten-Durchlauf waren so weit gesunken, dass es günstiger war, etwas fünfmal zu versuchen, als einmal gründlich darüber nachzudenken.

Diese Schwelle ist der Grund, warum dieser Fahrplan existiert. Prompting war die Fähigkeit, als ein Mensch am Schreibtisch sitzen und einen Agenten Schritt für Schritt anleiten musste. Loop Engineering ist die Fähigkeit jetzt, wo der Agent ein Ziel bekommen und losgeschickt werden kann, um es zu erledigen. Dies ist der vollständige 20-Schritte-Weg von einem zum anderen, in der richtigen Reihenfolge, denn die Reihenfolge ist wichtiger als jeder einzelne Schritt.

Hier ist, warum die Reihenfolge speziell wichtig ist, bevor wir zu den Schritten selbst kommen. Loop Engineering ist keine einzelne Fähigkeit, die man entweder hat oder nicht. Es ist ein Stapel, bei dem jede Schicht von der Stabilität der darunterliegenden abhängt. Einen Scheduling-Trigger zu bauen, Schritt 14, bevor man eine echte Abbruchbedingung hat, Schritt 10, bedeutet nur, dass man ein System automatisiert hat, das jetzt unbeaufsichtigt Geld verschwenden kann, anstatt nur, während man zusieht. Persistenz aufzubauen, Schritt 11, bevor man echte Verifikation hat, Schritte 6 und 7, bedeutet, dass man sorgfältig Lehren von einem Judge aufzeichnet, der möglicherweise schlechte Ergebnisse einfach durchwinkt, was die Persistenzschicht aktiv schädlich macht, anstatt nur nutzlos. In dieser Liste vorzuspringen bedeutet nicht nur, ein Feature zu verpassen. Es bedeutet, die aufregend aussehenden Teile auf einem Fundament zu bauen, das sie nicht wirklich tragen kann, und das erst zu entdecken, wenn im großen Stil bereits etwas schiefgegangen ist.

Phase Eins: Der Mentale Wandel (Schritte 1 bis 4)

Schritt 1: Akzeptiere, dass du der Engpass bist, nicht das Modell

Der erste wirkliche Schritt ist nicht technischer Natur. Es geht darum, zuzugeben, dass der limitierende Faktor in deinem aktuellen Workflow nicht die Fähigkeit des Modells ist, sondern deine eigene Anwesenheit im Loop. Jedes Mal, wenn du sitzt und auf eine Antwort wartest, sie liest, dann die nächste Anweisung tippst, bist du mit Abstand der langsamste Teil des Systems. Das Modell kann handeln, verifizieren und wiederholen, weit schneller, als du es dabei beaufsichtigen kannst.

Dieser Schritt hat kein Prompt, das daran hängt. Es ist eine Entscheidung. Bis du das wirklich glaubst, wird sich jeder folgende Schritt wie unnötiger Aufwand anfühlen, anstatt das zu sein, was er ist: den tatsächlichen Engpass zu beseitigen.

Schritt 2: Höre auf, einen längeren Prompt mit einem besseren System zu verwechseln

Der Instinkt, wenn etwas schiefgeht, ist, dem gleichen Prompt eine weitere Anweisung hinzuzufügen. Über Monate hinweg entsteht so ein Prompt, der eine dichte, sich selbst widersprechende Wand von Regeln ist, die das Modell nicht mehr alle gleichzeitig im Arbeitsspeicher behalten kann, also pattern-matched es auf das, was sich am aktuellsten anfühlt, und lässt den Rest stillschweigend fallen.

Loop Engineering ersetzt diesen Instinkt vollständig. Anstatt eine weitere Regel zu einem Prompt hinzuzufügen, fügst du eine weitere Komponente zu einem System hinzu. Einen Verifikationsschritt. Eine Speicherdatei. Einen geplanten Trigger. Der Prompt selbst sollte im Laufe der Zeit kürzer werden, je leistungsfähiger das System um ihn herum wird, nicht umgekehrt.

Schritt 3: Lerne, jede Aufgabe als fünf Schritte zu sehen

Jede einzelne Runde eines Loops, unabhängig vom spezifischen Bereich, zerfällt in fünf Schritte. Discovery, herauszufinden, was tatsächlich passieren muss. Handoff, die Aufgabe an das zu übergeben, was sie ausführen wird. Verification, das Ergebnis an etwas Realem zu überprüfen. Persistence, aufzuzeichnen, was passiert ist, damit es nicht verloren geht. Scheduling, zu entscheiden, wann dies erneut läuft.

Der aktuelle Workflow der meisten Menschen hat nur zwei dieser Schritte explizit, Discovery und Handoff, manuell in einem Chat-Fenster durchgeführt. Die anderen drei existieren entweder nicht oder finden unsichtbar im Kopf der Person statt. Loop Engineering ist die Praxis, alle fünf Schritte explizit und automatisch zu machen.

Schritt 4: Identifiziere deine erste echte Kandidatenaufgabe

Bevor du etwas baust, wähle eine Aufgabe aus, die du bereits wiederholt erledigst, mit einem Standard, den du aufschreiben könntest, wenn du gefragt würdest. Nicht dein schwierigstes Problem. Nicht etwas völlig Neues. Eine Aufgabe mit einer echten, erkennbaren Definition von "erledigt", etwas, das ein Kollege anschauen und sofort als korrekt erledigt oder nicht erledigt bezeichnen könnte. Diese Einschränkung ist wichtiger, als sie aussieht. Eine Aufgabe ohne klare Definition von "erledigt" kann Schritt drei, die Verifikation, nicht dafür bauen lassen, und ein Loop ohne echte Verifikation ist kein Loop, sondern nur eine unbeaufsichtigte Vermutung.

Phase Zwei: Den Ersten Loop Bauen (Schritte 5 bis 9)

Schritt 5: Schreibe die Definition von "Erledigt", bevor du ein Prompt schreibst

Dies ist der Schritt, den die meisten überspringen, und derjenige, der bestimmt, ob alles danach funktioniert. Bevor du eine einzige Anweisung für den Agenten schreibst, schreibe in einfacher Sprache auf, wie genau ein korrektes Ergebnis aussieht. Spezifische, überprüfbare Kriterien, kein vages Gefühl von Qualität.

DEFINITION VON "ERLEDIGT" für [Aufgabenname]:

• [Spezifisches, überprüfbares Kriterium 1]
• [Spezifisches, überprüfbares Kriterium 2]
• [Spezifisches, überprüfbares Kriterium 3] Diese Aufgabe ist NICHT erledigt, wenn eines der oben genannten fehlt, selbst wenn die Ausgabe vollständig oder ausgefeilt aussieht.

Wenn du dies für deine gewählte Aufgabe nicht ausfüllen kannst, gehe zurück zu Schritt 4 und wähle eine andere.

Schritt 6: Trenne den Builder vom Judge

Die mit Abstand wichtigste architektonische Entscheidung in jedem Loop. Die Rolle, die die Arbeit produziert, und die Rolle, die die Arbeit überprüft, müssen getrennt werden, denn ein Modell, das seine eigene Ausgabe im selben Atemzug überprüft, in dem es sie produziert hat, neigt dazu, diese Ausgabe zu verteidigen, anstatt sie wirklich zu hinterfragen.

Der Builder bekommt kreativen Spielraum und erstellt einen ersten Versuch. Der Judge bekommt die Ausgabe des Builders plus die Definition von "erledigt" aus Schritt 5, und nichts anderes, wovon er sich abbringen lassen könnte. Idealerweise hat der Judge auch Zugang zu etwas, das der Builder nicht hat, eine Testsuite, das ursprüngliche Quelldokument, Live-Daten, sodass sein Urteil auf echten Beweisen basiert, nicht nur auf einer zweiten Meinung, die auf die gleiche Weise gebildet wurde wie die erste.

Schritt 7: Gib dem Judge die Ground Truth, nicht nur eine Meinung

Ein Judge, der nur die Ausgabe des Builders sieht, kann dir sagen, ob sie kohärent aussieht. Er kann dir nicht sagen, ob sie tatsächlich korrekt ist. Für Codierungsaufgaben ist die Ground Truth die Testsuite und die tatsächliche Ausführungsergebnisse. Für Inhaltsaufgaben ist es das ursprüngliche Quellmaterial und das Briefing, Seite an Seite mit dem Entwurf. Für Rechercheaufgaben sind es die tatsächlichen Dokumente, die hätten verwendet werden sollen.

Wenn du nicht die spezifische Ground Truth nennen kannst, gegen die dein Judge prüfen wird, hat dein Loop noch keine echte Verifikation, egal wie zuversichtlich die Sprache des Judges klingt.

Schritt 8: Schreibe das Handoff-Format, bevor du das Handoff-Prompt schreibst

Die Ausgabe des Builders und das Urteil des Judges brauchen beide eine definierte Struktur, keine freien Prosatexte, sonst hat der Manager im nächsten Schritt nichts Zuverlässiges, um darauf zu routen.

BUILDER OUTPUT: deliverable + confidence + known uncertainties

JUDGE VERDICT: PASS / FAIL / NEEDS REVISION + specific issues found +

which ground truth this was checked against

Schritt 9: Führe es einmal manuell durch, den ganzen Weg, bevor du etwas automatisierst

Bevor du Scheduling oder automatische Wiederholungen einrichtest, führe die vollständige Builder-dann-Judge-Sequenz selbst, von Hand, einmal durch. Lies das Urteil des Judges kritisch. Würdest du ihm zustimmen? Wenn der Judge etwas bestanden hat, von dem du weißt, dass es falsch ist, oder etwas nicht bestanden hat, das eigentlich in Ordnung war, korrigiere die Ground Truth oder die Kriterien, bevor du fortfährst. Das Automatisieren eines fehlerhaften Verifikationsschritts produziert nur schneller fehlerhafte Ergebnisse.

Ein durchgerechnetes Beispiel für die Schritte 5 bis 9

Um die letzten fünf Schritte konkret zu machen, hier, wie sie bei einer realen, häufigen Aufgabe ablaufen: ein rohes Quelldokument in ein fertiges Inhaltstück zu verwandeln.

Die Definition von "erledigt" aus Schritt 5: Jede sachliche Behauptung im Entwurf geht auf etwas tatsächlich im Quelldokument Vorhandenes zurück. Der Entwurf erfüllt jede spezifische Anforderung im Briefing, Länge, Ton, erforderliche Struktur. Das Kernargument bleibt klar erhalten, ohne durch Füllmaterial verwässert zu werden.

Der Builder aus Schritt 6 erhält die Quelle und das Briefing und produziert einen Entwurf, zusammen mit einer expliziten Aussage darüber, was ihm beim Schreiben unklar war, eine Zahl, bei der er sich nicht ganz sicher war, ob sie in der Quelle stand, eine Behauptung, die er eher abgeleitet als ausdrücklich so vorgefunden hat.

Der Judge aus Schritt 7 erhält den Entwurf und die ursprüngliche Quelle Seite an Seite, niemals den Entwurf allein, und prüft jedes der drei Kriterien der Definition von "erledigt" separat und gibt für jedes einzeln ein Bestehen oder Nichtbestehen zurück, anstatt eine einzige gemischte Gesamtbewertung. Drei unterschiedliche Prüfungen in einem einzigen Urteil zusammenzufassen, verbirgt genau, welche Dimension tatsächlich fehlgeschlagen ist, was der mit Abstand häufigste Weg ist, wie ein funktionierender Loop leise aufhört, nützliches Feedback zu geben.

Das Handoff-Format aus Schritt 8 bedeutet, dass das Urteil des Judges als strukturiertes Objekt ankommt, nicht als Absatz mit abwägender Prosa, drei explizite Bestehen- oder Nichtbestehen-Ergebnisse mit einem spezifischen Grund, der an jedem Fehlschlag hängt.

Dies einmal von Hand durchzuführen, gemäß Schritt 9, bevor irgendetwas automatisiert wird, fängt den Fall, wo dein Judge zu nachsichtig ist, einen Entwurf mit einer erfundenen Statistik bestehen lässt, weil der Schreibstil ausgefeilt war, oder zu streng, einen Entwurf wegen einer stilistischen Vorliebe durchfallen lässt, die nie im Briefing stand. Beide Fehlermodi sind bei einem ersten Versuch häufig, und beide sind weit billiger, einmal manuell zu fangen, als zu entdecken, nachdem der Loop bereits fünfzig Mal unbeaufsichtigt gelaufen ist.

Phase Drei: Die Fehlenden Teile des Loops Hinzufügen (Schritte 10 bis 14)

Schritt 10: Baue den Manager und seine Abbruchbedingung

Der Manager liest das Urteil des Judges und entscheidet, was als Nächstes passiert. Hier lebt auch die Abbruchbedingung des Loops, und sie muss als harte Logik geschrieben werden, nicht als weiche Anweisung, über die das Modell sich hinwegreden kann.

ABB RUCHBEDINGUNGEN:

Maximale Überarbeitungen: 3. Bei der 3. fehlgeschlagenen Bewertung an einen Menschen eskalieren

mit der vollständigen Historie, keinen 4. Zyklus versuchen.

Qualitätsschwelle: jedes Element in der Definition von "erledigt" muss PASS zeigen.

Budgetobergrenze: wenn diese Aufgabe [X] Kosten oder [Y] Zeit überschreitet, sofort

stoppen, unabhängig vom aktuellen Zustand.

Ein Loop ohne eine echte Abbruchbedingung ist kein System. Es ist eine Verbindlichkeit, die darauf wartet, dass der Tag kommt, an dem sich die Aufgabe als wirklich unlösbar herausstellt. Der spezifische Grund, warum eine weiche Anweisung hier versagt, ist es wert, verstanden zu werden, nicht nur akzeptiert. "Stopp, wenn es gut genug ist" in einem Prompt ist ein Vorschlag, und ein Modell unter genügend Druck, das bereits mehrere Überarbeitungen verfehlt hat, wird sich oft selbst einreden, dass der aktuelle Versuch nah genug dran ist, um zu bestehen, genau weil es eine befriedigende Lösung für die Aufgabe produzieren will. Ein harter Iterationszähler, der mechanisch vom Code überprüft wird, oder durch eine explizite Regel, die der Manager nicht umgehen kann, hat diesen Fehlermodus nicht.

Schritt 11: Füge Persistenz hinzu, damit sich der Loop über Durchläufe hinweg erinnert

Ein Loop, der jedes Mal, wenn er läuft, bei Null anfängt, hat keine Erinnerung an das, was er beim letzten Mal gelernt hat. Füge eine einfache Persistenzschicht hinzu, eine Datei pro wirklich neuer Lektion, mit einer einzeiligen Zusammenfassung oben, die aufzeichnet, was gelernt oder korrigiert wurde und warum es wichtig war. Wichtig: zeichne nur das auf, was nicht bereits an anderer Stelle erfasst ist, duplizierte Erinnerung ist Rauschen, nicht Wissen.

Die Disziplin, die diesen Schritt langfristig zum Funktionieren bringt, ist Zurückhaltung beim Schreiben. Der Instinkt ist, alles zu protokollieren, was in einer Sitzung passiert ist, was genau das aufgeblähte Transkript-Problem produziert, vor dem dieser Fahrplan in Schritt 2 gewarnt hat, nur eben in einen Speicherordner verschoben statt in ein Prompt. Eine Lektion, die es wert ist, aufgeschrieben zu werden, ist etwas, dessen Wiederentdeckung im Falle des Vergessens echte Zeit kosten würde, keine Aufzeichnung von Routinearbeit, die genau wie erwartet erfolgreich war.

Schritt 12: Füge einen Konsolidierungsdurchlauf nach einem Zeitplan hinzu

Persistenz allein führt irgendwann zum gleichen Problem wie ein aufgeblähter Prompt, Dutzende von Dateien, von denen viele leicht unterschiedliche Versionen derselben Sache sagen. Überprüfe zu einem wiederkehrenden Zeitplan, wöchentlich ist angemessen, die Speicherdateien, führe Duplikate zu einzelnen, schärferen Lektionen zusammen und lösche alles, was sich inzwischen als falsch erwiesen hat. Das Ziel ist weniger Dateien mit jeweils mehr Dichte, nicht ein ständig wachsender Haufen.

Dieser Schritt ist der, den die meisten ganz überspringen, weil er allein keine sichtbare neue Fähigkeit produziert, er verhindert nur ein zukünftiges Problem. Diese Unsichtbarkeit ist genau der Grund, warum er explizit geplant werden muss, anstatt dem Zufall überlassen zu werden, wann jemand bemerkt, dass der Speicherordner unhandlich geworden ist, was in der Praxis bedeutet, dass es nie passiert, bis die Leistung des Loops bereits unter dem Gewicht widersprüchlicher, halb relevanter Lektionen zu leiden beginnt, die um denselben Kontextfenster konkurrieren.

Schritt 13: Füge den Recall-Schritt hinzu

Lasse den Loop zu Beginn eines neuen Durchlaufs die einzeiligen Zusammenfassungen im Speicher durchsuchen, identifizieren, welche Lektionen tatsächlich für die aktuelle Aufgabe relevant sind, und nur diese laden. Weise ihn explizit an, zu sagen, wenn nichts im Speicher zutrifft, anstatt eine irrelevante vergangene Lektion zwanghaft auf eine neue Situation anzuwenden, nur weil Speicher existiert.

Schritt 14: Füge einen Scheduling-Trigger hinzu

Entscheide, wann dieser Loop läuft, ohne dass du ihn manuell startest. Ein Cron-Job. Ein Datei-Watcher. Ein wiederkehrender kalenderbasierter Trigger. Dies ist der Schritt, der ein System, das du auf Abruf betreibst, in eines verwandelt, das läuft, während du schläfst, und es ist normalerweise der mit Abstand einfachste Schritt in dieser gesamten Liste, und derjenige, den die meisten Leute nie implementieren, selbst nachdem sie alles andere gebaut haben.

Phase Vier: Skalieren und Härten (Schritte 15 bis 18)

Schritt 15: Belaste den Loop, bevor du ihm vertraust

Bevor du dich auf diesen Loop für irgendetwas Reales verlässt, teste ihn absichtlich gegen vier Fehlermodi.

Gib ihm eine wirklich unlösbare Version der Aufgabe und bestätige, dass der Manager tatsächlich stoppt, anstatt sich endlos zu wiederholen, denn ein Loop, der nur an Aufgaben getestet wird, die er erledigen kann, hat nie wirklich gezeigt, dass er weiß, wie man gnädig scheitert.

Füttere den Judge mit einer Ausgabe, von der du weißt, dass sie subtil falsch ist, etwas, das sich gut liest, aber einen bestimmten sachlichen oder logischen Fehler enthält, den du absichtlich eingebaut hast, und bestätige, dass er den Fehler tatsächlich bemerkt, anstatt etwas plausibel Klingendes durchzuwinken.

Wenn Builder und Judge dasselbe zugrundeliegende Modell teilen, füttere den Judge mit einem Fehler, den dieses Modell charakteristischerweise macht, und sieh nach, ob er den Fehler durchwinkt, denn ein Judge, der die blinden Flecken des Builders teilt, macht den gesamten Zweck der Trennung aus Schritt 6 zunichte.

Berechne die Worst-Case-Kosten des Loops, wenn er bis zu seinem maximalen Überarbeitungslimit läuft, unter Verwendung deiner teuersten Modellaufrufe und der längsten vernünftigen Ausgabe, und entscheide ehrlich, ob dich diese Zahl, wenn sie auf einer echten Rechnung erscheinen würde, alarmieren würde.

Diese vier Tests durchzuführen, bevor man einem Loop mit etwas Wichtigem vertraut, fängt die überwältigende Mehrheit der Fehler, die sonst zum ersten Mal vor einem Kunden, einem Chef oder deinem eigenen Kontoauszug auftauchen würden, anstatt in einem kontrollierten Test, den du absichtlich durchgeführt hast.

Schritt 16: Leite Aufgaben an das richtige Modell weiter, nicht jedes Mal an dasselbe

Sobald ein Loop funktioniert, widerstehe der Gewohnheit, jeden Teil davon mit deinem einzigen Lieblingsmodell auszuführen. Die Builder-Rolle profitiert normalerweise von deinem leistungsfähigsten Modell, da sie die eigentliche harte Denkarbeit leistet, und ein schwächeres Modell hier produziert einen schlechteren ersten Entwurf, der mehr Überarbeitungszyklen kostet, um ihn zu korrigieren, als es gekostet hätte, ihn von Anfang an gut zu generieren.

Die Judge-Rolle, die gegen einen spezifischen schriftlichen Standard prüft, funktioniert oft genauso zuverlässig auf einem kleineren, billigeren, schnelleren Modell, da sie nicht kreativ sein muss, sondern nur konsistent, und ein kleineres Modell, das gegen eine extrem gut spezifizierte Checkliste prüft, erreicht häufig ein großes zu einem Bruchteil der Kosten und Latenz.

Der Manager, der auf der Grundlage von Regeln routet, die du bereits aufgeschrieben hast, braucht fast nie dein teuerstes Modell, da seine Aufgabe darin besteht, Logik auszuführen, die du bereits spezifiziert hast, nicht offenes Denken, und er läuft mindestens einmal pro Iteration, unabhängig davon, wie Builder und Judge abschneiden, was seine Kosten pro Aufruf wichtiger macht als seine rohe Fähigkeit.

Dieser abgestufte Ansatz, teures Modell zum Bauen, billiges und konsistentes Modell zum Beurteilen von Routineprüfungen, billiges Modell zum Routen, ist normalerweise der Ort, an dem die echten Kosteneinsparungen in einem Loop herkommen. Die meisten Leute nehmen an, dass Kostenkontrolle weniger Loops oder weniger Überarbeitungen bedeutet. Sie kommt tatsächlich davon, die Modellkosten an die tatsächliche Schwierigkeit jeder spezifischen Rolle innerhalb des Loops anzupassen, den du bereits gebaut hast.

Schritt 17: Erweitere auf einen zweiten Loop, nicht auf fünf gleichzeitig

Die Versuchung, sobald der erste Loop funktioniert, ist, sofort mehrere weitere zu bauen, fünf verschiedene Aufgaben parallel anzugehen, weil die Architektur es technisch jetzt unterstützt. Widerstehe dem länger, als es sich bequem anfühlt. Bringe einen Loop so zuverlässig zum Laufen, dass du wirklich aufgehört hast, seine Ausgabe genau zu überprüfen, was bedeutet, dass er über einen realen Zeitraum hinweg konsequent deine eigenen manuellen Stichproben besteht, nicht nur eine einzige erfolgreiche Demo-Runde, die alle zufällig genau beobachtet haben. Erst dann beginne mit dem zweiten Loop, an einer anderen Aufgabe, idealerweise einer, die sich auf etwas völlig anderes als die erste abbildet, so dass du testest, ob das zugrundeliegende Skelett verallgemeinert, anstatt nur dieselbe Aufgabe weiter zu verfeinern.

Schritt 18: Verschaffe dir eine gemeinsame Ansicht über alle laufenden Loops

Sobald du mehr als einen Loop am Laufen hast, verfolge eine gemeinsame Ansicht der Kosten und der Auslöser der Abbruchbedingungen über alle hinweg, nicht pro Loop isoliert. Ein einzelner Loop mit einem vernünftigen Budget pro Aufgabe sieht für sich allein völlig in Ordnung aus. Zehn Loops, die jeweils einzeln im Budget liegen, können trotzdem eine alarmierende Gesamtsumme ergeben, die niemand bemerkt, bis die Gesamtrechnung eintrifft, genau weil die Verfolgung jedes einzelnen Loops für sich genommen in Ordnung aussah.

Protokolliere jeden Auslöser der Abbruchbedingung spezifisch, nicht nur erfolgreiche Abschlüsse. Ein Loop, der ständig sein Überarbeitungslimit erreicht, während andere es selten tun, sagt dir, dass der Standard seines Judges falsch kalibriert ist, zu streng, um jemals wirklich zu bestehen, oder dass er gegen die völlig falsche Ground Truth prüft, nicht, dass die zugrundeliegende Aufgabe einfach schwer ist. Dieses Muster ist unsichtbar, wenn du nur Erfolge verfolgst und jede Eskalation als isoliertes, unauffälliges Ereignis behandelst, anstatt als Datenpunkt über das Design dieses spezifischen Loops.

Phase Fünf: Ein Systemdesigner Werden (Schritte 19 und 20)

Schritt 19: Höre auf, dich an der Anzahl geschriebener Prompts zu messen

Das klarste Zeichen dafür, dass der Wandel tatsächlich stattgefunden hat, ist eine Veränderung dessen, worauf du Tag für Tag achtest. Ein Prompter verfolgt, wie viele gute Prompts er geschrieben hat. Ein Systemdesigner verfolgt, wie viele Loops laufen, wie zuverlässig jeder ist und wie viel seiner eigenen Zeit ihm durch Systeme zurückgegeben wurde, die keine Aufsicht mehr brauchen. Wenn du deine eigene Produktivität immer noch an der Anzahl getippter Prompts misst, ist der mentale Wandel aus Schritt eins noch nicht vollständig angekommen, unabhängig davon, wie viele Loops du technisch gebaut hast.

Schritt 20: Bringe jemand anderem die fünf Schritte bei

Der letzte Schritt hat eigentlich nichts mehr mit deinen eigenen Systemen zu tun. Er bestätigt, dass du den Wandel wirklich verinnerlicht hast, indem du ihn jemand anderem erklärst, ohne auf Jargon zurückzugreifen. Discovery, Handoff, Verification, Persistence, Scheduling. Wenn du eine andere Person durch den Bau ihres eigenen ersten Loops führen kannst, indem du nur diese fünf Schritte und die obigen Schritte verwendest, hast du den eigentlichen Übergang vollzogen, den dieser Fahrplan beschreibt. Du bist nicht länger die Person im Loop, die die nächste Anweisung tippt. Du bist die Person, die ihn entworfen hat, draußen stehend, und zusiehst, wie er läuft.

Die vier Kosten, die still anfallen, wenn du Schritte überspringst

Es lohnt sich, mit einer Warnung zu schließen, denn das Überspringen von Schritten in diesem Fahrplan scheitert nicht laut, es scheitert leise, auf Weisen, die sich erst viel später zeigen.

Verifikationsschulden häufen sich an, wenn du die Schritte 6 und 7 überspringst, Loops ohne echten Judge oder ohne echte Ground Truth baust. Der Loop sieht aus, als ob er funktioniert, weil die Ausgabe in Ordnung aussieht, genau bis ein Fehler sich still über Dutzende von Durchläufe hinweg verstärkt, bevor ihn jemand bemerkt.

Verständnisfäule setzt ein, wenn du Schritt 20 überspringst, Loops laufen lässt, die du einmal gebaut hast, aber nicht mehr erklären oder debuggen könntest, wenn sie kaputtgehen, weil du nie verinnerlichen musstest, warum jedes Stück existiert.

Kognitive Kapitulation tritt ein, wenn Schritt 1 nie wirklich ankommt, wenn du aus Gewohnheit weiterhin jede Ausgabe manuell doppelt überprüfst, lange nachdem sich das Verifikationssystem bereits bewährt hat, und damit den gesamten Zweck des Systembaus zunichte machst.

Token-Explosion ist das, was passiert, wenn du Schritt 10 überspringst, Loops ohne echte Abbruchbedingung laufen lässt, und die tatsächlichen Kosten erst entdeckst, wenn die Rechnung kommt.

Jede dieser Kosten ist vermeidbar, und jede wird durch dieselbe Disziplin vermieden. Baue die Schritte in der richtigen Reihenfolge. Überspringe nicht die, die sich unglamourös anfühlen. Die langweiligen Schritte, die Definition von "erledigt", die Abbruchbedingung, die Ground Truth, sind diejenigen, die tatsächlich die Arbeit leisten. Die interessant klingenden Teile, das clevere Prompt, das ausgeklügelte Architekturdiagramm, sind weit weniger wichtig als die Frage, ob das System, das du gebaut hast, tatsächlich weiß, wann es richtig liegt, wann es falsch liegt und wann es aufhören muss.

Das ist der gesamte Unterschied zwischen einem Prompter und einem Systemdesigner. Nicht Klugheit. Disziplin in Bezug auf die Teile, die langweilig zu bauen und leicht zu überspringen sind.

Folge @cyrilXBT für die genauen Loop-Vorlagen und Builder-Judge-Manager-Setups hinter jedem Schritt in diesem Fahrplan.