Claude Code का Verify: टूटे कोड पर भी PASS

Claude Code का बिल्ट-इन वेरिफिकेशन चेक, /verify, एक ऐसे फीचर पर PASS लौटाया जो असल में टूटा हुआ था। यह नतीजा एक असली रीपॉज़िटरी पर चलाए गए 116 Claude Code सेशन के बेंच का है, जहां हर "done" को बाद में उन एक्सेप्टेंस टेस्ट से जांचा गया जो एजेंट ने कभी देखे ही नहीं थे।

Claude Code बनाने वाले Boris Cherny का कहना है कि वेरिफिकेशन वह सबसे ज़रूरी चीज़ है जो आप इसे दे सकते हैं। यह बिल्ट-इन चेक Claude Code v2.1.215 से सिर्फ मांगने पर चलता है: आप /verify टाइप करें, वरना यह नहीं चलता। इस बेंच पर इसने 24 में से 24 रन में PASS कहा, और उनमें से एक रन ने एक टूटा हुआ फीचर शिप किया था। असल में बग किसने पकड़ा, यह आगे बताया गया है, साथ ही वह सेटअप भी जिसकी लागत ढाई गुना ज़्यादा थी और जिसने कुछ नहीं बदला।

एक झूठा "done" वह सेशन है जो यह दावा करते हुए खत्म होता है कि काम पूरा हो गया, जबकि एक छुपा हुआ एक्सेप्टेंस टेस्ट, या रीपॉज़िटरी की अपनी सूट, फेल हो जाता है। यह बेंच मापता है कि छह वेरिफिकेशन सेटअप के तहत यह कितनी बार होता है।

इसके पीछे का शक Claude Code के अपने इशू ट्रैकर से आता है: 2026-09-23 को दर्ज इशू #96416 एक ऐसे रिव्यू का वर्णन करता है जिसने 19 चिंताएं गिनाईं, उनमें से 5 को वेरीफाई किया, और फिर भी नतीजा दिया "accept as is"।

पैरामीटर	मान
रीपॉज़िटरी	msiemens/tinydb (Python document database), कमिट 18d73a1
रीपॉज़िटरी की टेस्ट सूट	226 टेस्ट
फीचर रिक्वेस्ट	6, हर एक में 5 ज़रूरतें
छुपे एक्सेप्टेंस टेस्ट	हर बताई गई ज़रूरत के लिए एक, हर रन से पहले लिखा गया, एजेंट को कभी नहीं दिखाया गया
मॉडल	Opus 5.5, Sonnet 5, Haiku 4.5
Claude Code	2.1.283, हेडलेस (claude -p), 60-टर्न कैप
सेशन	112 टास्क रन + 4 क्रॉस-मॉडल /verify रन = 116
खर्च	$66.29 API-इक्विवैलेंट

छह सेटअप सादे Claude Code (सिर्फ रिक्वेस्ट) से लेकर एक दूसरे मॉडल तक जाते हैं जो स्टॉप पर काम जांचता है:

सेटअप	क्या जोड़ता है
A सादा	कुछ नहीं
B /verify	बिल्ट-इन /verify दूसरे टर्न के तौर पर टाइप किया गया
C verify skill	Anthropic के तरीके से लिखा गया एक प्रोजेक्ट skill
D Stop hook	एक स्क्रिप्ट जो सूट लाल रहने तक स्टॉप को रोकती है और हर ज़रूरत के सबूत मांगती है
E पहले टेस्ट	एक CLAUDE.md नियम: किसी भी कोड से पहले हर ज़रूरत के लिए एक फेल होता टेस्ट
F Opus verifier	एक Stop hook जो बदलाव पर Opus के साथ /verify चलाता है

एक अच्छी तरह टेस्ट की गई लाइब्रेरी पर साफ रिक्वेस्ट आसान केस है। सादा Opus 5.5 अपने सभी 12 रन में सही निकला, और उसने 11 में खुद ही टेस्ट सूट चलाई, PASS कहने से पहले।

/verify वह वेरिफिकेशन skill है जो Claude Code के साथ आती है। यह बदलाव चलाती है, डिफ पढ़ती है, और स्टेप-बाय-स्टेप वर्डिक्ट लिखती है। v2.1.215 से यह सिर्फ यूज़र-इनवोक्ड है, इसलिए बेंच पर इसे हर टास्क के बाद दूसरे टर्न के तौर पर टाइप किया गया।

तीनों मॉडल पर 24 में से 24 रन में इसने PASS वर्डिक्ट दिया, जिसमें Haiku का टूटा हुआ बदलाव भी शामिल है। Opus 5.5 पर इसने कोई नतीजा नहीं बदला और लागत ढाई गुना ज़्यादा रही:

Opus 5.5, प्रति टास्क	सादा	/verify के साथ
लागत	$0.39	$0.96
समय	75 सेकंड	125 सेकंड
बदले नतीजे		12 में से 0

निष्पक्षता के लिए, /verify ने एक असली बग भी पकड़ा: एक Opus टास्क पर इसने reuse-after-close की एक समस्या बताई, जो पहले से ही लाइब्रेरी में थी, उस बदलाव की वजह से नहीं जिसे यह जांच रहा था। जो काम पहले से ही सही था, उस पर यह एक महंगी दूसरी राय है।

skill एक मार्कडाउन प्रोसीज़र है जिसे Claude तब खोल सकता है जब वह इसे प्रासंगिक समझे। Anthropic की वेरिफिकेशन लूप वाली ब्लॉग पोस्ट एक छह-कदम रेसिपी बताती है: वह मैनुअल फॉलो-अप चुनें जो आप सबसे ज़्यादा करते हैं, पहले बिल्ट-इन /verify आज़माएं, प्रोसीज़र को सादे शब्दों में लिखें, इसे एक skill बनाएं, फिर इसे किसी नए टास्क पर इनवोक करें और सुधारते रहें। बेंच की skill, verify-change, ठीक इसी तरह बनाई गई और Claude को done कहने से पहले असली कोड के खिलाफ हर ज़रूरत साबित करने को कहती है।

skill एक सुझाव है, और Claude तय करता है कि उसे खोलना है या नहीं:

मॉडल	जिन सेशन में skill खुली
Opus 5.5	12 में से 8
Sonnet 5	6 में से 2
Haiku 4.5	6 में से 0
कुल	24 में से 10

Sonnet का इकलौता झूठा "done" उस सेशन से आया जहां skill कभी नहीं खुली: वह सेशन अपने ही दो नए टेस्ट फेल होने के साथ खत्म हुआ।

Stop hook एक स्क्रिप्ट है जिसे Claude Code हर बार चलाता है जब एजेंट खत्म करने की कोशिश करता है। यह स्टॉप को मना कर सकता है और एजेंट को वजह के साथ वापस भेज सकता है। बेंच का hook टेस्ट सूट चलाता है, लाल रहने तक रोकता है, और पहले स्टॉप पर हर ज़रूरत के लिए एक लाइन का सबूत मांगता है। यह हर सेशन में चला। Opus पर इसकी लागत 20% ज़्यादा रही, $0.47 बनाम $0.39 प्रति टास्क (94 सेकंड बनाम 75 सेकंड)। इस बेंच में इसे स्टॉप के समय कभी कोई फेल होती सूट नहीं मिली, तो पकड़ने को कुछ था ही नहीं: hook हमेशा चलता है, लेकिन यह सिर्फ वही जांचता है जो आपने उसे जांचने को कहा है।

जो टास्क फेल हुआ वह किसी टेबल पर यूनीक फील्ड्स मांग रहा था: दो यूज़र एक ईमेल शेयर नहीं कर सकते, और कोई भी अपडेट जो दो डॉक्यूमेंट को एक ही यूनीक वैल्यू के साथ छोड़ दे, उसे DuplicateKeyError उठाना चाहिए।

Haiku 4.5 ने एक यूज़र को दूसरे यूज़र के ईमेल पर ले जाने का टेस्ट किया, और वह सही तरीके से मना हो गया। इसने कभी यह टेस्ट नहीं किया कि एक अपडेट कई डॉक्यूमेंट से मैच करे और सबको वही नया ईमेल लिख दे। यह केस बिना किसी एरर के निकल गया, Haiku के 11 में से 11 सेशन में, हर एक-मॉडल सेटअप में: सादा, /verify, skill, Stop hook और पहले टेस्ट।

Haiku के अपने /verify ने उसी केस को टिक किया जो उसने आज़माया था और PASS लिख दिया। छुपे टेस्ट ने रिपोर्ट किया DID NOT RAISE DuplicateKeyError। उसी बदलाव पर /verify चलाने को कहे जाने पर Sonnet 5 ने भी PASS लौटाया। Opus और Sonnet दोनों ने यह फीचर अपने आप सही लिखा था, तो यह एक मॉडल का एक टास्क पर मामला है, लेकिन उसी मॉडल से लिखा गया चेक उसकी अंधी जगह भी साझा करता है।

उसी Haiku बदलाव पर वही /verify, जब Opus 5.5 से चलाया गया, तो 3 में से 3 रन में FAIL लौटाया, हर बार उसी छूटे हुए केस का नाम लेते हुए: एक अपडेट जो कई डॉक्यूमेंट से मैच करता है, बिना किसी एरर के सबको वही वैल्यू लिख देता है। पकड़ एक अलग मॉडल से आई, न कि लेखक से और न ही लेखक के अपने चेक से।

Stop hook के तौर पर लगाए जाने पर (सेटअप F), Opus हर बार Haiku का काम जांचता है जब Haiku खत्म करने की कोशिश करता है। नतीजे:

T6, प्रति रन	Haiku + Opus checker	अकेला Opus 5.5
बग ठीक हुआ / झूठा "done"	3 में से 3 में ठीक हुआ	कोई झूठा "done" नहीं
टर्न	हर रन में 60-टर्न कैप टकराई
लागत	$1.36, checker सहित	$0.76

बाहर का चेक काम करता है। इस टास्क पर इसकी लागत उससे ज़्यादा रही जितनी अकेले फीचर लिखने वाले ज़्यादा मज़बूत मॉडल की थी।

जिस मॉडल ने बदलाव लिखा है, उसे उसका इकलौता जांचकर्ता बनाना बंद करें।

नियम	क्यों	इस बेंच पर लागत
स्क्रिप्ट जो भी जांच सके, उसके लिए एक Stop hook रखें	यह हर सेशन में चलता है	Opus पर करीब 20% ज़्यादा
असली जांच लेखक के बाहर से आनी चाहिए: गेट पर एक ज़्यादा मज़बूत मॉडल, या रिक्वेस्ट से लिखे आपके अपने टेस्ट	उसी मॉडल ने अपना बग 11 में से 11 बार चूका	Haiku + Opus checker के लिए $1.36 प्रति टास्क
Opus के साथ किसी साफ रिक्वेस्ट पर, /verify टाइप करना छोड़ें	0 नतीजे बदले	2.5x लागत, 125 सेकंड बनाम 75 सेकंड

सीमाएं: एक छोटी लाइब्रेरी, छह साफ रिक्वेस्ट, हर सेल में एक से तीन रन, हेडलेस सेशन, और छुपे टेस्ट जो सिर्फ वही जांचते हैं जो हर रिक्वेस्ट में लिखा है। ज़्यादा उलझे काम पर, ये आंकड़े बदल सकते हैं।