Was bedeutet Agentic Verification?

Der Coding-Agent bekommt einen Weg, seine eigene Arbeit zu prüfen: Er schreibt eine Änderung, startet einen Check, liest das Ergebnis und versucht es erneut, bis der Check besteht. Erst danach sieht ein Mensch das Ergebnis.

Welche Tests sind für Coding-Agenten am wertvollsten?

Wenn du nur eine Art wählen kannst, sind es End-to-End-Tests, weil sie abbilden, was ein echter Nutzer tut, und sich schwer austricksen lassen. Property-Based Tests und Differential-Tests ergänzen sie bei Logik und Migrationen.

Warum schaden langsame oder flaky Tests einem Agenten besonders?

Der Agent lernt aus den Anreizen des Loops. Besteht ein fehlschlagender Test beim Wiederholen manchmal doch, wird Wiederholen zur bevorzugten Strategie. Dauert die Suite lange, läuft sie seltener und der Agent bündelt mehr Änderungen pro Lauf.

Reicht es, Regeln in AGENTS.md oder CLAUDE.md zu schreiben?

Nicht immer. Geoffrey Huntley beschreibt, dass Anweisungen in AGENTS.md driften können. Ein Pre-Commit-Hook, der den Diff prüft und bei einem Verstoß den Commit scheitern lässt und dem Agenten sagt, was er stattdessen nutzen soll, griff bei ihm deutlich zuverlässiger.

Welche Tools gibt es für Property-Based Testing?

Genannt werden fast-check für JavaScript und TypeScript, Hypothesis für Python und proptest für Rust. Sie erzeugen viele Eingaben, um eine Regel zu brechen, und reduzieren einen Fehlschlag auf den minimalen Fall.

Agentic Verification: Coding-Agenten prüfen sich selbst

Warum Verifikation der Engpass bei Coding-Agenten ist und wie E2E-, Property- und Differential-Tests einen Loop bauen, in dem der Agent selbst prüft.

Der Agent erledigt das Ticket in einer Stunde, und dann sitzt du den Rest des Nachmittags vor dem Diff, startest die App, findest einen Bug, erklärst ihn, wartest auf die nächste Runde. Das ist der langsamste und teuerste Loop, den man bauen kann, und er skaliert nicht über einen Menschen hinaus. Addy Osmani bringt das in seinem Essay “Agentic Verification” auf einen Satz: Der Engpass hat sich vom Schreiben des Codes dahin verschoben, zu wissen, ob er korrekt ist.

Die Konsequenz für dein Setup: weniger jede Zeile reviewen, mehr Loops bauen, die der Agent selbst ausführen kann. Ohne Check rät der Agent, und das Raten fängst du dann selbst ab.

Tests als Sensor, nicht nur als Sicherheitsnetz

Tests waren bisher vor allem das Werkzeug, mit dem Menschen Bugs finden und sicher refactorn. Für Agenten kommt eine zweite Rolle dazu: Über Tests nimmt der Agent die Welt wahr und weiß, wann er fertig ist. Läuft der Loop gut, ändert der Agent etwas, lässt den Check laufen, liest die Ausgabe und versucht es so lange, bis er besteht. Osmani sagt dazu klar, er nehme lieber einen deutlich besseren Feedback-Loop als ein etwas besseres Modell.

Dein Review verschiebt sich damit: Du prüfst Belege statt nur Diffs. Verantwortlich für das, was ausgeliefert wird, bleibt trotzdem ein Mensch.

E2E-Tests als Orakel

Wenn du nur eine Testart wählen darfst, dann End-to-End. Ein E2E-Test macht, was ein Nutzer macht: registrieren, Artikel in den Warenkorb, bezahlen, Bestätigung sehen. Die interne Struktur ist ihm egal. Genau deshalb ist er schwer auszutricksen. Ein Unit-Test mit Mocks kann grün sein, während das Feature kaputt ist, weil Agent und Test dasselbe Missverständnis teilen.

Was E2E-Tests für Agenten besonders nützlich macht:

Sie definieren “fertig”. “Bau das Feature” ist vage, “bring diesen E2E-Test auf Grün” ist ein Ziel, das der Agent allein verfolgen kann.
Gute Fehlermeldungen mit Screenshots, Traces und dem fehlgeschlagenen Schritt sagen dem Agenten, was schiefging. Ein nackter Timeout sagt ihm nichts.

Der Trade-off ist real: E2E-Tests sind langsamer und flakier als Unit-Tests. Also eine kleine Menge hochwertiger Flows, nicht alle Pfade. Osmani verweist zusätzlich darauf, dem Agenten Hände und Augen am laufenden System zu geben, etwa über einen gepflegten Skill oder ein CLI, das die App starten, bedienen und beobachten kann, plus eine Feature Map aus Nutzersicht.

Property- und Differential-Tests

Beispieltests sagen, was passieren soll. Properties sagen, was nie passieren darf. Das ist wichtig, weil ein Agent sich sonst eigene Beispiele baut, die zu seiner eigenen Logik passen. Bei Property-Based Tests formulierst du eine Regel, und ein Tool wie fast-check, Hypothesis oder proptest generiert Eingaben, um sie zu brechen, und schrumpft einen Fehlschlag auf den minimalen Fall. Typische Properties: Round-Trip (encode, dann decode ergibt das Original), Invarianten (ein Kontostand wird nie negativ), Idempotenz (zweimal migrieren wirkt wie einmal) und Äquivalenz (optimierte Funktion gleich einfacher Referenz).

Praktisch: mit einer kleinen, reinen Funktion anfangen, die Property erst in Klartext formulieren und den Agenten gezielt nach Properties statt nach Beispielen fragen. Gefundene Minimalfälle als Regressionstest behalten.

Bei Rewrites und Migrationen wird das Altsystem zum Orakel. Differential Testing schickt dieselben Eingaben durch alt und neu und vergleicht die Ausgaben, mit zufällig generierten Eingaben oder einer Stichprobe echten Traffics. Damit das nicht in endlosen Falsch-Diffs endet, normalisierst du alles Irrelevante vor dem Vergleich und führst eine Liste gewollter Abweichungen, jede mit Begründung.

Der Loop muss schnell und deterministisch sein

Der unterschätzte Teil: Der Agent lernt aus den Anreizen des Loops. Besteht ein roter Test beim Wiederholen manchmal doch, wird Wiederholen seine Strategie statt Reparieren. Dauert die Suite lange, läuft sie seltener, der Agent bündelt mehr Änderungen und kann nicht mehr sagen, welche den Fehler verursacht hat. Beides sieht man nicht, man bekommt nur schlechteren Output zum Review.

Was “gut” heißt:

Ein leicht auffindbarer Testbefehl mit Quiet-Flags, schnell genug für jeden Zyklus.
Seeded Randomness, eingefrorene Uhren, kontrolliertes Netzwerk, isolierter State.
Flaky Tests raus aus der Hauptsuite, sofort. Einer reicht, um das Vertrauen in alle anderen Ergebnisse zu zerstören.
Kurze Ausgabe: was fehlschlug, nicht seitenlange Logs über das, was bestand. Jede überflüssige Zeile kostet den Agenten Aufmerksamkeit in jedem Turn.
Schnelle Checks im inneren Loop, schwere E2E- und Diff-Tests vor der Integration.

Fehler in Mechanik verwandeln statt in Prosa

Osmani nennt es “Taste compound”: Wenn der Agent etwas falsch macht, schreib es so fest, dass es nicht zweimal passiert, als geteilte Config, Hook oder Test. Geoffrey Huntley liefert dazu ein Beispiel, das Simon Willison zitiert: Statt in AGENTS.md nachzubessern, dass der Agent seine Diagnostics-Library nutzen soll, was weiter driftet, prüft ein Pre-Commit-Hook den Git-Diff auf direkte Aufrufe der Observability-Module. Bei einem Treffer scheitert der Commit, und der Agent bekommt die Anweisung, die Library zu nutzen. Danach traf es laut Huntley jedes Mal.

Das deckt sich mit dem Grundgedanken hinter Claude Code Hooks: Eine Regel, die ausgeführt wird, schlägt eine Regel, die nur im Kontext steht.

Was das für deinen Workflow bedeutet

Lass den Agenten vor dem Coden die Erfolgskriterien in eigenen Worten wiedergeben.
Gib ihm einen Testbefehl, der schnell, deterministisch und knapp in der Ausgabe ist, und dokumentier ihn so, dass er ihn findet.
Bau eine kleine Menge E2E-Flows als Definition von “fertig”.
Frag bei neuer Logik nach Properties, bei Migrationen nach einem Differential-Harness.
Prüf verifizierende Arbeit mit frischem Kontext oder einem separaten Reviewer-Agenten, etwa als Subagent, und behandle generierte Tests selbst als prüfwürdig: Unterscheiden sie korrekte von plausibel falschen Implementierungen?
Jeder wiederkehrende Fehler wird zu Hook, Test oder Config, nicht zu einer weiteren Zeile Prosa.

Die Testinfrastruktur ist damit eine Komponente, von der der Agent abhängt, und jede Verbesserung wirkt auf alle künftigen Tasks.

Du willst wissen, ob dein Repo dem Agenten einen brauchbaren Verifikations-Loop bietet, von CLAUDE.md über Hooks bis zum CI-Workflow? Das Agent-Setup-Review schaut genau darauf und liefert priorisierte Änderungsvorschläge. Setup-Review anfragen.