Claude Code Kendine PASS Dedi ama Kod Bozuktu

Claude Code'un yerleşik doğrulama kontrolü olan /verify, bozuk bir özellik üzerinde PASS döndürdü. Bu sonuç, gerçek bir depo üzerinde çalıştırılan 116 Claude Code oturumluk bir bench'ten geliyor; burada her "done" sonradan, ajanın hiç görmediği kabul testleriyle notlandı.

Claude Code'u yaratan Boris Cherny, doğrulamayı ona verebileceğin en önemli şey olarak tanımlıyor. Yerleşik kontrol, Claude Code v2.1.215'ten beri yalnızca istek üzerine çalışıyor: ya /verify yazarsın ya da hiç çalışmaz. Bu bench'te 24 çalıştırmanın 24'ünde de PASS dedi ve bunlardan biri bozuk bir özelliği kapsıyordu. Aşağıda gerçekte hatayı neyin yakaladığı, ve hiçbir şeyi değiştirmeden 2,5 kat daha pahalıya mal olan kurulum anlatılıyor.

Sahte bir "done", gizli bir kabul testinin veya deponun kendi test paketinin başarısız olduğu halde işin bittiğini iddia ederek biten bir oturumdur. Bench, bunun altı farklı doğrulama kurulumu altında ne sıklıkla gerçekleştiğini ölçüyor.

Bunun ardındaki şüphe, Claude Code'un kendi issue tracker'ından geliyor: 2026-09-23 tarihinde açılan issue #96416, 19 endişe sıralayan, bunlardan 5'ini doğrulayan ve yine de "accept as is" sonucuna varan bir incelemeyi anlatıyor.

Parametre	Değer
Depo	msiemens/tinydb (Python doküman veritabanı), commit 18d73a1
Depo test paketi	226 test
Özellik istekleri	6, her biri 5 gereksinim belirtiyor
Gizli kabul testleri	her belirtilen gereksinim için bir tane, her çalıştırmadan önce yazıldı, ajana hiç gösterilmedi
Modeller	Opus 5.5, Sonnet 5, Haiku 4.5
Claude Code	2.1.283, headless (claude -p), 60 tur sınırı
Oturumlar	112 görev çalıştırması + 4 modeller-arası /verify çalıştırması = 116
Harcama	66,29 $ API-eşdeğeri

Altı kurulum, yalnızca isteği içeren sade Claude Code'dan, işi durma anında kontrol eden ikinci bir modele kadar uzanıyor:

Kurulum	Eklediği şey
A sade	hiçbir şey
B /verify	ikinci tur olarak yazılan yerleşik /verify
C verify skill	Anthropic'in iş akışına göre yazılmış bir proje skill'i
D Stop hook	test paketi kırmızıyken durmayı engelleyen ve her gereksinim için kanıt isteyen bir script
E önce testler	bir CLAUDE.md kuralı: herhangi bir kod yazılmadan önce her gereksinim için başarısız bir test
F Opus doğrulayıcı	değişiklik üzerinde Opus ile /verify çalıştıran bir Stop hook

İyi test edilmiş bir kütüphanede net istekler, kolay durum. Sade Opus 5.5, 12 çalıştırmasının 12'sini de doğru yaptı ve bunların 11'inde done demeden önce test paketini kendisi çalıştırdı.

/verify, Claude Code ile birlikte gelen doğrulama skill'idir. Değişikliği çalıştırır, diff'i okur ve adım adım bir karar yazar. v2.1.215'ten beri yalnızca kullanıcı tarafından çağrılıyor, bu yüzden bench'te her görevden sonra ikinci bir tur olarak yazıldı.

Üç model genelinde 24 çalıştırmanın 24'ünde de PASS verdi, Haiku'nun bozuk değişikliği dahil. Opus 5.5'te hiçbir sonucu değiştirmedi ve 2,5 kat daha pahalıya mal oldu:

Opus 5.5, görev başına	Sade	/verify ile
Maliyet	0,39 $	0,96 $
Duvar saati	75 s	125 s
Değişen sonuçlar		12'de 0

Adil olmak gerekirse, /verify gerçek bir hata da buldu: bir Opus görevinde, kontrol ettiği değişiklikten kaynaklanmayan, kütüphanede zaten var olan bir "reuse-after-close" sorununu işaretledi. Zaten doğru olan bir iş üzerinde, pahalı bir ikinci görüş.

Bir skill, Claude'un uygun gördüğünde açabileceği markdown bir prosedürdür. Anthropic'in doğrulama döngüleri üzerine blog yazısı altı adımlı bir tarif anlatıyor: en sık yaptığın manuel takip işini seç, önce yerleşik /verify'ı dene, prosedürü sade İngilizce yaz, bir skill'e dönüştür, ardından yeni bir görevde çağır ve yinele. Bench'in skill'i olan verify-change, tam olarak bu şekilde inşa edildi ve Claude'a done demeden önce her gereksinimi gerçek kod üzerinde kanıtlamasını söylüyor.

Bir skill bir öneridir ve onu açıp açmayacağına Claude karar verir:

Model	Skill'i açan oturumlar
Opus 5.5	12'de 8
Sonnet 5	6'da 2
Haiku 4.5	6'da 0
Toplam	24'te 10

Sonnet'in tek sahte "done"'ı, skill'in hiç açılmadığı bir oturumdan geldi: oturum, kendi yeni testlerinden ikisi başarısızken bitti.

Bir Stop hook, ajan bitirmeyi her denediğinde Claude Code'un çalıştırdığı bir scripttir. Durmayı reddedip ajanı bir gerekçeyle geri gönderebilir. Bench'in hook'u test paketini çalıştırır, kırmızıyken engeller ve ilk durma anında her gereksinim için bir satır kanıt ister. Her oturumda tetiklendi. Opus'ta yüzde 20 daha pahalıya mal oldu, görev başına 0,47 $'a karşı 0,39 $ (94 s'ye karşı 75 s). Bu bench'te durma anında hiç başarısız bir test paketiyle karşılaşmadı, yani yakalayacak bir şeyi olmadı: bir hook her zaman tetiklenir, ama yalnızca ona ne kontrol etmesini söylediysen onu kontrol eder.

Başarısız olan görev, bir tabloda benzersiz alanlar istiyordu: iki kullanıcı aynı e-postayı paylaşamaz ve iki dokümanı aynı benzersiz değerle bırakacak herhangi bir güncelleme DuplicateKeyError fırlatmalıdır.

Haiku 4.5, bir kullanıcıyı başka bir kullanıcının e-postasına taşımayı test etti ve bu doğru şekilde reddedildi. Birden fazla dokümanla eşleşen ve hepsine aynı yeni e-postayı yazan tek bir güncellemeyi hiç test etmedi. Bu durum, aynı-model kurulumlarının her birinde — sade, /verify, skill, Stop hook ve önce testler — 11 Haiku oturumunun 11'inde de hatasız geçti.

Haiku'nun kendi /verify'ı, denediği durumu işaretledi ve PASS yazdı. Gizli test DID NOT RAISE DuplicateKeyError bildirdi. Aynı değişiklik üzerinde /verify çalıştırması istenen Sonnet 5 de PASS döndürdü. Opus ve Sonnet, bu özelliği kendi başlarına doğru yazdı, yani bu tek bir görevde tek bir model, ama aynı model tarafından yazılan bir kontrol, o modelin kör noktasını paylaşır.

Aynı Haiku değişikliği üzerinde, bu kez Opus 5.5 tarafından çalıştırılan aynı /verify, 3 çalıştırmanın 3'ünde de FAIL döndürdü ve her seferinde kaçırılan durumu adlandırdı: birden fazla dokümanla eşleşen tek bir güncelleme, hepsine hatasız aynı değeri yazıyor. Yakalama, yazardan değil ve yazarın kendi kontrolünden değil, farklı bir modelden geldi.

Bir Stop hook olarak bağlandığında (kurulum F), Opus, Haiku her bitirmeyi denediğinde işi kontrol ediyor. Sonuçlar:

T6, çalıştırma başına	Haiku + Opus kontrolcü	Sade Opus 5.5
Hata düzeltildi / sahte "done"	3'te 3 düzeltildi	0 sahte "done"
Turlar	her çalıştırmada 60 tur sınırına ulaşıldı
Maliyet	kontrolcü dahil 1,36 $	0,76 $

Dışarıdan kontrol işe yarıyor. Bu görevde, daha güçlü modelin özelliği tek başına yazmasından daha pahalıya mal oldu.

Bir değişikliği yazan modelin, onu kontrol eden tek şey olmasına izin vermeyi bırakın.

Kural	Neden	Bu bench'teki maliyet
Bir script'in kontrol edebileceği her şey için bir Stop hook tutun	her oturumda tetiklenir	Opus'ta yaklaşık yüzde 20 daha fazla
Gerçek kontrolün yazarın dışından gelmesini sağlayın: kapıda daha güçlü bir model, ya da istekten yazdığınız kendi testleriniz	aynı model kendi hatasını 11'de 11 kaçırdı	Haiku + Opus kontrolcü için görev başına 1,36 $
Opus ile net bir istekte /verify yazmayı atlayın	0 sonuç değişti	2,5 kat maliyet, 125 s'ye karşı 75 s

Sınırlar: tek bir küçük kütüphane, altı net istek, hücre başına bir ile üç çalıştırma, headless oturumlar ve yalnızca her isteğin belirttiğini kontrol eden gizli testler. Daha karmaşık işlerde bu rakamlar değişecektir.