Loop Engineering: Der Loop ist der billige Teil

Auch auf Englisch verfügbar: Loop Engineering: The Loop Is the Cheap Part.

Teil 2 zu Loop Engineering: Wenn nicht mehr der Prompt die Arbeitseinheit ist. Dort steht die Theorie. Hier wird es konkret, am eigenen Repo, mit grünen und roten Tests.

In Teil 1 stand ich an der Schwelle und habe mich nicht getraut. Die halbe Branche ruft „schreib keine Prompts mehr, schreib Loops”, und ich hatte meinen ersten ernsthaften Loop noch nicht gewagt. Inzwischen habe ich ihn gebaut. Die Überraschung war, woran mein Zögern wirklich lag: nicht am Loop. Der war nie das Schwierige.

Was entstanden ist

Mein Testobjekt war FunkParcours, ein Funkübungs-Tool, das ich in einem Rutsch zusammengevibet hatte. Architektur und Spec waren solide, der Spielkern sogar getestet. Was fehlte, war die Prüf-Fläche. Der Server gab zentrale Versprechen, die niemand absicherte: Der Empfangstrupp darf die Vorlage nie sehen, der Timer läuft serverseitig. Kein CI, kein echtes Lint, kein Vertrag, der ein neues Spieltyp-Plugin zwingt, sich selbst prüfbar zu machen.

Aus jeder Lücke wurde ein Issue, mit Akzeptanzkriterien, Architekturnotizen und einer Definition davon, was „geprüft” heißt. Das ganze Bündel ging dann in einem einzigen Durchlauf an Claude Code, nicht mehr Prompt für Prompt. Heraus kamen ein CI-Gate mit Postgres, das bei Rot blockiert, eine AGENTS.md mit den Invarianten, ESLint, Server-Integrationstests und ein registry-getriebener Vertragstest. Am Ende: 141 grüne Tests im Kern, 80 davon allein der Vertrag.

Ehrlich eingeordnet: Das war kein autonomer Loop, der nachts allein lief. Es war ein agentischer Durchlauf gegen einen klaren Plan, mit mir als Verifier. Und genau da liegt der Punkt.

Der Loop ist billig, der Verifier ist die Arbeit

Monatelang hatte ich Respekt vor der falschen Sache. Ich dachte, der Mut, der mir fehlt, sei der Mut zum Kontrollverlust: das while laufen zu lassen, ohne danebenzusitzen. Aber das while ist der billigste Teil der Geschichte. Ein Dutzend Zeilen.

Die Arbeit steckt woanders, nämlich im Schreiben der Verifier. Festzulegen, was „korrekt” und „fertig” in diesem Projekt überhaupt bedeuten. Das ist die eine Aufgabe, die kein Agent übernimmt, weil sie die Frage ist, an der er selbst gemessen wird. Ein Agent benotet sich nicht; fragt man ihn, ob er fertig sei, sagt er Ja. Das Urteil muss von außen kommen, und dieses Urteil zu bauen, ist die eigentliche Ingenieursarbeit.

Das passt zur Kostenrechnung aus Teil 1. Was eine Schleife bezahlbar macht und was ihr Vertrauen verschafft, ist dasselbe: eine harte, prüfbare Stop-Bedingung. Ohne Verifier gibt es keinen bezahlbaren Loop und erst recht keinen, dem ich trauen würde. Teuer ist nicht das Loslassen. Teuer ist der Verifier, der davor entstehen muss.

Coding ist der einfache Fall

Diese Erkenntnis hat einen unbequemen Beigeschmack, den Louis Bouchard (Towards AI) in seinem Video „Loop Engineering Explained” gut auf den Punkt bringt. Ein deterministisches Ziel, alle Tests grün, CI sauber, ist prüfbar, also hält der Loop an. Ein subjektives Ziel, „mach es gut”, hat kein Target. Der Loop schreibt endlos um, Version 55 und kein Ende, weil ihm niemand sagt, wann Schluss ist. Ohne Prüfung wird daraus kein Loop, sondern, in Bouchards Bild, ein sehr selbstbewusster Token-Ofen.

Deshalb läuft FunkParcours überhaupt autonom: weil seine Ziele deterministisch sind. „Die perfekte Antwort ergibt 1,0” und „der Trupp sieht die Vorlage nie” kann eine Maschine beweisen. Coding ist genau aus diesem Grund der einfache Fall. Heißt das Ziel dagegen „bessere Produktstrategie” oder „schöneres Design”, fehlt das Target, und kein while der Welt ersetzt den Menschen, der entscheidet, was „gut” heißt.

Der Verifier, der die Architektur verändert hat

Am schönsten zeigt das der Vertragstest. Ein einziger Test geht alle registrierten Spieltypen durch und prüft fünf Gesetze: Gleicher Seed erzeugt dieselbe Vorlage, die perfekte Antwort ergibt Genauigkeit 1,0, eine falsche Antwort weniger, der Wert bleibt zwischen 0 und 1, und der Generator bleibt frei von Frontend und I/O.

Das Gesetz „perfekte Antwort ergibt 1,0” hatte eine Folge, die ich beim Schreiben nicht kommen sah. Um es zu prüfen, muss jeder Typ sagen können, wie seine perfekte Antwort aussieht. Also wanderte eine Methode samplePerfectAnswer auf das gemeinsame Interface und damit in alle dreizehn bestehenden Typen. Seitdem kompiliert ein neuer Spieltyp nicht mehr, wenn er nicht erklären kann, wie man ihn löst.

Das ist für mich der Kern von Loop Engineering, viel mehr als das while: Der Verifier diktiert das Design. Ich habe nicht „ein paar Tests ergänzt”, ich habe das System gezwungen, sich selbst prüfbar zu machen, und das hat die Schnittstelle verändert. Jedes künftige Plugin erbt diesen Vertrag und ist damit sicher by construction. Das ist die Arbeit, die nach oben wandert.

Was kaputtging

Die 141 Unit-Tests waren grün. Das End-to-End war es nicht. Im e2e-Durchlauf, der den ganzen Stack durchspielt, blieb der Trupp sofort hängen, nicht an der Logik, sondern an einem Hilfe-Dialog der Station, der beim ersten Öffnen über dem Spielfeld liegt und alle Klicks abfängt. Kein Unit-Test sieht das: Jede Funktion für sich ist korrekt. Es bricht erst da, wo die echten Bausteine im Browser aufeinandertreffen, in der Reihenfolge, in der ein Mensch klickt.

Die Lektion in einem Satz: Verschiedene Verifier fangen verschiedene Wahrheiten. Der Vertragstest sichert die reine Logik, billig und schnell. Der e2e-Test sichert die Integration, teuer und langsam. Wer nur den billigen baut, hält ein grünes Projekt für fertig, das im Browser stolpert.

Eine Prüfung verdient mehr Misstrauen als alle anderen. Sie steht wörtlich in der AGENTS.md, die der Durchlauf geschrieben hat: „A green route is not enough – the test must assert the property, never just status 200.”

Es geht um das zentrale Versprechen der Plattform: Der Empfangstrupp bekommt die Vorlage nie über die Software. Der Kanal ist das Funkgerät, nicht die App. Ein fauler Test prüft, ob die Route antwortet. Der echte Test rekonstruiert serverseitig die wahre Vorlage und behauptet dann, dass sie in der Antwort an den Trupp in keiner Form auftaucht: nicht als Feld, nicht im Heatmap-Feedback nach dem Abgeben, nicht im Snapshot nach einem Reconnect. Dieser Verifier ist nicht freundlich, er ist adversariell. Er unterstellt, dass die Antwort durchsickern könnte, und sucht aktiv danach.

Hier meldet sich mein Governance-Reflex aus Teil 1. Bei einer Sicherheitseigenschaft traue ich weder dem Selbstbericht eines Agenten noch einem grünen Häkchen, das nur Erreichbarkeit prüft. Solche Tests gehören gelesen, nicht nur ausgeführt, im Zweifel von einem zweiten Augenpaar, das die Lösung nicht selbst gebaut hat.

Wann ein Loop sich lohnt, und wann nicht

Bevor ich frage, wie autonom eine Schleife laufen darf, frage ich, ob sie sich überhaupt lohnt. Bouchards Faustregel gefällt mir: einfach anfangen, Autonomie erst dazunehmen, wenn sie sich rechnet. Eine einmalige Aufgabe prompte ich schlicht, kein Gerüst nötig. Wiederholt sich die Arbeit und hat ein klares Bestehen oder Durchfallen, lohnt der Loop, der genau diese stumpfe Wiederholung übernimmt. Ist das Ziel vage, gehört es nicht in eine while-Schleife, sondern einen Schritt zurück: erst mit Menschen ein besseres Ziel schärfen.

Dazu die harte Kostenseite. Self-Prompting und Retries verbrennen Tokens, schnell Millionen, und das pro Lauf. Die Bremsen sind unspektakulär und Pflicht: eine maximale Iterationszahl und ein Tagesbudget in Tokens oder Euro. Ohne prüfbares Stop-Ziel laufen beide ins Leere; der Ofen heizt dann nur teurer.

Auch innerhalb eines Projekts gibt es keine glatte Autonomie, sondern eine klare Kante. Wo der Verifier billig, deterministisch und vollständig ist, etwa der Vertragstest für ein neues Plugin, darf eine Schleife über Nacht laufen. Wo er eine Sicherheits- oder Fairness-Eigenschaft prüft, läuft sie auch, aber das Urteil lese ich nach. Und bevor etwas in Produktion geht, schaue ich selbst noch einmal drüber. Die Reichweite jeder Schleife endet dort, wo sich „fertig” nicht mehr maschinell beweisen lässt.

Das ist zugleich meine nüchterne Antwort auf die Frage, ob solche Loops Teams ersetzen. Der Wert ist nie in die Schleife gewandert. Er bleibt in den drei Dingen darüber: zu wissen, was „korrekt” heißt, gut genug, um es als Test zu schreiben; zu merken, wenn ein Agent sich grün stempelt, obwohl er das Falsche geprüft hat; und zu entscheiden, wo ein Mensch zwingend dazwischengehört. Diese Urteilsarbeit ist mehr geworden, nicht weniger.

Wo der Weg hinführt

Die Schwelle ist überschritten, nur an anderer Stelle als gedacht. Der Mut, den ich brauchte, war nicht der zum Kontrollverlust, sondern die Disziplin, zuerst die unscheinbare Hälfte zu bauen: die Prüfungen, die festlegen, was gut ist. Das while davorzusetzen, ist danach ein Nachmittag.

Der nächste Schritt ist klar, und diesmal ohne flaues Gefühl: ein neues Spieltyp-Plugin von einer echten autonomen Schleife bauen lassen, mit dem Vertragstest als Richter, über Nacht, mit Kostenbremse. Weil der Verifier existiert, ist das kein Sprung ins Dunkle mehr, sondern ein kontrollierter Lauf gegen ein Tor, das nicht lügt. Davon handelt Teil 3.

Noch eine Notiz zur KI-Transparenz auf diesem Blog: Den Code-Durchlauf hat Claude Code gemacht, die Prosa entsteht KI-gestützt. Nicht ausgelagert, und nicht auslagerbar, war die Entscheidung, was überhaupt geprüft gehört. Das war die Arbeit. Der Rest ist Tippen.

Repo zum Mitlesen: github.com/achildrenmile/funkparcours. Begriffsgrundlage in Teil 1. Das Bild vom deterministischen vs. subjektiven Ziel stammt aus Louis Bouchards „Loop Engineering Explained” (Towards AI); Addy Osmanis Originalbeitrag bleibt der beste Einzelreferenzpunkt.

Transparenz: Dieser Beitrag entstand mit KI-Unterstützung. Ich habe ihn geprüft und verantworte den Inhalt. Mehr dazu unter KI-Transparenz.