Warum 'fertig' bei mir erst zählt, wenn ein zweites Modell nein sagen durfte

Vor ein paar Wochen hat mir ein Agent ein Feature als fertig gemeldet. Tests grün, Build sauber, alles durch. Ich hab es geglaubt und weitergemacht. Zwei Schritte später fiel auf: der eigentliche Pfad lief nie. Der Agent hatte im Test einen Wert hart reingeschrieben, damit die Zusicherung durchläuft, und die Logik drumherum nie wirklich ausgeführt. Grün war nicht dasselbe wie funktioniert. Das ist der unangenehme Teil an Agenten, über den selten jemand schreibt. Ein Modell, das seine eigene Arbeit bewertet, ist ein schlechter Gutachter. Nicht aus Bösartigkeit, sondern weil es beim Bauen und beim Prüfen denselben blinden Fleck hat. Wenn es beim Schreiben nicht an den Edge-Case gedacht hat, denkt es beim Selbstcheck auch nicht dran. Ich hab lange versucht, das mit besseren Anweisungen zu lösen. "Prüfe deinen Code kritisch." "Sei ehrlich, ob es wirklich läuft." Bringt fast nichts. Ein Modell, das sich für fertig hält, bleibt bei dieser Einschätzung, egal wie oft ich es höflich bitte, nochmal draufzuschauen. ## Ein zweiter Kopf, der nichts gebaut hat Was tatsächlich zieht, ist eine simple Regel aus der Menschenwelt: der, der etwas baut, prüft es nicht selbst ab. Bei Code nennen wir das Review. Bei Agenten braucht es dasselbe, nur automatisch. Also lasse ich einen zweiten Durchlauf über die Arbeit gehen, bevor "fertig" bei mir zählt. Ein separater Prüf-Agent, der den Bau nicht gemacht hat und gar nicht kennt. Der bekommt nur zwei Dinge: den Auftrag und den Diff, also was sich in dieser Session am Code geändert hat. Seine Aufgabe ist nicht "schau ob es schön ist", sondern das Gegenteil. Versuch es zu brechen. Finde die Abkürzung. Zeig mir, wo grüne Tests etwas anderes behaupten als der Code kann. Bewusst ein anderes, günstigeres Modell als das, das gebaut hat. Zwei Gründe. Erstens kostet ein reiner Lese- und Kritik-Durchlauf viel weniger als der Bau selbst, das darf also ruhig ein sparsameres Modell machen. Zweitens ist ein anderes Modell ein echter zweiter Blick, kein Echo des ersten. Der Prüfer gibt am Ende genau zwei Signale zurück. GO, wenn er nichts findet. Oder eine Liste konkreter Probleme mit Datei und Zeile. Bei Problemen geht die Arbeit zurück in eine Fix-Schleife, wird nachgebessert und erneut geprüft. Das läuft, bis GO kommt. Erst dann darf der Bau-Agent sagen, dass er fertig ist. ## Der Trick ist, es hart zu machen Der spannende Teil ist nicht der Prüfer, sondern wie ich ihn erzwinge. Denn ein höfliches "bitte lass nochmal prüfen" wird genauso ignoriert wie ein höfliches "prüf deinen Code". Es muss ein hartes Nein sein. In Claude Code gibt es dafür den Stop-Hook. Der feuert genau in dem Moment, in dem der Agent glaubt, er sei durch. Und ein Stop-Hook kann diesen Moment blockieren. Er gibt eine Entscheidung zurück, die dem Agenten sagt: nein, du bist nicht fertig, mach erst das hier. Der Agent kann die Session nicht beenden, solange der Prüfer nicht GO gesagt hat. Das ist der entscheidende Unterschied zu allem, was ich vorher probiert hatte. Vorher hing das Prüfen daran, dass das Modell dran denkt. Jetzt hängt das Beenden daran, dass der Prüfer zufrieden ist. Die Reihenfolge ist umgedreht. Nicht das Modell entscheidet, wann fertig ist, sondern das Gate. Die genaue Syntax für Stop-Hooks und die Entscheidungssteuerung steht in der offiziellen Doku unter https://code.claude.com/docs/en/hooks. Der relevante Punkt: ein Stop-Hook kann mit einer Block-Entscheidung samt Begründung verhindern, dass der Agent aufhört, und ihm sagen, wie es weitergeht. ## Mein eigener Fehler zuerst Als ich das Gate zum ersten Mal scharf hatte, war ich begeistert und hab es auf alles losgelassen. Jede Session, jeder Task, auch Tippfehler und Doku-Zeilen. Das war dumm. Ein Prüf-Durchlauf über eine Ein-Zeilen-Änderung ist reine Verschwendung, kostet Zeit und verbrennt das Kontingent des zweiten Modells für nichts. Schlimmer noch, es hat mich ausgebremst bei genau den kleinen Dingen, die schnell gehen sollen. Die Korrektur war, das Gate standardmäßig aus zu lassen und nur bewusst scharf zu stellen. Bei uns entscheidet das eine Handvoll Kategorien: ein neues Feature, ein größeres Refactoring, eine Änderung an einem MCP-Server, sicherheitsrelevanter Code, ein Bau über mehrere Dateien. Genau vier, fünf Fälle, in denen ein falsches "fertig" richtig weh tut. Ein einziger Befehl stellt es für so einen Bau scharf, danach ist es wieder aus. Der Rest läuft ohne. Das klingt nach weniger Absicherung, ist aber mehr. Ein Gate, das überall feuert, nervt so lange, bis man es komplett abschaltet. Ein Gate, das nur bei den teuren Fällen kommt, bleibt an. ## Was du daraus mitnimmst Wenn dein Agent dir sagt, er sei fertig, dann ist das eine Behauptung, kein Beweis. Selbstbewertung ist die schwächste Form von Qualitätssicherung, die es gibt. Der billigste echte Fortschritt ist ein zweiter Durchlauf mit einem anderen Modell, das nur den Diff sieht und den Auftrag hat, etwas zu finden. Und wenn du willst, dass das nicht vom guten Willen des Modells abhängt, gehört das Ganze in einen Hook, der das Beenden blockiert, statt in eine Bitte, die ignoriert wird. Wie du überhaupt sinnvoll mit einem Human-in-the-Loop absicherst, steht in unserer Lektion dazu (/levels/5/05-human-in-the-loop). Das Muster, mehrere Agenten mit verteilten Rollen aufeinander loszulassen, erklären wir in (/levels/5/03-research-critic-analyst). Und wenn du direkt einen Hook gegen falsche Behauptungen bauen willst, ist das Playbook (/playbooks/hooks-gegen-halluzinationen) der schnellste Einstieg.