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 die Folge in den ersten Abschnitt seiner Empfehlungen (externe Seite, code.claude.com): Dann sind Sie selbst die Prüfschleife, und jeder Fehler wartet darauf, dass Sie ihn bemerken.

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. Die Empfehlungen (externe Seite, code.claude.com) zählen als Prüfung alles, was ein Signal zurückgibt, das Claude im Gespräch lesen kann: eine Testsammlung, den Rückgabewert eines Baus, einen Linter, ein Skript, das die Ausgabe mit einer hinterlegten Vorlage vergleicht, oder ein Bildschirmfoto aus dem Browser, das gegen einen Entwurf gehalten wird.

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.

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, und sein Rat (externe Seite, code.claude.com) dazu ist kurz: Claude eine Prüfung geben, die es selbst ausführen kann, also Tests, einen Bau oder ein Bildschirmfoto zum Vergleichen.

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. Die Empfehlungen (externe Seite, code.claude.com) raten zum Zweiten: Claude soll Belege vorlegen, statt den Erfolg zu behaupten.

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.

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 Antwort 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 Antwort heraus. Man formuliert sie einmal als Bedingung, und danach prüft ein eigener Bewerter am Ende jeder Antwort, ob sie erfüllt ist. Der Agent arbeitet weiter, solange sie es nicht ist.

Der Bewerter ist ein kleines Modell, und er führt selbst nichts aus. Die Doku zur Zielbedingung (externe Seite, code.claude.com) sagt, er starte keine Befehle und lese keine Dateien selbst, und rät deshalb, die Bedingung so zu schreiben, dass Claudes eigene Ausgabe sie nachweisen kann.

Die Bedingung braucht also einen Beleg im Gespräch, etwa die Ausgabe des Testlaufs. Das ist dieselbe Gewohnheit wie in Ebene 1, Beweis statt Behauptung, und diesmal liest ein Modell mit. Auch diese Stufe hat eine Kante: Antwortet der Agent mehrmals hintereinander, ohne ein Tool aufzurufen, hält das Werkzeug die Schleife an und gibt an Sie zurück. Die Bedingung bleibt dabei gesetzt.

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 läuft an einem bestimmten Ereignis, und in der Bauart als Befehl ist er ein Skript. Am Ereignis für das Ende einer Antwort kann er den Agenten weiterarbeiten lassen, bis das Skript ohne Fehler durchläuft. Wie das technisch aussieht, steht in Kapitel 12. Die Bedingung aus der zweiten Stufe ist technisch derselbe Hook (externe Seite, code.claude.com), dort urteilt ein Modell anstelle eines Skripts.

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 Antwort trotzdem, damit eine dauerhaft scheiternde Prüfung die Sitzung nicht festsetzt. Wer sich auf den Riegel verlässt, sollte wissen, dass er eine Obergrenze hat. Gezählt werden dabei nur Blockaden ohne Tool Call dazwischen: Arbeitet der Agent, beginnt die Zählung von vorn. Gedeckelt ist also nur ein Agent, der auf jede Abweisung bloß antwortet, und die Grenze lässt sich anheben (externe Seite, code.claude.com).

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. Die Empfehlungen (externe Seite, code.claude.com) lassen dafür ein frisches Modell das Ergebnis zu widerlegen versuchen, damit der Agent, der die Arbeit gemacht hat, sie nicht selbst benotet.

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, oder über einen Workflow, der seine eigenen Befunde gegenprüft. Wie das aufgesetzt wird, steht in Kapitel 13.

Die vierte Stufe hat ihre eigene Schwäche, und der Hersteller nennt sie in seinen Empfehlungen (externe Seite, code.claude.com) selbst: Ein Prüfer, der Lücken finden soll, meldet meistens welche, auch wenn die Arbeit in Ordnung ist, weil genau das sein Auftrag war.

Wer jedem dieser Befunde nachgeht, baut zu viel: zusätzliche Schichten, Abwehrcode, Tests für Fälle, die nicht eintreten können. Der Rat dort lautet, den Prüfer nur melden zu lassen, was die Korrektheit oder die gestellten Anforderungen betrifft.

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 Sicher­heits­richt­linie im Aus­lie­fe­rungs­schritt: 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. Vor jedem Livegang dieser Seite laufen 28 Prüfungen, die meisten über die gebauten Dateien; neun davon starten einen echten Browser, weil sich die Lage eines Elements anders nicht messen lässt. Über ihnen stehen 122 Sonden, die die Prüfungen und die Automaten selbst prüfen (Stand 09.10.2026). Viele davon sind 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 (externe Seite, openai.com) zu einem fünf Monate lang agen­ten­ge­schrie­benen Produkt hält den allgemeinen Fall dazu fest: Aus Sicht des Agenten existiert praktisch nicht, was er während des Laufs nicht im Kontext erreichen kann.

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 in seinen Empfehlungen (externe Seite, code.claude.com) unter den häufigen Fehlerbildern: Claude liefert eine Umsetzung, die plausibel aussieht und die Randfälle nicht behandelt.

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 Kom­man­do­zei­len­um­ge­bung 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 Wie­der­ho­lungs­mel­dungen 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 Kom­man­do­zei­len­um­ge­bungen: 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­über­schrei­tung 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 (externe Seite, code.claude.com) zieht sie deutlich: Was sich nicht prüfen lässt, wird nicht ausgeliefert.

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.

Für die Arbeit mit Agenten hat das eine praktische Folge. Die Einrichtung, die in Kapitel 12 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.