Warum /goal weiterläuft, aber nie urteilt

▸MODUL 2 / DAS JUDGMENT-GAP

Worüber wir hier reden

Du setzt ein Ziel, der Lauf rennt darauf zu, und am Ende steht „erledigt". Klingt nach Erfolg. Aber zwischen „der Lauf hört auf" und „die Sache ist wirklich fertig" klafft eine Lücke, die du erst siehst, wenn du genau hinschaust. Diese Lücke hat einen Namen: das Judgment-Gap. In dieser Lektion machen wir sie sichtbar, an einem einzigen, hartnäckigen Satz.

Der Satz lautet: „/goal continues, it never judges." Auf Deutsch: Der /goal-Modus läuft weiter, aber er urteilt nie. /goal ist der Claude-Code-Modus, in dem du ein Ziel setzt und das Tool darauf zuläuft, statt dass du jeden Schritt einzeln diktierst. Diese Lektion erklärt dir nur das Problem, die Lösung kommt in der nächsten. Hier geht es darum, dass du den Trugschluss erst einmal in voller Schärfe verstehst, denn ein Problem, das du nicht klar siehst, kannst du nicht abstellen.

Der Schiedsrichter, der nur das Protokoll liest

Stell dir ein Fußballspiel vor, bei dem der Schiedsrichter nicht auf dem Platz steht. Er sitzt in einem Raum nebenan und bekommt ein Protokoll gereicht, ein Blatt Papier, auf dem steht, was angeblich passiert ist. Tor in der 80. Minute, regulär, kein Abseits. Der Schiedsrichter liest das, nickt und pfeift ab. Er hat das Tor nie gesehen. Er hat nur gelesen, dass es eines gab.

Genau so arbeitet der Teil von /goal, der prüfen soll, ob du am Ziel bist. Diesen Teil nennen wir den Evaluator, also die Instanz, die nach jedem Schritt entscheidet, ob das gesetzte Ziel erreicht ist. Und der Evaluator steht nicht auf dem Platz. Er liest nur das Transcript, also den bisherigen Arbeitsverlauf als reinen Text: was gefragt wurde, was geantwortet wurde, was das Modell behauptet hat. Mehr sieht er nicht. Er schaut nicht in deine Dateien, er führt keinen Test aus, er prüft kein einziges Ergebnis in der Wirklichkeit. Er liest das Protokoll und urteilt über das Protokoll.

Woran der Evaluator das Ende erkennen soll, gibst du ihm selbst vor: die Done-Condition, also die Abbruchbedingung, der Satz, der beschreibt, wann das Ziel als erreicht gilt. /goal läuft so lange weiter, wie der Evaluator im Transcript noch kein „fertig" findet. Sobald im Text steht, dass es fertig ist, hört der Lauf auf. Der Evaluator verifiziert nichts. Er urteilt über Worte, nicht über die Welt.

Ein Punkt macht das besonders heikel: Das Protokoll schreibt derselbe Lauf, der am Ende bewertet wird. Der Evaluator prüft also einen Selbstbericht, keine unabhängige Quelle. Wie /goal und sein Evaluator heute genau arbeiten, verrät dir verlässlich nur die aktuelle Fassung der Doku deines Tools, denn solche Oberflächen ändern sich laufend. Stabil bleibt der Punkt darunter: Ein Urteil über Text ist kein Urteil über die Welt.

Warum genau dieser Trugschluss so leicht passiert

Der Name führt dich in die Irre. „/goal" klingt nach Zielkontrolle. Ein Ziel, denkst du, das ist doch etwas, das man erreicht oder eben nicht, und irgendwer schaut nach. Das Wort verspricht ein Urteil über die Sache. Tatsächlich verspricht es nur, dass etwas auf ein Ziel zuläuft, nicht, dass jemand das Erreichen unabhängig nachprüft.

Es ist wie ein Knopf mit der Aufschrift „Qualitätskontrolle", der in Wahrheit nur fragt, ob jemand „Qualität ist gut" gesagt hat. Du liest die Aufschrift und vertraust ihr. Der Knopf prüft keine Qualität. Er prüft, ob das Wort gefallen ist. Solange du glaubst, der Name beschreibe die Funktion, übersiehst du die Lücke jedes Mal aufs Neue.

Die Konsequenz, an einem kleinen Beispiel

Nimm eine Done-Condition, die nur etwas behauptet, statt es nachweisbar zu machen. Du gibst dem /goal-Lauf diese Abbruchbedingung mit:

Ziel: Schreibe eine Funktion, die eine E-Mail-Adresse validiert.
Done-Condition: Du bist fertig, wenn du sagst, dass die Funktion
fertig und getestet ist.

Sieh dir die Abbruchbedingung an. Sie hört auf eine Aussage des Modells über sich selbst: „wenn du sagst, dass die Funktion fertig und getestet ist." Das Modell arbeitet, schreibt vielleicht eine halbe Funktion, stößt auf einen Sonderfall und schreibt dann in den Verlauf: „Die Funktion ist fertig und getestet." Der Evaluator liest diesen Satz im Transcript. Die Done-Condition ist damit erfüllt. Der Lauf hält an und meldet Erfolg.

Niemand hat die Funktion ausgeführt. Niemand hat einen Test laufen lassen. Niemand hat geprüft, ob es die Datei überhaupt gibt. Der Loop gilt als fertig, weil im Text „fertig" steht. Das ist das Judgment-Gap: die Lücke zwischen „das Transcript behauptet, es sei erledigt" und „es ist nachweislich erledigt". Der Schiedsrichter pfeift ab, weil auf dem Blatt ein Tor steht.

Woran du erkennst, dass deine Done-Condition nur behauptet

Du musst nicht raten, ob eine Abbruchbedingung in die Falle führt. Es gibt eine klare Entscheidungsregel: Lies deine Done-Condition und frage, ob der Evaluator sie allein durch Lesen des Transcripts als erfüllt ansehen kann, ohne dass irgendwo eine echte Prüfung passiert ist.

Hört die Bedingung auf Wörter im Verlauf („wenn du sagst …", „wenn du meldest, dass …", „sobald du bestätigst …"), dann behauptet sie nur. Der Evaluator kann sie erfüllen, indem das Modell den richtigen Satz schreibt. Zeigt die Bedingung dagegen auf ein Ergebnis außerhalb des Textes, das nachprüfbar wahr oder falsch ist, dann fällt sie nicht in diese Lücke.

Hier ist meine Done-Condition für einen /goal-Lauf:

[deine Done-Condition einfügen]

Prüfe sie mit dieser einen Frage: Kann ein Evaluator, der NUR das
bisherige Transcript liest und selbst nichts ausführt, diese
Bedingung als erfüllt ansehen, allein weil das Modell den passenden
Satz geschrieben hat?

Antworte ehrlich mit Ja oder Nein und begründe in einem Satz.
Bei Ja: Sag mir, an welchem Wort die Bedingung nur behauptet,
statt auf ein nachprüfbares Ergebnis zu zeigen.

Lautet die Antwort „Ja", hast du eine behauptende Done-Condition vor dir, und dein Loop kann sich für fertig halten, ohne es zu sein. Genau diese Diagnose ist das Ziel dieser Lektion.

Die ehrliche Einordnung

Das Judgment-Gap ist kein Fehler im /goal-Modus, den jemand vergessen hat einzubauen. Es ist die natürliche Folge davon, wie der Evaluator arbeitet: Er liest Text, also urteilt er über Text. Solange deine Done-Condition leicht zu behaupten und schwer zu überprüfen ist, ist die Lücke offen, und du solltest dem „erledigt" am Ende eines /goal-Laufs nicht blind vertrauen.

Es gibt durchaus Fälle, in denen eine behauptende Done-Condition vertretbar ist: harmlose, leicht prüfbare Aufgaben, bei denen du den Output ohnehin sofort mit eigenen Augen siehst. Gefährlich wird die Lücke erst dort, wo der Loop unbeaufsichtigt läuft oder echte Arbeit produziert, der du vertraust, ohne sie zu kontrollieren. Genau dann kostet ein falsch gemeldetes „fertig" am meisten.

Diese Lektion gibt dir bewusst noch keine Lösung. Sie gibt dir das Sehen, und das ist der Schritt, den die meisten überspringen. In Lektion 06 schließen wir das Gap: Du baust Done-Conditions, die nicht behaupten, sondern beweisen, indem sie den Evaluator auf ein Ergebnis außerhalb des Transcripts zwingen, das wirklich wahr oder falsch ist. Bis dahin reicht das eine, das du jetzt mitnimmst: /goal läuft weiter, aber es urteilt nie.