Prüfen statt glauben

Die sechs Kapitel davor haben eingerichtet, was ein Agent vorfindet: eine Projektanweisung, eine Historie, ein Gedächtnis, eine Wissensbasis. Alles davon verbessert die Ausgangslage. Nichts davon beantwortet die Frage, ob das Ergebnis stimmt.

Fertig aussehen ist das einzige Signal

Ein Agent arbeitet, bis er meint, fertig zu sein. Woran er das erkennt, ist die entscheidende Stelle: Ohne eine Prüfung, die er selbst laufen lassen kann, bleibt ihm allein der Anschein. Der Hersteller schreibt es in den ersten Abschnitt seiner Empfehlungen:

you become the verification loop: every mistake waits for you to notice it (externe Seite, code.claude.com)

Das ist die Sorte Fehler, die man erst spät bemerkt. Der Code liest sich plausibel, die Erklärung klingt schlüssig, und dass etwas fehlt, zeigt sich Tage später an einer Stelle, die niemand mit dieser Sitzung in Verbindung bringt.

Was als Prüfung zählt

Eine Prüfung ist in diesem Zusammenhang etwas sehr Schlichtes: ein Vorgang, der ein Ergebnis liefert, das der Agent lesen kann, und der zwei Ausgänge hat.

The check is anything that returns a signal Claude can read in the conversation: a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot compared against a design. (externe Seite, code.claude.com)

Fünf Formen, und keine davon ist aufwendig. Ein Bau, der abbricht, ist bereits eine Prüfung. Ein Vergleich der Ausgabe gegen eine hinterlegte Erwartung ist zwanzig Zeilen. Der Wert steckt darin, dass am Ende zwei Zustände stehen und der Agent den Unterschied lesen kann, und ganz und gar nicht in der Ausgefeiltheit.

seitlich verschiebbar

eigene Darstellung, Stand 04.08.2026

Wer die Schleife schließt

Der Unterschied liegt bei der Anwesenheit. Gründlicher wird dadurch niemand. Mit einer Prüfung arbeitet der Agent, führt sie aus, liest das Ergebnis und macht weiter, bis sie durchgeht. Ohne eine Prüfung übernimmt diese Rolle ein Mensch, der dafür hinsehen muss.

Der Hersteller formuliert es als Unterschied zwischen zwei Arbeitsweisen:

Give Claude a check it can run: tests, a build, a screenshot to compare. (externe Seite, code.claude.com)

Praktisch heißt das für den Auftrag: Wer eine Funktion bestellt, nennt am besten gleich zwei oder drei Beispiele, bei denen klar ist, was herauskommen muss, und bittet darum, die Prüfung nach dem Bauen auch auszuführen. Das kostet einen Satz und ändert den Charakter der Sitzung.

Beweis statt Behauptung

Die zweite Gewohnheit ist noch billiger. Ein Agent kann berichten, dass etwas funktioniert, und er kann zeigen, woran er das sieht.

Have Claude show evidence rather than asserting success (externe Seite, code.claude.com)

Die Ausgabe des Testlaufs, der Befehl mit seiner Antwort, das Bild des Ergebnisses. Das durchzusehen geht schneller, als es selbst noch einmal nachzustellen, und es funktioniert auch dann, wenn man beim Arbeiten nicht zugesehen hat.

Wo es trotzdem hakt

Zwei Dinge, die dieses Kapitel in den folgenden Ebenen ausführt.

Erstens läuft eine Prüfung nur, wenn sie tatsächlich läuft. Ein Agent, der sie überspringen kann, überspringt sie irgendwann, und eine übersprungene Prüfung sieht von außen genauso aus wie eine bestandene.

Zweitens misst eine Prüfung nur das, was sie misst. Beides sind eigene Fehlerklassen, und die zweite ist die unangenehmere: Sie erzeugt ein grünes Ergebnis, das nichts bedeutet.

Eine Prüfung zu haben ist die eine Frage. Die zweite ist, wie verbindlich sie ist: Ob der Agent sie ausführen soll, ausführen muss oder ohne sie gar nicht aufhören darf. Der Hersteller unterscheidet dafür vier Stufen, und sie unterscheiden sich in genau einer Größe.

Vier Stufen, ein Tauschgeschäft

Jede Stufe verlangt mehr Einrichtung und braucht dafür weniger Aufmerksamkeit im Betrieb. Die erste funktioniert sofort und in jeder Sitzung, die letzte sichert einen Lauf, bei dem niemand zusieht.

Stufe	Wo sie sitzt	Was sie kostet
Im Auftrag	ein Satz im Prompt	nichts
Über die Sitzung	eine Zielbedingung	einmal formulieren
Als Riegel	ein Hook, der das Ende blockiert	ein Skript
Als zweite Meinung	ein eigener Prüfer	ein Subagent

seitlich verschiebbar

eigene Darstellung nach Anthropic, Best practices for Claude Code, Stand 04.08.2026

Der Satz im Auftrag

Die einfachste Form steht im Auftrag selbst: bauen, prüfen und wiederholen, bis die Prüfung durchgeht. Das wirkt genau für diese eine Runde und ist deshalb nichts, worauf man sich verlässt, wenn man weggeht.

Wichtig ist dabei die Richtung der Bitte. Ein Agent, dessen Bau scheitert, hat zwei Wege: die Ursache beheben oder die Meldung stillstellen. Beide führen zu einem grünen Ergebnis, und nur einer davon hilft. Der Auftrag sagt deshalb besser dazu, dass die Ursache gemeint ist.

Die Bedingung über die ganze Sitzung

Die zweite Stufe hebt die Prüfung aus der einzelnen Runde heraus. Man formuliert sie einmal als Bedingung, und danach prüft ein eigener Bewerter nach jeder Runde, ob sie erfüllt ist. Der Agent arbeitet weiter, solange sie es nicht ist.

Der Unterschied zur ersten Stufe zeigt sich beim Verdichten. Ein Satz im Auftrag steht im Gesprächsverlauf und wird zusammengefasst, siehe Kapitel 05. Eine Bedingung liegt daneben und gilt weiter.

Der Riegel

Die dritte Stufe verlässt das Modell. Ein Hook ist ein Programm, das an einem bestimmten Ereignis läuft, und am Ereignis für das Rundenende kann er die Runde offen halten, bis sein Skript ohne Fehler durchläuft. Wie das technisch aussieht, steht in Kapitel 08.

Eine Kante gehört hierher, weil sie leicht zu übersehen ist: Auch dieser Riegel gibt irgendwann nach. Nach acht Blockaden hintereinander beendet das Werkzeug die Runde trotzdem, damit eine dauerhaft scheiternde Prüfung die Sitzung nicht festsetzt. Wer sich auf den Riegel verlässt, sollte also wissen, dass er eine Obergrenze hat.

Die zweite Meinung

Die vierte Stufe ist die interessanteste, weil sie ein anderes Problem angeht. Die ersten drei prüfen das Ergebnis gegen etwas Festes. Diese hier lässt ein zweites Modell versuchen, den Befund umzustoßen:

a fresh model try to refute the result, so the agent doing the work isn’t the one grading it (externe Seite, code.claude.com)

Der zweite Teil des Satzes ist der Grund. Wer eine Aufgabe gelöst hat, kennt seinen Weg dorthin und liest das Ergebnis mit diesem Wissen. Ein Prüfer, der den Weg nicht kennt, sieht nur, was dasteht.

Praktisch läuft das über einen Subagenten, der den Unterschied in einem frischen Fenster bekommt, dazu die Maßstäbe. Wie das aufgesetzt wird, steht in Kapitel 09.

Woher die Prüfung kommt

Die vier Stufen sagen, wie hart eine Prüfung blockiert. Offen bleibt, was überhaupt geprüft wird, und dort liegt der übliche Denkfehler: Gesucht wird ein Test, den erst jemand schreiben muss.

Die meisten Prüfungen stehen schon da. Ein Compiler, der einen Tippfehler meldet, ein Typsystem, das eine Signatur ablehnt, ein Schema, das ein Pflichtfeld einfordert, ein Linter, eine Sicherheitsrichtlinie im Auslieferungsschritt: Jedes davon entscheidet eine Bedingung und sagt das Ergebnis in einem Rückgabewert. Mehr braucht ein Riegel nicht. Test heißt keines davon.

Dazu kommen die Prüfungen, die ein Projekt sich selbst gibt. Diese Seite fährt dreizehn Prüfläufe über die gebauten Dateien und sechsundzwanzig Prüfstände über die Prüfläufe selbst; vier davon starten einen echten Browser, weil sich die Lage eines Elements anders nicht messen lässt. Jeder einzelne ist entstanden, nachdem etwas durchgerutscht war.

Beim Suchen zählt deshalb der Ausgang: Gibt es eine Bedingung, die eine Maschine entscheiden kann, und sagt sie es in einem Rückgabewert. Wo die Antwort ja lautet, ist der Rest Einrichtung. Wo sie nein lautet, hilft auch die vierte Stufe nur begrenzt, denn ein zweites Modell braucht ebenfalls einen Maßstab.

Wo die Schleife das Falsche belohnt

Zwei Fehlerbilder treten regelmäßig auf, und beide erzeugen ein grünes Ergebnis.

Das erste ist die angepasste Erwartung. Der Agent bekommt eine Prüfung, die er verändern darf, und irgendwann verändert er sie, statt den Fehler zu suchen. Das ist meist die kürzere Strecke zu dem Ziel, das man ihm gegeben hat, und selten böse Absicht. Die Gegenmaßnahme ist eine Frage der Zuständigkeit: Wer prüft, schreibt die Erwartung nicht selbst um.

Am deutlichsten wird diese Trennung, wenn die Erwartung schon vor der Arbeit dasteht. Dann ist der Test die Beschreibung der Aufgabe, und jede Änderung daran fällt im Unterschied auf. Was das an Einrichtung verlangt und was dazu gemessen ist, steht in Erst der rote Test.

Das zweite ist die Prüfung, die es zwar gibt, die aber nicht läuft. Ein fehlendes Werkzeug, ein Skript, das nicht gefunden wird, ein stiller Fallback-Pfad, der bei einem Fehler einfach nichts tut. Der Bericht von OpenAI zu einem fünf Monate lang agentengeschriebenen Produkt hält den allgemeinen Fall dazu fest:

From the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist (externe Seite, openai.com)

Für Prüfungen gilt derselbe Satz in scharfer Form. Was nicht läuft, existiert nicht, und ein Lauf, der nichts prüft, gibt trotzdem Null zurück.

Die beiden Ebenen davor behandeln die Frage, ob eine Prüfung da ist und wie hart sie greift. Diese Ebene behandelt die Frage danach: ob sie das misst, wofür man sie aufgestellt hat.

Der Hersteller führt den Ausgangsfall unter den häufigen Fehlerbildern:

Claude produces a plausible-looking implementation that doesn’t handle edge cases. (externe Seite, code.claude.com)

Die Abhilfe dort ist eine Prüfung. Was er offen lässt, ist der Fall eine Etage tiefer: eine Prüfung, die selbst plausibel aussieht.

Ein grünes Ergebnis, das nichts bedeutet

Eine Prüfung hat zwei Ausgänge, und über Wochen hinweg sieht man fast immer denselben. Genau darin liegt die Schwierigkeit: Ein Prüfstand, der nie anschlägt, ist von einem, der nichts messen kann, äußerlich nicht zu unterscheiden. Beide laufen durch, beide geben Null zurück, beide erscheinen grün.

Die drei folgenden Fälle stammen aus dem Betrieb dieser Website. Sie sind verschiedene Fehler und dieselbe Klasse.

seitlich verschiebbar

eigene Darstellung, Stand 04.08.2026

Der Prüfstand wechselte die Umgebung

Ein Prüfstand für einen Freigabelauf rief das zu prüfende Skript mit einer anderen Kommandozeilenumgebung auf als der Betrieb. Die beiden gehen mit unquotierten Variablen verschieden um: Die eine zerlegt den Inhalt in mehrere Argumente, die andere reicht ihn als eines weiter.

Der Prüfstand meldete daraufhin einen Fehler, den es im Betrieb gar nicht gab. Ärgerlich, aber harmlos, weil ein Fehlalarm auffällt. Die gefährliche Richtung ist die andere: Hätte der echte Aufruf die Eigenart gebraucht, die nur der Prüfstand mitbrachte, wäre der Fehler unsichtbar geblieben und der Prüfstand grün.

Daraus folgt eine Regel, die einfach klingt und selten eingehalten wird: Ein Prüfstand startet seinen Prüfling so, wie der Betrieb ihn startet. Jede Vereinfachung an dieser Stelle prüft ein anderes Programm.

Die gekürzte Ausgabe

Ein zweiter Prüfstand reichte seinem Prüfling drei Zeilen Ausgabe herein, weil das für die Sache zu genügen schien. Der Prüfling liest darin nach einem Grund für einen Abbruch, und in einer dreizeiligen Ausgabe steht der Grund zwangsläufig in den ersten drei Zeilen.

Im Betrieb stehen davor Angaben, die sich jede Nacht ändern. Genau daran hängen zwei Eigenschaften, die der Prüfstand belegen sollte: dass der Grund überhaupt in der Meldung landet, und dass eine Sperre gegen Wiederholungsmeldungen hält. Mit vollständiger Ausgabe fielen gegen die kaputte Fassung sieben Prüfungen durch statt drei.

Der Regelfall war der einzige ungeprüfte Pfad

Der dritte Fall ist der unangenehmste, weil er lange gut ging. Ein nächtlicher Lauf brach jede Nacht nach einer Sekunde ab. Die Ursache war eine Eigenheit älterer Kommandozeilenumgebungen: Ein leeres Feld gilt dort unter einer bestimmten Einstellung als nicht gesetzt, und leer war es genau dann, wenn keine der beiden Steuervariablen gesetzt war.

Der dokumentierte Test setzte eine davon. Damit war das Feld gefüllt, der Test lief durch, und er war grün, während der Produktionsfall jede Nacht scheiterte.

Die Prüfliste deckte jeden Sonderfall ab und den Regelfall nicht. Dasselbe Muster kam am selben Projekt ein zweites Mal vor: Ein anderer Lauf blockierte sich mit seiner eigenen Sperre, gefunden beim ersten echten Dry Run, nachdem 46 Prüfungen grün gewesen waren. Sie hatten den Start nur in Fällen gefahren, in denen vorher schon etwas anderes abbrach.

Der Nachweis, der dazugehört

Aus den drei Fällen folgt eine Praxis, die den Aufwand ungefähr verdoppelt und den Nutzen erst herstellt: Ein Prüfstand muss zeigen, dass er anschlägt.

Dafür lässt man ihn einmal gegen die kaputte Fassung laufen. Fällt er dort durch und schweigt gegen die reparierte, misst er etwas. Läuft er in beiden Fällen durch, ist er Zierde. In diesem Projekt hat dieser Nachweis mehrfach den Prüfstand selbst widerlegt, zuletzt bei einem, dessen drei Prüfungen nur deshalb bestanden, weil er seinen Prüfling in eine Zeitüberschreitung laufen ließ und dessen Schweigen als Erfolg verbuchte.

Der Aufwand ist derselbe wie beim Prüfen von Anwendungscode, und die Begründung ebenso: Ein Prüfstand ist Code, den niemand prüft.

Wo die Grenze liegt

Ein Satz aus derselben Sammlung von Fehlerbildern zieht sie deutlich:

If you can’t verify it, don’t ship it. (externe Seite, code.claude.com)

Das ist strenger, als es zunächst klingt, denn es gilt auch für die Prüfung selbst. Wer nicht sagen kann, woran er merken würde, dass sein Prüfstand kaputt ist, hat eine Gewohnheit und keinen Prüfstand.

Für die Arbeit mit Agenten hat das eine praktische Folge. Die Einrichtung, die in Kapitel 08 beschrieben wird, verlagert Verlässlichkeit vom Modell in Programme daneben. Damit verlagert sie auch die Frage: Vorher hieß sie, ob das Modell die Regel befolgt. Jetzt heißt sie, ob das Programm daneben tut, was auf ihm steht.