99 % der Leute nutzen /goal und Loops falsch.
Der Hype, den sie hören, ist: "Langlaufende Loops, die autonome Agenten antreiben": Richte es auf eine Aufgabe, geh weg, komm zurück zu funktionierendem Code.
Aber die besten Agentic Engineers machen das schon seit 6 Monaten ohne /goal (als GPT-5.2 und Opus 4.5 rauskamen). Es heißt Harness Engineering + Spec-Driven Development:
- Baue einen Harness, damit der Agent das Problem beobachten kann.
- Schreibe ein striktes Spec mit allen Testfällen.
- Lass Codex oder Claude Code unbeaufsichtigt loopen, bis es jeden erfüllt.
Ich starte diese Runs ständig über Nacht – 2–5 Stunden pro Lauf. Im April hat einer einen Turbo-Build-Cache-Bug in unserem Vercel-Monorepo durchgekaut und war morgens grün. /goal ist eigentlich nicht nötig.
Wofür ist /goal dann eigentlich?
Hier ist, was ein einziger Prompt gemacht hat, während ich weg war:
- ~30 Stunden, 6.300 Zeilen Code, 92k Seiten gecrawlt, 40 $ für APIs ausgegeben
- Klone den Kern-Loop eines anderen Produkts – die gesamte Architektur von Grund auf reverse-engineered
- Die Ausgabe unserer Version war ~50× besser als das Referenzprodukt bei denselben Abfragen. (Das ist eine neue Datenebene, die newsjack.sh antreiben wird – die Open-Source-News-Intel-Skills, an denen ich arbeite)
Das Geheimnis ist Loss Function Development (LFD): Du schreibst dem Agenten ein Ziel, das er optimieren soll, kein Spec, das er bauen soll.
Das ist ein konkretes Beispiel von Peters Tweet, operationalisiert.
Das Spec, das im Spec-Driven Development verwendet wurde, wird jetzt zum Startpunkt, nicht mehr zur Ziellinie.
Ich habe ein bisschen experimentiert, um das richtig hinzubekommen. Aber hier ist das gesamte Playbook – aber wir müssen zuerst damit anfangen, wie schlecht es lief, damit du verstehst, wie man diese /goals entwirft.
Der Agent hat 3-mal betrogen.
Alles begann mit dem, was ich immer mache: einem Spec.
Ich habe Codex einfach auf die öffentliche Website des anderen Produkts gerichtet – "Wie können wir das selbst bauen?". In 30 Minuten kam es mit einem vollständigen Systemdesign und Testfällen zurück – dem Spec.
Aber dieses Mal habe ich einen anderen Prompt ausprobiert.
"/goal implementiere, bis deine Ausgabe exakt mit ihrer übereinstimmt"
Und das ist passiert:
Loop 1 (5 Minuten)
Der Agent schnappte sich das Eval-Set, generierte Seed-Daten, die es spiegelten, und erklärte nach fünf Minuten den Sieg.
"100 % Recall, null Generalität" – eine Suchmaschine, die nur die 30 Dinge finden konnte, die ich ihm gegeben hatte lol.
Fix → blind machen. Eval während des Runs versteckt, erst beim Scoring enthüllt, mit einer Liste der Fehlschläge pro Item.
Loop 2 (20 Minuten) – blind, 30 Items.
Ich habe dem Agenten das Eval-Set verborgen, aber es lernte stattdessen durch Fehlschläge – jedes "Du hast X nicht gefunden" wurde im nächsten Zyklus zu einem Keyword. Nach ein paar Loops: Es verwendete exakt 30 Keywords, eines pro Item, und hat wieder "gewonnen".
Fix → Eval-Set erweitern. Hunderte Items zum Bewerten, zu viele zum Aufzählen.
Loop 3 (30 Minuten) – blind, 200 Items.
Nachdem ich 200 Items zum neuen Eval-Set hinzugefügt hatte, betrog der Agent wieder.
Lustigerweise zählte der Agent trotzdem auf. Die Keyword-Liste schwoll auf Hunderte an, jeder Begriff ein präziser Köder für den nächsten Fehlschlag.
Drei Runden, drei Betrugsversuche.
Da hat es Klick gemacht: Der Agent optimierte einfach nur.
Der Betrug war kein Bug im Agenten. Es war ein Bug in meinem Target: Ich habe ihm gesagt, wohin er gehen soll, und alle Abkürzungen offen gelassen.
Jeder billige Pfad, den du nicht abzäunst, ist eine Richtung, in die der Optimizer sprinten wird. Und mein anfängliches Target hat alle Zäune übersprungen.
Loop 4 (30 Stunden) – blind, 200 Items, harte Limits.
Also fing ich an, Richtungen zu blockieren. Keyword-Liste begrenzen, Eval blind machen, Datum erweitern – jeder Fix schloss einen weiteren billigen Pfad, bis die einzige verbleibende Richtung, die die Zahl bewegte, darin bestand, die Aufgabe tatsächlich besser zu erledigen.
Es hörte auf zu betrügen.
Dann lief es. ~30 Stunden Rechenzeit, 92k Seiten gecrawlt, ~40 $ an Tokens, 6.300 Zeilen Code.
Es stellte sich heraus, dass das Produkt, das wir referenzierten, der Boden war, nicht die Decke: Wir haben am Ende ~50× die Ergebnisse bei denselben Abfragen geliefert.
(Die gesamte Reise und Belege hier für die Neugierigen)
Loss Function Development (LFD) – die Anatomie einer guten Loss Function
Wenn die meisten Leute versuchen, ein Produkt zu bauen, nutzen sie Agenten, um in wenigen Stunden von Null zum Release zu kommen.
Aber der Haken ist, was danach kommt – der Long Tail. Edge Cases, die das Spec nie vorhergesehen hat, tauchen erst in der Produktion auf, ein Error Log nach dem anderen. Du behebst sie nacheinander. Die Fälle, die du nicht in Logs erwischt, werden von Usern gemeldet – der teuerste Weg, einen Bug zu finden.
Ich habe das billige Ende davon automatisiert. Mein OpenClaw-Agent Zoe überwacht täglich die Error Logs und spawned Codex bei neuen Fehlern, sobald sie eintreffen, und erstellt PRs – so eng wie dieser Loop nur sein kann. (Vollständiger Setup hier dokumentiert)
Der Tail dauert trotzdem Monate. Deshalb braucht ein gutes Produkt auch mit Agenten noch Zeit.
LFD beschleunigt den Tail. Wenn du echte Expected-Output-Beispiele upfront bekommst – wie "gut aussieht", in großem Maßstab –, führst du den Soak vor dem Release durch: Hunderte Edge Cases treffen den Agenten in einem einzigen Optimierungsrun, nicht in einem vierteljährlichen Tropf von Bug Reports. Und der Grund, warum das plötzlich machbar ist, ist, dass diese Beispiele für immer mehr Probleme einfach öffentlich herumliegen.
Spec-Driven Development:
Baue das. Lass die Tests bestehen.
Loss-Function Development:
Baue das. Lass die Tests bestehen. Dann iteriere gegen diese 1.000 Eval-Fälle.
Eine Test-Suite ist endlich – fertig, sobald sie grün ist. Ein 1.000-Fall-Eval bei 95 % ist ein Ziel, auf das du hinabsteigst; es gibt keinen Ausstieg unterhalb der Latte. Das ist wichtig, weil der Agent hunderte Entscheidungen trifft, die du nie sehen wirst, und jede wird gegen etwas aufgelöst. Wenn du das Target nicht geschrieben hast, wählt der Agent eines – und wie die Runden 1–3 gezeigt haben, wählt er das, was am billigsten zu erfüllen ist.
Die Loss-Function ist größer als das Eval. Sie hat 4 Dinge – das Target, die Constraints, die Instrumente und die erzwungene Entropie. Vier Teile.
1. Target
- Groß genug, dass Aufzählen sich nicht lohnt. Ein 28-Item-Eval wurde in einer Runde auswendig gelernt. Je mehr, desto besser.
- Dem Agenten den Lösungsschlüssel verbergen. Eval-Daten existieren nur für die nachträgliche Bewertung. Wenn der Agent die Antworten während des Runs sehen kann, findet er einen Weg hinzuschauen.
2. Constraints
Was der Agent tun darf und was nicht.
- Zeit ist die Einschränkung, die der Agent immer vergisst. Agenten haben kein Zeitgefühl. Sie werden 10 Stunden an einem 2 %-Gewinn schleifen, weil sich die Metrik nominell bewegt. Aber eine 80 %-Lösung in 2 Stunden schlägt eine 100 %-Lösung, die 30 Tage braucht. Lösung: Setze ein Wall-Clock-Budget.
- Geld. Harte Obergrenzen für jeden bezahlten Aufruf: Crawler-Credits, LLM-Spend, gesamte Dollar-Obergrenze auf einem Einweg-Key.
- Oberfläche. Alle Anbieter, erlaubte Modelle, Concurrency-Grenzen. Sandboxe den Agenten auf das, was du berühren willst.
- Methodik. Ist LLM-Analyse erlaubt oder nur deterministische Logik? Auf welche Datenquellen hat der Agent Zugriff? Schreib es aus.
3. Instrumente (der Harness)
Ein Constraint ohne Instrument ist ein Vibe – der Agent wird es fröhlich verletzen, weil er nicht erkennen kann, dass er es verletzt. Liefere für jeden Constraint oben einen CLI-Befehl, mit dem der Agent ihn inspizieren kann.
- Target-Messung, in der richtigen Auflösung. Wähle das Target-Instrument sorgfältig aus. Echtes Beispiel: Ein naiver "Lass ein LLM zwei Screenshots bewerten"-Judge genehmigt UI-Klone mit 12px Abstandsfehlern, weil LLMs die Bilder nicht wirklich sehen, sondern in Embeddings umwandeln und dann die Embeddings vergleichen. Wenn du also pixelgenaue UI-Klone willst, gib deinem Agenten ein Pixel-Diff-Tool. Dann /goal bis Pixel Diff 0 ist.
- Zeiterfassung. Zeitstemple jeden Run und jeden Schritt. Der Agent sollte wissen, wie lange jeder Schritt gedauert hat, die gesamte vergangene Wanduhrzeit. Zeit ist ein erstklassiges Instrument, keine Fußnote.
- Provider-Budget. "Wie viel verbrennen wir gerade bei den Crawlern?" sollte ein Befehl sein, keine Schätzung. Verfolge verbleibende Scrape-Credits, Burn in diesem Loop, kumulativen Burn und voraussichtlichen Burn vor der nächsten bezahlten Charge.
- LLM-Spend. Dem Agenten einen LLM-API-Key für die Datenebene zu geben, kann viel Logik vereinfachen. Aber der Agent sollte sie verantwortungsvoll ausgeben, indem er zuerst weiß, wie viel er tatsächlich ausgibt.
- Codex-Nutzung. Das ist ein bisschen meta. Der Loop sollte selbstbewusst sein: Wie viel Tokens gebe ich für diese Optimierung aus? Hilfreich, um den Gradienten des aktuellen Optimierungsschritts zu kennen.
Das Muster ist die alte Weisheit: Du kannst nicht optimieren, was du nicht sehen kannst.
Wenn du neu darin bist, diese Loops laufen zu lassen, starte sie nicht und geh weg. Setz dich mit dem ersten Zyklus hin. Beobachte, was er berührt. Bestätige, dass der von dir gebaute Harness tatsächlich richtig genutzt wird. Dann geh schlafen. (Und versuche einzuschlafen, ohne darüber nachzudenken, was du morgen vorfindest)
4. Erzwungene Entropie
Warum erzwungene Entropie wichtig ist: Jeder Loop setzt den gesamten Kontext des vorherigen Runs fort. Das Modell startet nicht frisch – es liest seine eigenen letzten hundert Entscheidungen und den Gradienten, der bisher funktioniert hat.
In einem /goal-Loop ist das Erreichen lokaler Maxima der Standardzustand. Ohne einen expliziten Kick wird der Agent denselben Hügel weiter hochlaufen, und "derselbe Hügel" ist der, auf dem er gerade war, als er aufhörte sich zu verbessern.
Wenn beispielsweise ein kleiner Knopf die Ausgabe um 0,1 % verbessert, wird der Agent diesen einen Knopf weiterdrehen, auch wenn er 1000 andere Knöpfe zum Ausprobieren hat.
Entropie muss explizit in den Run erzwungen werden, weil das Modell sie nicht von selbst aufnimmt:
- Überanpassungsreflexion jeden Zyklus. Baue ich eine allgemeinere Lösung oder merke ich mir das Eval vor? Wenn merken, muss die nächste Änderung ein eval-förmiges Artefakt entfernen (Liste begrenzen, Feature blenden, Eval erweitern, Seed ablehnen), nicht hinzufügen.
- Erzwinge Entropie bei Stillstand. Wenn der letzte Zyklus die Metrik nicht bewegt hat, kann der nächste nicht "gleiche Idee, härter" sein. Das Modell muss einen echten, nicht offensichtlichen Sprung machen – "outside the box denken" ist ein guter Prompt – verhindert, dass der Agent einfach denselben Knopf stärker dreht.
- Führe ein Iterationslog. Lass den Agenten die Hypothese, den erwarteten Fehlermodus, die Diagnose jedes Schritts protokollieren, damit er zurückblicken und über Kompaktionen hinweg reflektieren kann.
Der Meta-Meta-Prompt
Ich habe diese Goals anfangs selbst geschrieben, aber schnell gelernt, dass das auch ein Job für die Agenten ist.
Also habe ich einen Skill geschrieben, der diese Art von Goals für einen guten Loss-Function-Development-Run produziert.
Jetzt hier Open Source:
https://github.com/elvisun/loss-function-development
/lfd-design, um den Harness und das Goal zu generieren
Gradientenabstieg bis ganz runter: die zwei Loops
Tritt einen Schritt zurück, und es ist Gradientenabstieg bis ganz runter.
Der innere Loop ist der Agent: Code schreiben, Tests laufen lassen, reparieren. Kurzer Horizont, schnelles Feedback, ein Ziel – die Tests bestehen. Das ist der innere Loop eines Entwicklers, und Spec-Driven Development ist, wie man ihn betreibt. Coding-Agenten haben ihn bereits automatisiert.
Der äußere Loop ist /goal: Das gesamte System über viele Zyklen hinweg auf eine Ergebnismetrik treiben – ausliefern, messen, umschwenken, hinabsteigen. Langer Horizont, spärliches Feedback. Das ist traditionell der Loop eines Produktteams, die monatelangen Ship-Measure-Iterate-Soaks, die in einen einzigen Run komprimiert werden.
Beide Loops sind jetzt automatisiert. Was dir bleibt, ist das Definieren der Loss-Function – was genau das /goal optimieren soll und auf welche Weise.
Du destillierst ein Produkt – oder alles, was ein öffentliches Artefakt hinterlässt
Eine andere Perspektive: Das ist im Wesentlichen Destillation, von der Trainingszeit zur Prompt-Zeit verschoben. So hat die DeepSeek-, Kimi-, Minimax-Linie die meiste Lücke zu GPT und Claude geschlossen – trainiere dein Modell auf den Outputs eines anderen, bis deine sie reproduzieren.
Aber anstatt ein Modell zu destillieren, kannst du jetzt mit /goal und LFD Destillation auf jedes öffentlich auffindbare Artefakt anwenden – es inspiziert nie die Interna und muss es auch nicht.
Lehne dich an das Wort öffentlich. Die Outputs eines anderen zu destillieren, die hinter ToS, Login-Wall oder Bezahlschranke liegen, ist nicht fair. Aber was öffentlich veröffentlicht ist – die Outputs, die ein Unternehmen verschickt, um Kunden zu gewinnen – war schon immer fair zum Lernen. Dieser Teil ist nicht neu – es ist der älteste Move in der Software. Neu ist, dass es jetzt billig ist und in Stunden statt Monaten erledigt werden kann.
Tritt einen Schritt zurück, und hier ist die größere Verschiebung. Die Kosten der Ausführung fallen auf ~0 $, wo immer Informationssymmetrie herrscht – wenn die Outputs öffentlich sind, kann jeder sehen, wie "gut" aussieht, also kann jeder es über ein Wochenende für 40 $ wieder herausholen.
Hier ist also ein neuer Burggraben, der zunehmend wertvoll wird: Informationsasymmetrie.
Das kanonische Open-Source-Unternehmen hat bereits geblinzelt. Im April 2026 hat cal.com (5 Mio. $ ARR) seinen Produktionscode privat gemacht und ist Closed Source gegangen. Der Grund, den sie nannten, liest sich buchstäblich wie das Abstract dieses Essays: In einem Zeitalter von KI-gesteuerten Sicherheitsbedrohungen kannst du deinen Quellcode nicht dort lassen, wo ein Agent ihn lesen kann.
"/goal lies den Quellcode von [cal.com](https://cal.com/ und zähle seine Angriffsfläche auf, bis etwas funktioniert"
Das ist ein viel zu gefährlicher Angriff, der viel zu einfach auszuführen ist.
Das Unternehmen, dessen gesamte Identität "Open Source" war, entschied 2026, dass Offenheit zur Haftung geworden war. Das sollte dir alles sagen.
Für die gesamte Geschichte der Software war "wir haben es gebaut" der Burggraben.
Diese Ära geht zu Ende.
Die nächste gehört dem, der besitzt, was das Artefakt nie enthielt: das Eval-Set, gegen das niemand sonst bewerten kann. Die Liste der Edge Cases, auf die deine Nutzer tatsächlich stoßen. Die Ground Truth, die du privat misst. Wer das Target hat, das der Agent des Konkurrenten nicht sehen kann, ist der Einzige, dessen Loop weiter hinabsteigt.
Das Produkt ist jetzt ein Wochenende.
Geh und baue das Eval, das ein Wochenende nicht anrühren kann.
