TL;DR
- Anthropic'in kendi önerisi ruhu bakımından doğru: geri bildirim döngüsü olan model daha iyi iş çıkarır. Sorun, döngüyü kimin çalıştırdığı. 116 çalıştırmada yerleşik
/verify24 çalıştırmanın 24'ünde PASS döndürdü; belirtilmiş bir gereksinimi bozan bir değişiklik de bunun içinde. - Kendi değişikliğini kontrol eden bir model, onunla aynı kör noktayı paylaşır. Haiku 4.5, aynı modelin kullanıldığı tüm kurulumlarda benzersiz alan senaryosunu 11 çalıştırmanın 11'inde kaçırdı ve kendi
/verifyçıktısı yanlış senaryonun yanına onay işareti koydu. - Opus 5.5 üzerinde
/verify2.5 kat pahalıya geldi ($0.96'ya karşı $0.39) ve hiçbir sonucu değiştirmedi. Düz Opus 12 çalıştırmanın 12'sinde doğru yaptı ve bunların 11'inde test paketini kendisi çalıştırdı. - Proje skill'i model için isteğe bağlı: 24 çalıştırmanın 10'unda tetiklendi, Haiku'da 6'nın 0'ında. Stop hook her çalıştırmada tetiklendi ve Opus'ta yaklaşık %20 fazlaya mal oldu.
- İşe yarayan kontrol yazarın dışından geldi: aynı
/verify, Opus ile çalıştırıldığında Haiku'nun değişikliği için 3 çalıştırmanın 3'ünde FAIL dedi ve hatayı adıyla söyledi. Stop hook olarak bağlandığında Haiku'ya hatayı 3 seferin 3'ünde düzelttirdi; görev başına $1.36, görevi tek başına yazan Opus için ise $0.76. - Bunu kopyalayın: deterministik kısım için bir Stop hook, yargı gerektiren kısım için yazar olmayan bir doğrulayıcı ve iyi tanımlanmış işlerde Opus üzerinde
/verifykullanmamak.
Ölçümler ne söylüyor
Anthropic'in iddiası: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Blog bunu 5 adımlık bir benimseme akışına çeviriyor: en çok tekrarladığınız elle kontrolü seçin, yerleşik /verify'ı deneyin, prosedürü düz dille bir skill olarak yazın, onu deterministik yapın, sonra CI'a taşıyın. s1 v2.1.215'ten beri "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
Sahadan gelen raporlar, doğrulamanın iddia edildiği ama çalıştırılmadığı durumlar hakkında. Issue #96416, 19 endişeden 5'inin doğrulandığı ve yine de "accept as-is" verilen bir inceleme kararı. s6 Issue #97039, yüklü bir kontrol listesine rağmen kısmi kontrollerden sonra yapılan bir "held up" iddiası. s7 "build passes" ile "production-ready" farklı çıtalardır ve her kaçırma 2-3 tur yeniden istem yazmaya mal olur. s8
Benchmark'ımız her "done"ı, ajanın hiç görmediği gizli kabul testleriyle puanladı. 112 görev çalıştırması + 4 modeller arası /verify çalıştırması = 116 çalıştırma, API karşılığı $66.29 harcama. Yanlış "done": 112'de 12; 11'i A'dan E'ye her kurulumda T6'daki Haiku, 1'i skill kurulumunda T6'daki Sonnet (kendi yeni testleri başarısızdı ve skill hiç tetiklenmedi). s1
Yerleşik /verify, üç modelde 24 çalıştırmanın 24'ünde Verdict: PASS dedi (23'ü ayrıştırılabilir, 1'i etiketsiz geçiş), Haiku'nun bozuk T6'sı da dahil. Opus'ta düz çalıştırmanın $0.39'una karşılık $0.96'ya (2.5x) ve 75 s'ye karşılık 125 s'ye mal oldu; hiçbir sonucu değiştirmedi. s3
5 adımlık akışa göre yazılan proje skill'i 24 çalıştırmanın 10'unda çağrıldı: Opus 8/12, Sonnet 2/6, Haiku 0/6. Stop hook her çalıştırmada tetiklendi; Opus'ta $0.47'ye karşı $0.39 (+20 %). s19
Kör nokta tek bir gereksinim, T6 req 4: eşleşen birkaç belgeye aynı benzersiz değeri veren tek bir update, DuplicateKeyError fırlatmalı. Haiku bunu 11 çalıştırmanın 11'inde, her kurulumda (plain, /verify, skill, hook, tests first) kaçırdı. Haiku'nun kendi /verify'ı "bir belgeyi başka bir belgenin e-postasına güncelle" senaryosunu kontrol etti ve birkaç belgeyi vuran tek bir update'i hiç denemedi. Önce test kuralı yardımcı olmadı: 3/3 hâlâ req 4'ü kaçırıyor, biri req 3'ü de bozdu. s1
Aynı Haiku değişikliği, /verify başka bir modelle çalıştırıldığında: Sonnet PASS dedi (1/1), Opus 3/3 FAIL dedi ve her seferinde aynı senaryoyu, aynı değeri birkaç belgeye yazan tek bir update'i adıyla belirtti; kontrol başına $0.39 ila $0.47. Haiku üzerinde Stop hook olarak (kurulum F), Opus doğrulayıcısı hatayı 3 çalıştırmanın 3'ünde düzelttirdi; üçü de düzeltirken 60 turn sınırına çarptı, doğrulayıcı dahil T6 çalıştırması başına ortalama $1.36; T6'yı tek başına yazan Opus ise ortalama $0.76 ve 0 yanlış "done". s19
Ölçüm detayları
Test düzeneği: Claude Code 2.1.283 headless (claude -p), izole yapılandırma dizini, görev başına aynı istem, 60 turn sınırı. Depo: msiemens/tinydb @ 18d73a1 (Python, 226 test). T1'den T6'ya altı özellik isteği, her birinde 5 belirtilmiş gereksinim (T5: 6). Her belirtilmiş gereksinim için bir tane olan ve ajana hiç gösterilmeyen gizli kabul testleri her çalıştırmayı puanlar; deponun kendi paketi de çalışır. Yanlış "done", tamamlandığını iddia ederek biten ama bir gizli testin ya da depo paketinin başarısız olduğu çalıştırmadır.
Kurulumlar: A plain (yalnızca istek); B /verify (A, ardından ikinci turn olarak yerleşik /verify); C verify skill (5 adımlık akışa göre yazılmış, modelin çağırabildiği bir proje skill'i); D Stop hook (prove-it.py: test paketi kırmızıyken durmayı engeller ve ilk durmayı, her gereksinim için bir satır kanıt isteyerek engeller); E tests first (bir CLAUDE.md kuralı: herhangi bir koddan önce her gereksinim için başarısız bir test); F Opus verifier hook (değişiklik üzerinde claude -p /verify --model opus, PASS olmayan kararda engeller, en fazla 2 tur).
| model | kurulum | çalıştırma | yanlış done | ort. maliyet | ort. turn | ort. süre |
|---|---|---|---|---|---|---|
| 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 doğrulayıcı dahil | 61 (cap) | 457 s |
| Sonnet 5 | F | 1 (T6) | 0 | $2.30 doğrulayıcı dahil | 50 | 512 s |
Sınırlar: tek bir depo (küçük, iyi test edilmiş bir Python kütüphanesi), altı iyi tanımlanmış istek, hücre başına 1 ila 3 tekrar, headless çalıştırmalar. Gizli testler yalnızca isteğin belirttiğini kontrol eder.
Pazartesi yapılacaklar
- Modelin "done" demesini okumadan önce, belirtilen her gereksinim için kendiniz bir kabul testi yazın. Benchmark'ın gizli testleri, aynı modelle yapılan her kontrolün kaçırdığını yakaladı.
- Test paketinizi çalıştıran ve kırmızıyken block kararı döndüren bir Stop hook ekleyin. Her çalıştırmada tetiklenir; skill tetiklenmez.
- Bir görevin ilk durmasını, gereksinim başına bir satır kanıta mal edin (
prove-it.pykalıbı): bir cümle değil, bir komut ve çıktısı. - Yargı kontrolünü değişikliği yazmamış bir modele yönlendirin: diff üzerinde
claude -p /verify --model opus, PASS olmayan kararda engelleyerek, en fazla 2 turla sınırlı. - İyi tanımlanmış bir istekte Opus 5.5 üzerinde alışkanlıkla
/verifyyazmayı bırakın. 2.5 kat pahalıya geldi ve 12 çalıştırmada hiçbir şeyi değiştirmedi; testsiz bir alan ya da önceden var olan bir hata avı için saklayın. - Maliyet için Haiku 4.5'e devrediyorsanız doğrulayıcıyı bütçeye katın: Opus hook'u ile görev başına $1.36, Opus'un tek başına yazması ise $0.76.
- Başarısız bir düzeltmenin her yeniden denemesini bir deftere kaydedin ve bir tekrardan sonra döngüyü durdurun; böylece engelleyen bir hook aynı yanlış yama için token yakmaz.
- Gereksinimlerinizi çok satırlı senaryo için yeniden okuyun: "birkaç belgeyle eşleşen tek bir update", Haiku'nun 11 çalıştırmanın 11'inde hiç denemediği senaryonun biçimidir.
Daha fazlası
- 5 adımlı akış ve elle kontrolden CI kapısına uzanan olgunluk merdiveni: hook'unuz yerelde çalışınca deterministik kısmın ait olduğu yer, üst basamaklar (CI ve PR kapıları). s1
- Stop hook anlambilimi: gerekçeli bir block kararı turn'ü modele geri gönderir; kendi kapınızı yazmadan önce exit code ve JSON sözleşmesini okuyun. s19
- Groundtruth, kontroller geçene kadar turn'ün bitmesini reddeden bir Stop hook: fikrin deterministik sürümü, referans uygulama olarak okunmaya hazır. s5
- regressionledger, maliyet tarafı: döngünün aynı başarısız düzeltmeyi yeniden denemesini engelleyen bir hook; çalıştırmalar 60 turn sınırına çarptığında bizim Stop hook'umuzda eksik olan parça. s10
Sources
- Building verification loops in Claude Code with skills, Anthropic blog. Neden okunmalı: benchmark'ın skill kurulumunun üzerine kurulduğu 5 adımlı akış ve merdiven.
- Building verification loops in Claude Code, resmi Claude kanalı. Neden okunmalı: tutup tutmayacağınıza karar vermeden önce
/verify'ın ilk çalıştırmada ne yaptığı üzerine üç dakika. - Claude Code CHANGELOG, GitHub. Neden okunmalı: v2.1.215,
/verify'ın yalnızca kullanıcı tarafından çağrılır hale geldiği sürüm; bu, sizde ne sıklıkla çalıştığını değiştirir. - Boris Cherny: give Claude a way to verify its work, X. Neden okunmalı: "2-3x the quality" iddiası, tam ifadesiyle.
- Groundtruth, GitHub. Neden okunmalı: sıfırdan yazmak yerine kopyalayabileceğiniz çalışan bir Stop hook kapısı.
- Issue #96416, GitHub. Neden okunmalı: 19 endişeden 5'ini doğrulayıp yine de kabul eden bir inceleme kararının tarihli dökümü.
- Issue #97039, GitHub. Neden okunmalı: iki gün sonra, kontrol listesi yüklüyken aynı hata; yani çözüm kontrol listesi değil.
- AI coding agents can verify some of their work now, dev.to. Neden okunmalı: "build passes" ile "production-ready" arasındaki farkın en net anlatımı.
- Saguaro, GitHub. Neden okunmalı: döngü içi ve PR düzeyinde inceleme tartışması, karşı argüman yorumlarda.
- regressionledger, GitHub. Neden okunmalı: engelleyen bir hook'un yarattığı yeniden deneme maliyeti sorunu ve onu sınırlamanın bir yolu.
- SPICE simulation to oscilloscope to verification with Claude Code, kişisel blog. Neden okunmalı: kıstası fiziksel bir cihaz olan bir doğrulama döngüsü.
- Hooks reference, code.claude.com. Neden okunmalı: Stop hook'unuzun uyması gereken block karar sözleşmesi.
FAQ
Yerleşik /verify hataları yakalıyor mu?
Bu benchmark'ta hayır. Opus 5.5, Sonnet 5 ve Haiku 4.5 genelinde 24 çalıştırmanın 24'ünde PASS döndürdü; belirtilmiş bir gereksinimi bozan bir Haiku değişikliği de bunun içinde. Tek faydalı bulgusu, değişiklikle ilgisi olmayan, önceden var olan bir upstream hatasıydı.
Neden daha güçlü bir doğrulayıcı daha zayıf bir yazara yardım ediyor?
Haiku'nun kendi kontrolü, zaten aklına gelmiş senaryoyu test etti. Aynı değişiklik ve aynı /verify verilen Opus, birkaç belgeyi vuran tek bir update'i denedi ve 3 çalıştırmanın 3'ünde FAIL dedi. Sonnet PASS dedi. Doğrulayıcının, yazarın görmediği bir senaryoyu görmesi gerekir.
Haiku'yu Opus ile doğrulamak mı daha ucuz, yoksa Opus ile yazmak mı?
Opus ile yazın. Haiku üzerindeki Opus doğrulayıcı hook'u T6 çalıştırması başına ortalama $1.36'ya geldi ve her seferinde 60 turn sınırına çarptı; T6'yı tek başına yazan Opus ortalama $0.76 tuttu ve 0 yanlış "done" üretti.
AIDive