AIDiveTL;DR
- Zalecenie samego Anthropic jest słuszne co do zasady: model, który dostaje pętlę zwrotną, pracuje lepiej. Problem w tym, kto tę pętlę uruchamia. W 116 przebiegach wbudowane
/verifyzwróciło PASS 24 razy na 24, także przy zmianie, która łamała jedno z podanych wymagań. - Model sprawdzający własną zmianę ma ten sam ślepy punkt. Haiku 4.5 pominął ten sam przypadek pola unikalnego w 11 z 11 przebiegów, w każdej konfiguracji z tym samym modelem, a jego własne
/verifypostawiło ptaszek przy złym przypadku. - Na Opus 5.5
/verifykosztowało 2.5 razy więcej ($0.96 wobec $0.39) i nie zmieniło żadnego wyniku. Zwykły Opus trafił 12 na 12 i w 11 z tych przebiegów sam uruchomił zestaw testów. - Skill projektu jest dla modelu opcjonalny: uruchomił się w 10 z 24 przebiegów, w 0 z 6 na Haiku. Stop hook odpalił w każdym przebiegu, za około 20% więcej na Opus.
- Kontrola, która zadziałała, przyszła spoza autora: to samo
/verifyuruchomione przez Opus powiedziało FAIL 3 razy na 3 przy zmianie Haiku i wskazało błąd. Podpięte jako Stop hook sprawiło, że Haiku naprawił błąd 3 razy na 3, po $1.36 za zadanie wobec $0.76 dla Opus piszącego zadanie samodzielnie. - Skopiuj to: Stop hook do części deterministycznej, weryfikator, który nie jest autorem, do oceny, i żadnego
/verifyna Opus przy dobrze opisanych zadaniach.
What the measurements say
Teza Anthropic: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Blog zamienia ją w 5-krokowy plan wdrożenia: wybierz swoją najczęściej powtarzaną ręczną kontrolę, wypróbuj wbudowane /verify, opisz procedurę zwykłym językiem jako skill, uczyń ją deterministyczną, potem przenieś do CI. s1 Od v2.1.215 "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
Zgłoszenia z praktyki dotyczą weryfikacji deklarowanej, ale niewykonanej. Issue #96416 to werdykt review z 19 zastrzeżeniami, z których 5 sprawdzono, i mimo to wydane "accept as-is". s6 Issue #97039 to deklaracja "held up" po częściowych kontrolach mimo wczytanej checklisty. s7 "build passes" i "production-ready" to różne poprzeczki, a każda pomyłka kosztuje 2-3 rundy ponownego promptowania. s8
Nasz bench oceniał każde "done" ukrytymi testami akceptacyjnymi, których agent nigdy nie widział. 112 przebiegów zadań + 4 przebiegi /verify między modelami = 116 przebiegów, $66.29 wydatków w przeliczeniu na API. Fałszywe "done": 12 z 112, z czego 11 to Haiku na T6 w każdej konfiguracji od A do E, a 1 to Sonnet na T6 z konfiguracją ze skillem, gdzie jego własne nowe testy nie przechodziły, a skill się nie uruchomił. s1
Wbudowane /verify powiedziało Verdict: PASS w 24 z 24 przebiegów na trzech modelach (23 do sparsowania, 1 pass bez etykiety), także przy zepsutym T6 Haiku. Na Opus kosztowało $0.96 wobec $0.39 bez niego (2.5 razy) i 125 s wobec 75 s; nie zmieniło żadnego wyniku. s3
Skill projektu napisany według 5-krokowego planu został wywołany w 10 z 24 przebiegów: Opus 8/12, Sonnet 2/6, Haiku 0/6. Stop hook odpalił w każdym przebiegu, po $0.47 wobec $0.39 na Opus (+20 %). s19
Ślepy punkt to jedno wymaganie, T6 req 4: pojedynczy update, który nadaje kilku pasującym dokumentom tę samą unikalną wartość, musi rzucić DuplicateKeyError. Haiku pominął je w 11 z 11 przebiegów, w każdej konfiguracji (plain, /verify, skill, hook, tests first). Własne /verify Haiku sprawdziło "update one doc onto another's email" i nigdy nie spróbowało jednego update'u trafiającego w kilka dokumentów. Reguła tests-first nie pomogła: nadal 3/3 pomija req 4, a jeden przebieg złamał też req 3. s1
Ta sama zmiana Haiku, /verify uruchomione przez inny model: Sonnet powiedział PASS (1/1), Opus powiedział FAIL 3/3, a każdy przebieg wskazał ten sam przypadek, jeden update zapisujący tę samą wartość do kilku dokumentów, po $0.39 do $0.47 za kontrolę. Jako Stop hook na Haiku (konfiguracja F) weryfikator Opus doprowadził do naprawy błędu w 3 z 3 przebiegów; wszystkie trzy dobiły do limitu 60 tur podczas naprawy, ze średnim kosztem $1.36 za przebieg T6 wraz z weryfikatorem, wobec $0.76 dla Opus piszącego T6 samodzielnie i 0 fałszywych "done". s19
Measurements
Harness: Claude Code 2.1.283 headless (claude -p), izolowany katalog konfiguracji, ten sam prompt na zadanie, limit 60 tur. Repo: msiemens/tinydb @ 18d73a1 (Python, 226 testów). Sześć próśb o funkcję T1 do T6 po 5 podanych wymagań (T5: 6). Ukryte testy akceptacyjne, po jednym na każde podane wymaganie i nigdy niepokazywane agentowi, oceniają każdy przebieg; uruchamiany jest też zestaw testów repo. Fałszywe "done" to przebieg, który zakończył się deklaracją ukończenia, podczas gdy ukryty test lub zestaw repo nie przechodzi.
Konfiguracje: A plain (sama prośba); B /verify (A, potem wbudowane /verify jako druga tura); C verify skill (skill projektu wywoływany przez model, napisany według 5-krokowego planu); D Stop hook (prove-it.py: blokuje zakończenie, dopóki zestaw testów jest czerwony, i blokuje pierwsze zakończenie, żądając jednej linii dowodu na wymaganie); E tests first (reguła w CLAUDE.md: padający test na każde wymaganie przed jakimkolwiek kodem); F Opus verifier hook (claude -p /verify --model opus na zmianie, blokuje przy werdykcie innym niż PASS, maks. 2 rundy).
| model | setup | runs | false done | avg cost | avg turns | avg wall |
|---|---|---|---|---|---|---|
| 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 z weryfikatorem | 61 (cap) | 457 s |
| Sonnet 5 | F | 1 (T6) | 0 | $2.30 z weryfikatorem | 50 | 512 s |
Ograniczenia: jedno repo (mała, dobrze przetestowana biblioteka Pythona), sześć dobrze opisanych próśb, od 1 do 3 powtórzeń na komórkę, przebiegi headless. Ukryte testy sprawdzają tylko to, co podaje prośba.
Do this Monday
- Napisz sam jeden test akceptacyjny na każde podane wymaganie, zanim przeczytasz "done" od modelu. Ukryte testy w benchu wyłapały to, co przeoczyła każda kontrola tym samym modelem.
- Dodaj Stop hook, który uruchamia twój zestaw testów i zwraca decyzję block, dopóki jest czerwony. Odpala w każdym przebiegu; skill nie.
- Spraw, by pierwsze zakończenie zadania kosztowało jedną linię dowodu na wymaganie (wzorzec
prove-it.py): polecenie i jego wynik, nie zdanie. - Skieruj kontrolę osądową do modelu, który nie napisał zmiany:
claude -p /verify --model opusna diffie, z blokadą przy werdykcie innym niż PASS, z limitem 2 rund. - Na Opus 5.5 przy dobrze opisanej prośbie przestań wpisywać
/verifyz przyzwyczajenia. Kosztowało 2.5 razy więcej i w 12 przebiegach nic nie zmieniło; zostaw je na obszar bez testów lub polowanie na istniejący błąd. - Jeśli delegujesz do Haiku 4.5 dla oszczędności, uwzględnij koszt weryfikatora: $1.36 za zadanie z hookiem Opus wobec $0.76 dla Opus piszącego samodzielnie.
- Zapisuj w rejestrze każdą ponowną próbę nieudanej poprawki i przerywaj pętlę po powtórzeniu, żeby blokujący hook nie spalał tokenów na tej samej błędnej łatce.
- Przeczytaj ponownie swoje wymagania pod kątem przypadku wielu wierszy: "one update that matches several documents" to kształt przypadku, którego 11 z 11 przebiegów Haiku nigdy nie spróbowało.
Go further
- 5-krokowy plan i drabina dojrzałości, od ręcznej kontroli do bramki CI: najwyższe szczeble (bramki CI i PR) to miejsce dla części deterministycznej, gdy hook działa już lokalnie. s1
- Semantyka Stop hooka: decyzja block z powodem odsyła turę do modelu; przeczytaj kontrakt kodu wyjścia i JSON, zanim napiszesz własną bramkę. s19
- Groundtruth, Stop hook, który odmawia zakończenia tury, dopóki kontrole nie przejdą: deterministyczna wersja tego pomysłu, gotowa do czytania jako implementacja referencyjna. s5
- regressionledger, strona kosztowa: hook, który powstrzymuje pętlę przed ponawianiem tej samej nieudanej poprawki, element, którego nasz Stop hook nie miał, gdy przebiegi dobijały do limitu 60 tur. s10
Sources
- Building verification loops in Claude Code with skills, blog Anthropic. Dlaczego warto: 5-krokowy plan i drabina, na których zbudowano konfigurację ze skillem w benchu.
- Building verification loops in Claude Code, oficjalny kanał Claude. Dlaczego warto: trzy minuty o tym, co
/verifyrobi przy pierwszym uruchomieniu, zanim zdecydujesz, czy je zostawić. - Claude Code CHANGELOG, GitHub. Dlaczego warto: w v2.1.215
/verifystało się wywoływane tylko przez użytkownika, co zmienia, jak często się u ciebie uruchamia. - Boris Cherny: give Claude a way to verify its work, X. Dlaczego warto: teza "2-3x the quality" w dokładnym brzmieniu.
- Groundtruth, GitHub. Dlaczego warto: działająca bramka Stop hook, z której można skopiować zamiast pisać własną od zera.
- Issue #96416, GitHub. Dlaczego warto: datowany zapis werdyktu review, który sprawdził 5 z 19 zastrzeżeń i mimo to zaakceptował.
- Issue #97039, GitHub. Dlaczego warto: ta sama porażka dwa dni później z wczytaną checklistą, więc checklista nie jest rozwiązaniem.
- AI coding agents can verify some of their work now, dev.to. Dlaczego warto: najjaśniejsze ujęcie luki między "build passes" a "production-ready".
- Saguaro, GitHub. Dlaczego warto: spór o review w pętli kontra na poziomie PR, z kontrargumentem w komentarzach.
- regressionledger, GitHub. Dlaczego warto: problem kosztu ponowień, który tworzy blokujący hook, i jeden sposób na jego ograniczenie.
- SPICE simulation to oscilloscope to verification with Claude Code, blog osobisty. Dlaczego warto: pętla weryfikacji, w której wyrocznią jest fizyczny przyrząd.
- Hooks reference, code.claude.com. Dlaczego warto: kontrakt decyzji block, którego twój Stop hook musi przestrzegać.
FAQ
Czy wbudowane /verify wyłapuje błędy?
Nie w tym benchu. Zwróciło PASS w 24 z 24 przebiegów na Opus 5.5, Sonnet 5 i Haiku 4.5, także przy zmianie Haiku, która łamała podane wymaganie. Jego jedynym użytecznym znaleziskiem był istniejący wcześniej błąd upstream, niezwiązany ze zmianą.
Dlaczego mocniejszy weryfikator pomaga słabszemu autorowi?
Własna kontrola Haiku sprawdziła przypadek, który już wcześniej przyszedł mu do głowy. Opus, dostając tę samą zmianę i to samo /verify, spróbował jednego update'u trafiającego w kilka dokumentów i powiedział FAIL 3 razy na 3. Sonnet powiedział PASS. Weryfikator musi zobaczyć przypadek, którego autor nie zobaczył.
Taniej weryfikować Haiku przez Opus, czy pisać od razu Opus?
Pisz Opus. Hook z weryfikatorem Opus na Haiku kosztował średnio $1.36 za przebieg T6 i za każdym razem dobijał do limitu 60 tur; Opus piszący T6 samodzielnie kosztował średnio $0.76 przy 0 fałszywych "done".