AIDive

Video-Paket

Claude Code Verifikationsloops: Benchmark-Tabelle, Stop-Hook-Checkliste und Quellen

10 Min. Lesezeit

TL;DR

  • Anthropics eigene Empfehlung stimmt im Kern: Das Modell, das einen Feedback-Loop bekommt, liefert bessere Arbeit. Das Problem ist, wer den Loop ausführt. In 116 Läufen gab das eingebaute /verify 24 von 24 Mal PASS zurück, auch bei einer Änderung, die eine genannte Anforderung brach.
  • Ein Modell, das seine eigene Änderung prüft, teilt deren blinden Fleck. Haiku 4.5 übersah denselben Fall mit eindeutigen Feldern in 11 von 11 Läufen, in jedem Setup mit demselben Modell, und sein eigenes /verify setzte einen Haken neben den falschen Fall.
  • Auf Opus 5.5 kostete /verify das 2.5-fache ($0.96 gegen $0.39) und änderte kein Ergebnis. Opus ohne alles lag 12 von 12 richtig und führte die Testsuite in 11 dieser Läufe von selbst aus.
  • Ein Projekt-Skill ist für das Modell optional: Er wurde in 10 von 24 Läufen ausgelöst, bei Haiku in 0 von 6. Ein Stop-Hook lief in jedem Lauf, für etwa 20 % Mehrkosten auf Opus.
  • Die Prüfung, die funktionierte, kam von außerhalb des Autors: Dasselbe /verify, von Opus ausgeführt, sagte 3 von 3 Mal FAIL zu Haikus Änderung und benannte den Bug. Als Stop-Hook verdrahtet brachte es Haiku 3 von 3 Mal dazu, den Bug zu beheben, für $1.36 pro Aufgabe gegen $0.76, wenn Opus die Aufgabe allein schreibt.
  • Zum Übernehmen: ein Stop-Hook für den deterministischen Teil, ein Prüfer, der nicht der Autor ist, für den Teil, der Urteilsvermögen braucht, und kein /verify auf Opus bei gut spezifizierter Arbeit.

Was die Messungen zeigen

Anthropics Aussage: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Der Blog macht daraus einen Einführungs-Workflow in 5 Schritten: die am häufigsten wiederholte manuelle Prüfung wählen, das eingebaute /verify ausprobieren, das Vorgehen in einfachem Englisch als Skill aufschreiben, es deterministisch machen, dann in die CI verschieben. s1 Seit v2.1.215 gilt: "Claude no longer runs the /verify and /code-review skills on its own; invoke them with /verify or /code-review when you want them." s3

Die Praxisberichte drehen sich um Verifikation, die behauptet, aber nicht ausgeführt wurde. Issue #96416 ist ein Review-Urteil mit 19 Bedenken, davon 5 geprüft, und trotzdem ein "accept as-is". s6 Issue #97039 ist eine "held up"-Behauptung nach Teilprüfungen trotz geladener Checkliste. s7 "build passes" und "production-ready" sind unterschiedliche Messlatten, und jeder Fehlgriff kostet 2-3 Runden Nachprompten. s8

Unser Benchmark bewertete jedes "done" mit versteckten Akzeptanztests, die der Agent nie sah. 112 Aufgabenläufe + 4 modellübergreifende /verify-Läufe = 116 Läufe, $66.29 API-äquivalente Kosten. Falsches "done": 12 von 112, davon 11 Haiku auf T6 in jedem Setup von A bis E, 1 Sonnet auf T6 mit dem Skill-Setup, wo seine eigenen neuen Tests fehlschlugen und der Skill nie ausgelöst wurde. s1

Das eingebaute /verify sagte Verdict: PASS in 24 von 24 Läufen über die drei Modelle (23 auswertbar, 1 Pass ohne Label), auch bei Haikus kaputtem T6. Auf Opus kostete es $0.96 gegen $0.39 ohne (2.5x) und 125 s gegen 75 s; es änderte kein Ergebnis. s3

Der nach dem 5-Schritte-Workflow geschriebene Projekt-Skill wurde in 10 von 24 Läufen aufgerufen: Opus 8/12, Sonnet 2/6, Haiku 0/6. Der Stop-Hook lief in jedem Lauf, für $0.47 gegen $0.39 auf Opus (+20 %). s19

Der blinde Fleck ist eine Anforderung, T6 Anf. 4: Ein einzelnes update, das mehreren gefundenen Dokumenten denselben eindeutigen Wert gibt, muss DuplicateKeyError auslösen. Haiku übersah das in 11 von 11 Läufen, in jedem Setup (plain, /verify, Skill, Hook, Tests zuerst). Haikus eigenes /verify prüfte "update one doc onto another's email" und probierte nie ein Update, das mehrere Dokumente trifft. Die Tests-zuerst-Regel half nicht: 3/3 verfehlen Anf. 4 weiterhin, und einer brach zusätzlich Anf. 3. s1

Dieselbe Haiku-Änderung, /verify von einem anderen Modell ausgeführt: Sonnet sagte PASS (1/1), Opus sagte 3/3 FAIL, jeder Lauf nannte denselben Fall, ein Update, das denselben Wert in mehrere Dokumente schreibt, für $0.39 bis $0.47 pro Prüfung. Als Stop-Hook auf Haiku (Setup F) brachte der Opus-Prüfer den Bug in 3 von 3 Läufen zur Behebung; alle drei erreichten dabei das Limit von 60 Zügen, bei durchschnittlich $1.36 pro T6-Lauf inklusive Prüfer, gegen $0.76 für Opus, das T6 allein schrieb, mit 0 falschem "done". s19

Messungen

Harness: Claude Code 2.1.283 headless (claude -p), isoliertes Config-Verzeichnis, gleicher Prompt pro Aufgabe, Limit von 60 Zügen. Repo: msiemens/tinydb @ 18d73a1 (Python, 226 Tests). Sechs Feature-Requests T1 bis T6 mit je 5 genannten Anforderungen (T5: 6). Versteckte Akzeptanztests, einer pro genannter Anforderung und dem Agenten nie gezeigt, bewerten jeden Lauf; die eigene Suite des Repos läuft ebenfalls. Ein falsches "done" ist ein Lauf, der mit der Behauptung endete, fertig zu sein, während ein versteckter Test oder die Repo-Suite fehlschlägt.

Setups: A plain (nur die Anfrage); B /verify (A, dann das eingebaute /verify als zweiter Zug); C verify skill (ein vom Modell aufrufbarer Projekt-Skill, geschrieben nach dem 5-Schritte-Workflow); D Stop hook (prove-it.py: blockiert das Beenden, solange die Suite rot ist, und blockiert den ersten Stopp mit der Forderung nach einer Zeile Beleg pro Anforderung); E tests first (eine CLAUDE.md-Regel: ein fehlschlagender Test pro Anforderung vor jedem Code); F Opus verifier hook (claude -p /verify --model opus auf die Änderung, blockiert bei einem Nicht-PASS-Urteil, max. 2 Runden).

Modell Setup Läufe falsches done Ø Kosten Ø Züge Ø Laufzeit
Opus 5.5 A plain 12 0 $0.39 16.6 75 s
Opus 5.5 B /verify 12 0 $0.96 22.3 125 s
Opus 5.5 C skill 12 0 $0.43 19.5 80 s
Opus 5.5 D hook 12 0 $0.47 19.8 94 s
Opus 5.5 E tests first 2 (T6) 0 $0.64 18.5 129 s
Sonnet 5 A 7 0 $0.44 24.0 112 s
Sonnet 5 B 6 0 $1.18 36.3 210 s
Sonnet 5 C 7 1 $0.48 25.7 136 s
Sonnet 5 D 6 0 $0.53 27.0 157 s
Haiku 4.5 A 8 3 $0.34 35.4 172 s
Haiku 4.5 B 6 1 $0.68 43.3 217 s
Haiku 4.5 C 6 1 $0.26 28.2 124 s
Haiku 4.5 D 8 3 $0.37 38.9 179 s
Haiku 4.5 E 3 (T6) 3 $0.41 38.3 186 s
Haiku 4.5 F Opus verifier 3 (T6) 0 $1.36 inkl. Prüfer 61 (Limit) 457 s
Sonnet 5 F 1 (T6) 0 $2.30 inkl. Prüfer 50 512 s

Grenzen: ein Repo (eine kleine, gut getestete Python-Bibliothek), sechs gut spezifizierte Requests, 1 bis 3 Wiederholungen pro Zelle, Headless-Läufe. Die versteckten Tests prüfen nur, was die Anfrage nennt.

Das machst du am Montag

  • Schreibe selbst einen Akzeptanztest pro genannter Anforderung, bevor du das "done" des Modells liest. Die versteckten Tests des Benchmarks fanden, was jede Prüfung mit demselben Modell übersah.
  • Füge einen Stop-Hook hinzu, der deine Testsuite ausführt und eine Block-Entscheidung zurückgibt, solange sie rot ist. Er läuft in jedem Lauf; ein Skill nicht.
  • Mach den ersten Stopp einer Aufgabe an eine Zeile Beleg pro Anforderung gebunden (das prove-it.py-Muster): ein Befehl und seine Ausgabe, kein Satz.
  • Leite die Urteilsprüfung an ein Modell, das die Änderung nicht geschrieben hat: claude -p /verify --model opus auf den Diff, blockierend bei einem Nicht-PASS-Urteil, auf 2 Runden begrenzt.
  • Hör auf Opus 5.5 bei gut spezifizierten Requests auf, aus Gewohnheit /verify zu tippen. Es kostete 2.5x und änderte in 12 Läufen nichts; heb es für Bereiche ohne Tests oder die Suche nach einem bestehenden Bug auf.
  • Wenn du aus Kostengründen an Haiku 4.5 delegierst, plane den Prüfer ein: $1.36 pro Aufgabe mit dem Opus-Hook gegen $0.76, wenn Opus allein schreibt.
  • Protokolliere jeden Wiederholungsversuch eines fehlgeschlagenen Fixes in einem Ledger und stoppe den Loop nach einer Wiederholung, damit ein blockierender Hook keine Tokens an demselben falschen Patch verbrennt.
  • Lies deine Anforderungen noch einmal auf den Fall mit mehreren Zeilen: "ein Update, das mehrere Dokumente trifft" ist die Form des Falls, den 11 von 11 Haiku-Läufen nie probierten.

Weiterlesen

  • Der 5-Schritte-Workflow und die Reifeleiter, von der manuellen Prüfung bis zum CI-Gate: Die oberen Stufen (CI- und PR-Gates) sind der Ort für den deterministischen Teil, sobald dein Hook lokal läuft. s1
  • Stop-Hook-Semantik: Eine Block-Entscheidung mit Begründung schickt den Zug zurück an das Modell; lies den Exit-Code- und JSON-Vertrag, bevor du ein eigenes Gate schreibst. s19
  • Groundtruth, ein Stop-Hook, der das Ende des Zugs verweigert, bis die Prüfungen bestehen: die deterministische Version der Idee, als Referenzimplementierung lesbar. s5
  • regressionledger, die Kostenseite: ein Hook, der verhindert, dass der Loop denselben fehlgeschlagenen Fix erneut versucht, das Stück, das unserem Stop-Hook fehlte, als Läufe das 60-Züge-Limit erreichten. s10

Quellen

FAQ

Findet das eingebaute /verify Bugs?

Nicht in diesem Benchmark. Es gab in 24 von 24 Läufen über Opus 5.5, Sonnet 5 und Haiku 4.5 PASS zurück, auch bei einer Haiku-Änderung, die eine genannte Anforderung brach. Sein einziger nützlicher Fund war ein bereits bestehender Upstream-Bug, der nichts mit der Änderung zu tun hatte.

Warum hilft ein stärkerer Prüfer einem schwächeren Autor?

Haikus eigene Prüfung testete den Fall, an den es schon gedacht hatte. Opus probierte bei derselben Änderung und demselben /verify ein Update, das mehrere Dokumente trifft, und sagte 3 von 3 Mal FAIL. Sonnet sagte PASS. Der Prüfer muss einen Fall sehen, den der Autor nicht gesehen hat.

Ist es billiger, Haiku mit Opus zu prüfen oder gleich mit Opus zu schreiben?

Mit Opus schreiben. Der Opus-Prüfer-Hook auf Haiku kostete im Schnitt $1.36 pro T6-Lauf und erreichte jedes Mal das 60-Züge-Limit; Opus allein auf T6 lag im Schnitt bei $0.76 mit 0 falschem "done".