AIDiveSam się ocenił: PASS
Wbudowana kontrola weryfikacyjna Claude Code, /verify, zwróciła PASS na funkcji, która była zepsuta. To wynik testu 116 sesji Claude Code na prawdziwym repozytorium, w którym każde „gotowe” było później oceniane przez testy akceptacyjne, których agent nigdy nie widział.
Boris Cherny, twórca Claude Code, nazywa weryfikację najważniejszą rzeczą, jaką można mu dać. Wbudowana kontrola uruchamia się na żądanie dopiero od wersji Claude Code v2.1.215: wpisujesz /verify, albo się nie uruchamia. W tym teście zwróciła PASS w 24 uruchomieniach na 24, a jedno z nich dostarczyło zepsutą funkcję. Co naprawdę złapało tego buga, opisano niżej, razem z konfiguracją, która kosztowała dwa i pół raza więcej i niczego nie zmieniła.
Test: 116 uruchomień, testy, których nigdy nie widział
Fałszywe „gotowe” to sesja, która kończy się stwierdzeniem, że praca jest ukończona, podczas gdy ukryty test akceptacyjny albo własny zestaw testów repozytorium kończy się niepowodzeniem. Test mierzy, jak często to się zdarza w sześciu konfiguracjach weryfikacji.
Wątpliwość, która za tym stoi, pochodzi z własnego trackera zgłoszeń Claude Code: issue #96416, zgłoszony 2026-09-23, opisuje przegląd, który wymienił 19 zastrzeżeń, zweryfikował 5 z nich i mimo to zakończył się słowami „accept as is”.
| Parametr | Wartość |
|---|---|
| Repozytorium | msiemens/tinydb (baza dokumentowa w Pythonie), commit 18d73a1 |
| Zestaw testów repozytorium | 226 testów |
| Zgłoszenia funkcji | 6, każde z 5 wymaganiami |
| Ukryte testy akceptacyjne | jeden na każde wymaganie, napisany przed jakimkolwiek uruchomieniem, nigdy niepokazywany agentowi |
| Modele | Opus 5.5, Sonnet 5, Haiku 4.5 |
| Claude Code | 2.1.283, headless (claude -p), limit 60 tur |
| Sesje | 112 uruchomień zadań + 4 uruchomienia /verify między modelami = 116 |
| Wydatek | 66,29 USD w ekwiwalencie API |
Sześć konfiguracji rozciąga się od zwykłego Claude Code (samo zgłoszenie) po drugi model sprawdzający pracę przy zakończeniu:
| Konfiguracja | Co dodaje |
|---|---|
| A plain | nic |
| B /verify | wbudowany /verify wpisany jako druga tura |
| C verify skill | project skill napisany według metody Anthropic |
| D Stop hook | skrypt, który blokuje zakończenie, dopóki zestaw testów jest czerwony, i prosi o dowód dla każdego wymagania |
| E tests first | reguła w CLAUDE.md: nieudany test dla każdego wymagania przed jakimkolwiek kodem |
| F Opus verifier | Stop hook, który uruchamia /verify z Opus na zmianie |
Jasne zgłoszenia na dobrze przetestowanej bibliotece to łatwy przypadek. Zwykły Opus 5.5 miał rację we wszystkich 12 uruchomieniach i w 11 z nich sam uruchomił zestaw testów, zanim uznał zadanie za gotowe.
Wbudowany /verify: PASS za każdym razem, 2,5x
/verify to skill weryfikacyjny dołączony do Claude Code. Uruchamia zmianę, czyta diff i pisze werdykt krok po kroku. Od wersji v2.1.215 uruchamia się tylko na żądanie użytkownika, więc w teście był wpisywany po każdym zadaniu jako druga tura.
Zwrócił werdykt PASS w 24 uruchomieniach na 24 wśród trzech modeli, w tym na zepsutej zmianie Haiku. Na Opus 5.5 nie zmienił żadnego wyniku i kosztował 2,5 raza więcej:
| Opus 5.5, na zadanie | Plain | Z /verify |
|---|---|---|
| Koszt | 0,39 USD | 0,96 USD |
| Czas rzeczywisty | 75 s | 125 s |
| Zmienione wyniki | 0 z 12 |
Trzeba przyznać, że /verify znalazł jednego prawdziwego buga: w jednym zadaniu Opus wskazał problem reuse-after-close, który był już w bibliotece, a nie wynikał ze sprawdzanej zmiany. Na pracy, która już była poprawna, to droga druga opinia.
Skill czy hook: ten, który bywa pomijany
Skill to procedura w markdown, którą Claude może otworzyć, gdy uzna to za istotne. Wpis na blogu Anthropic o pętlach weryfikacji opisuje przepis w sześciu krokach: wybierz ręczną czynność kontrolną, którą wykonujesz najczęściej, najpierw wypróbuj wbudowany /verify, zapisz procedurę zwykłym językiem, zamień ją w skill, a potem wywołuj go przy nowym zadaniu i iteruj. Skill z tego testu, verify-change, powstał dokładnie w ten sposób i mówi Claude, żeby udowodnić każde wymaganie na realnym kodzie, zanim uzna zadanie za gotowe.
Skill to sugestia, a Claude sam decyduje, czy go otworzyć:
| Model | Sesje, w których otwarto skill |
|---|---|
| Opus 5.5 | 8 z 12 |
| Sonnet 5 | 2 z 6 |
| Haiku 4.5 | 0 z 6 |
| Razem | 10 z 24 |
Jedyne fałszywe „gotowe” Sonnet pochodziło z sesji, w której skill nigdy się nie otworzył: zakończyła się z dwoma własnymi nowymi testami, które nie przechodziły.
Stop hook to skrypt, który Claude Code uruchamia za każdym razem, gdy agent próbuje zakończyć pracę. Może odmówić zakończenia i odesłać agenta z powrotem z podanym powodem. Hook z tego testu uruchamia zestaw testów, blokuje, dopóki jest czerwony, a przy pierwszym zakończeniu prosi o jedną linijkę dowodu na każde wymaganie. Uruchomił się w każdej sesji. Na Opus kosztował o 20% więcej, 0,47 USD wobec 0,39 USD za zadanie (94 s wobec 75 s). W tym teście nigdy nie trafił na czerwony zestaw testów przy zakończeniu, więc nie miał czego złapać: hook zawsze się uruchamia, ale sprawdza tylko to, co mu kazano sprawdzać.
Martwy punkt: 11 na 11 pominiętych
Zadanie, na którym coś poszło źle, wymagało unikalnych pól w tabeli: dwaj użytkownicy nie mogą mieć tego samego adresu e-mail, a każda aktualizacja, która zostawiłaby dwa dokumenty z tą samą unikalną wartością, musi zgłosić DuplicateKeyError.
Haiku 4.5 przetestował przeniesienie jednego użytkownika na adres e-mail innego użytkownika, i to zostało poprawnie odrzucone. Nigdy nie przetestował jednej aktualizacji, która pasuje do kilku dokumentów i zapisuje ten sam nowy e-mail we wszystkich. Ten przypadek przechodził bez błędu w 11 sesjach Haiku na 11, w każdej konfiguracji z tym samym modelem: plain, /verify, skill, Stop hook i tests first.
Własny /verify Haiku zaznaczył przypadek, który sam sprawdził, i napisał PASS. Ukryty test zgłosił DID NOT RAISE DuplicateKeyError. Sonnet 5, poproszony o uruchomienie /verify na tej samej zmianie, również zwrócił PASS. Opus i Sonnet oba napisały tę funkcję poprawnie samodzielnie, więc to jeden model na jednym zadaniu, ale kontrola napisana przez ten sam model dzieli jego martwy punkt.
Kontrola z zewnątrz: Opus mówi FAIL
Ten sam /verify na tej samej zmianie Haiku, uruchomiony przez Opus 5.5, zwrócił FAIL w 3 uruchomieniach na 3, za każdym razem wskazując pominięty przypadek: jedna aktualizacja pasująca do kilku dokumentów zapisuje tę samą wartość we wszystkich bez błędu. Złapał to inny model, nie autor i nie własna kontrola autora.
Podłączony jako Stop hook (konfiguracja F), Opus sprawdza pracę Haiku za każdym razem, gdy Haiku próbuje zakończyć. Wyniki:
| T6, na uruchomienie | Haiku + kontroler Opus | Sam Opus 5.5 |
|---|---|---|
| Bug naprawiony / fałszywe „gotowe” | naprawiony w 3 z 3 | 0 fałszywych „gotowe” |
| Tury | limit 60 tur osiągnięty w każdym uruchomieniu | |
| Koszt | 1,36 USD łącznie z kontrolerem | 0,76 USD |
Kontrola z zewnątrz działa. Przy tym zadaniu kosztowała więcej niż silniejszy model piszący funkcję samodzielnie.
Co powielić i ile to kosztuje
Przestań pozwalać, żeby model, który napisał zmianę, był jedynym, który ją sprawdza.
| Zasada | Dlaczego | Koszt w tym teście |
|---|---|---|
| Zachowaj Stop hook dla wszystkiego, co może sprawdzić skrypt | uruchamia się w każdej sesji | około 20% więcej na Opus |
| Spraw, żeby prawdziwa kontrola pochodziła spoza autora: silniejszy model na bramce albo własne testy napisane na podstawie zgłoszenia | ten sam model przegapił własnego buga 11 razy na 11 | 1,36 USD za zadanie dla Haiku + kontroler Opus |
Przy jasnym zgłoszeniu na Opus pomiń wpisywanie /verify |
0 zmienionych wyników | koszt 2,5x, 125 s wobec 75 s |
Ograniczenia: jedna mała biblioteka, sześć jasnych zgłoszeń, od jednego do trzech uruchomień na komórkę, sesje headless i ukryte testy sprawdzające tylko to, co stwierdza każde zgłoszenie. Przy bardziej chaotycznej pracy te liczby się zmienią.
