Claude Code verification loops: bench table, Stop hook checklist और sources

TL;DR

• Anthropic की अपनी सिफारिश मूल रूप से सही है: जिस मॉडल को feedback loop मिलता है, वह बेहतर काम करता है। समस्या यह है कि loop कौन चलाता है। 116 runs में built-in /verify ने 24 में से 24 बार PASS दिया, उस बदलाव पर भी जिसने बताई गई requirement तोड़ दी थी।
• जो मॉडल अपना ही बदलाव जाँचता है, उसका blind spot वही रहता है। Haiku 4.5 ने वही unique-field case 11 में से 11 runs में छोड़ा, हर same-model setup में, और उसके अपने /verify ने गलत case के आगे check mark लगा दिया।
• Opus 5.5 पर /verify की लागत 2.5x रही ($0.96 बनाम $0.39) और कोई नतीजा नहीं बदला। सादा Opus 12 में से 12 बार सही रहा और 11 runs में test suite खुद चलाई।
• Project skill मॉडल के लिए optional है: वह 24 में से 10 runs में चला, Haiku पर 6 में से 0। Stop hook हर run में चला, Opus पर लगभग 20% ज़्यादा खर्च पर।
• जो check काम आया, वह लेखक के बाहर से आया: वही /verify जब Opus ने चलाया तो Haiku के बदलाव पर 3 में से 3 बार FAIL कहा और bug का नाम बताया। Stop hook के रूप में जोड़ने पर Haiku ने 3 में से 3 बार bug ठीक किया, $1.36 प्रति task पर, जबकि अकेले Opus के लिखने पर $0.76।
• इसे अपनाएँ: deterministic हिस्से के लिए Stop hook, judgment वाले हिस्से के लिए ऐसा verifier जो लेखक नहीं है, और well-specified काम में Opus पर /verify नहीं।

मापों से क्या पता चलता है

Anthropic का दावा: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Blog इसे 5 कदमों का adoption workflow बनाता है: अपना सबसे ज़्यादा दोहराया जाने वाला manual check चुनें, built-in /verify आज़माएँ, procedure को सादी अंग्रेज़ी में skill के रूप में लिखें, उसे deterministic बनाएँ, फिर CI में ले जाएँ। s1 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

Field reports उस verification के बारे में हैं जिसका दावा हुआ पर जो चली नहीं। Issue #96416 में review verdict के 19 concerns थे, 5 verify हुए, फिर भी "accept as-is" दे दिया गया। s6 Issue #97039 में checklist लोड होने के बावजूद आंशिक checks के बाद "held up" का दावा है। s7 "build passes" और "production-ready" अलग मापदंड हैं, और हर चूक पर 2-3 बार दोबारा prompt करना पड़ता है। s8

हमारे bench ने हर "done" को hidden acceptance tests से परखा, जो agent ने कभी नहीं देखे। 112 task runs + 4 cross-model /verify runs = 116 runs, $66.29 API-बराबर खर्च। गलत "done": 112 में से 12, उनमें से 11 Haiku के T6 पर, setup A से E तक हर एक में, और 1 Sonnet का T6 पर skill setup के साथ, जहाँ उसके अपने नए tests fail हो रहे थे और skill चला ही नहीं। s1

Built-in /verify ने तीनों मॉडलों के 24 में से 24 runs में Verdict: PASS कहा (23 parse हो सके, 1 बिना label का pass), Haiku के टूटे T6 पर भी। Opus पर इसकी लागत $0.96 रही, बिना इसके $0.39 (2.5x), और 125 s बनाम 75 s; कोई नतीजा नहीं बदला। s3

5 कदमों के workflow के अनुसार लिखा project skill 24 में से 10 runs में बुलाया गया: Opus 8/12, Sonnet 2/6, Haiku 0/6। Stop hook हर run में चला, Opus पर $0.47 बनाम $0.39 (+20 %) में। s19

Blind spot एक requirement है, T6 req 4: एक ही update जो कई matched documents को वही unique value दे, उसे DuplicateKeyError उठानी चाहिए। Haiku ने इसे 11 में से 11 runs में छोड़ा, हर setup में (plain, /verify, skill, hook, tests first)। Haiku के अपने /verify ने "update one doc onto another's email" जाँचा और कभी ऐसा update नहीं आज़माया जो कई documents पर लगे। Tests-first नियम से मदद नहीं मिली: 3/3 अब भी req 4 चूके, और एक ने req 3 भी तोड़ दी। s1

वही Haiku बदलाव, /verify दूसरे मॉडल से चलाया गया: Sonnet ने PASS कहा (1/1), Opus ने 3/3 FAIL कहा, हर run में वही case बताया, एक update जो कई documents में एक ही value लिखता है, प्रति check $0.39 से $0.47 पर। Haiku पर Stop hook के रूप में (setup F), Opus verifier ने 3 में से 3 runs में bug ठीक करवाया; तीनों ठीक करते समय 60-turn की सीमा पर पहुँचे, verifier समेत औसतन $1.36 प्रति T6 run पर, जबकि अकेले T6 लिखने वाले Opus का औसत $0.76 रहा और 0 गलत "done" रहे। s19

माप

Harness: Claude Code 2.1.283 headless (claude -p), अलग config dir, हर task पर वही prompt, 60-turn की सीमा। Repo: msiemens/tinydb @ 18d73a1 (Python, 226 tests)। छह feature requests T1 से T6, हर एक में 5 बताई गई requirements (T5: 6)। Hidden acceptance tests, हर बताई गई requirement के लिए एक और agent को कभी न दिखाए गए, हर run को score करते हैं; repo की अपनी suite भी चलती है। गलत "done" वह run है जो पूरा होने का दावा करके खत्म हुआ जबकि कोई hidden test या repo suite fail हो रही थी।

Setups: A plain (सिर्फ request); B /verify (A, फिर दूसरे turn के रूप में built-in /verify); C verify skill (5 कदमों के workflow के अनुसार लिखा, मॉडल द्वारा बुलाया जा सकने वाला project skill); D Stop hook (prove-it.py: suite red रहने तक stop रोकता है, और पहले stop को हर requirement के लिए प्रमाण की एक पंक्ति माँगकर रोकता है); E tests first (CLAUDE.md नियम: किसी भी code से पहले हर requirement के लिए एक failing test); F Opus verifier hook (बदलाव पर claude -p /verify --model opus, non-PASS verdict पर रोकता है, अधिकतम 2 rounds)।

सीमाएँ: एक repo (छोटी, अच्छी तरह tested Python library), छह well-specified requests, हर cell में 1 से 3 दोहराव, headless runs। Hidden tests सिर्फ वही जाँचते हैं जो request में बताया गया है।

सोमवार को यह करें

• मॉडल का "done" पढ़ने से पहले, हर बताई गई requirement के लिए एक acceptance test खुद लिखें। Bench के hidden tests ने वह पकड़ा जो हर same-model check से छूटा।
• एक Stop hook जोड़ें जो आपकी test suite चलाए और suite red रहने तक block decision लौटाए। यह हर run में चलता है; skill नहीं चलता।
• किसी task का पहला stop हर requirement के लिए प्रमाण की एक पंक्ति पर निर्भर रखें (prove-it.py pattern): एक command और उसका output, कोई वाक्य नहीं।
• Judgment वाला check ऐसे मॉडल को दें जिसने बदलाव नहीं लिखा: diff पर claude -p /verify --model opus, non-PASS verdict पर blocking, 2 rounds तक सीमित।
• Opus 5.5 पर well-specified request के साथ आदतन /verify टाइप करना बंद करें। इसकी लागत 2.5x रही और 12 runs में कुछ नहीं बदला; इसे बिना tests वाले हिस्से या पहले से मौजूद bug की खोज के लिए रखें।
• अगर लागत के लिए Haiku 4.5 को काम सौंपते हैं, तो verifier का बजट रखें: Opus hook के साथ $1.36 प्रति task, जबकि अकेले Opus के लिखने पर $0.76।
• फेल हुए fix के हर retry को ledger में दर्ज करें और एक दोहराव के बाद loop रोक दें, ताकि blocking hook उसी गलत patch पर tokens न जलाए।
• अपनी requirements को multi-row case के लिए दोबारा पढ़ें: "एक update जो कई documents से मेल खाए" उसी case का रूप है जिसे 11 में से 11 Haiku runs ने कभी नहीं आज़माया।

आगे पढ़ें

• 5 कदमों का workflow और maturity ladder, manual check से CI gate तक: ऊपरी पायदान (CI और PR gates) वह जगह हैं जहाँ deterministic हिस्सा आपका hook लोकल में चल जाने के बाद रहना चाहिए। s1
• Stop hook semantics: कारण के साथ block decision turn को वापस मॉडल के पास भेजता है; अपना gate लिखने से पहले exit code और JSON contract पढ़ लें। s19
• Groundtruth, एक Stop hook जो checks पास होने तक turn खत्म नहीं होने देता: विचार का deterministic रूप, reference implementation के तौर पर पढ़ने लायक। s5
• regressionledger, लागत का पहलू: एक hook जो loop को उसी फेल हुए fix को दोबारा आज़माने से रोकता है, वह हिस्सा जो हमारे Stop hook में नहीं था जब runs 60-turn की सीमा पर पहुँचे। s10

स्रोत

• Building verification loops in Claude Code with skills, Anthropic blog. क्यों पढ़ें: 5 कदमों का workflow और वह ladder जिस पर bench का skill setup बना है।
• Building verification loops in Claude Code, आधिकारिक Claude channel. क्यों पढ़ें: पहली बार चलाने पर /verify क्या करता है, इस पर तीन मिनट, इससे पहले कि आप तय करें कि इसे रखना है या नहीं।
• Claude Code CHANGELOG, GitHub. क्यों पढ़ें: v2.1.215 वह जगह है जहाँ /verify सिर्फ user द्वारा बुलाया जाने वाला बना, जिससे आपके लिए इसके चलने की आवृत्ति बदल जाती है।
• Boris Cherny: give Claude a way to verify its work, X. क्यों पढ़ें: "2-3x the quality" वाला दावा, उसके ठीक शब्दों में।
• Groundtruth, GitHub. क्यों पढ़ें: शून्य से लिखने के बजाय नकल करने लायक एक चालू Stop hook gate।
• Issue #96416, GitHub. क्यों पढ़ें: एक review verdict का तारीख वाला transcript, जिसने 19 में से 5 concerns verify किए और फिर भी accept कर लिया।
• Issue #97039, GitHub. क्यों पढ़ें: दो दिन बाद वही विफलता, checklist लोड होने के साथ, यानी checklist समाधान नहीं है।
• AI coding agents can verify some of their work now, dev.to. क्यों पढ़ें: "build passes" और "production-ready" के बीच के अंतर का सबसे साफ बयान।
• Saguaro, GitHub. क्यों पढ़ें: in-loop बनाम PR-level review की बहस, comments में प्रतिवाद के साथ।
• regressionledger, GitHub. क्यों पढ़ें: blocking hook से पैदा होने वाली retry-लागत की समस्या, और उसे सीमित करने का एक तरीका।
• SPICE simulation to oscilloscope to verification with Claude Code, personal blog. क्यों पढ़ें: एक verification loop जिसका oracle भौतिक उपकरण है।
• Hooks reference, code.claude.com. क्यों पढ़ें: block decision का वह contract जिसका आपके Stop hook को पालन करना है।

FAQ

क्या built-in /verify bugs पकड़ता है?

इस bench में नहीं। इसने Opus 5.5, Sonnet 5 और Haiku 4.5 के 24 में से 24 runs में PASS दिया, उस Haiku बदलाव पर भी जिसने बताई गई requirement तोड़ी थी। इसकी एकमात्र उपयोगी खोज एक पहले से मौजूद upstream bug थी जिसका बदलाव से कोई संबंध नहीं था।

मज़बूत verifier कमज़ोर लेखक की मदद क्यों करता है?

Haiku के अपने check ने वही case जाँचा जिसके बारे में वह पहले सोच चुका था। Opus ने उसी बदलाव और उसी /verify के साथ कई documents पर लगने वाला एक update आज़माया और 3 में से 3 बार FAIL कहा। Sonnet ने PASS कहा। Verifier को वह case दिखना चाहिए जो लेखक को नहीं दिखा।

Haiku को Opus से verify करना सस्ता है, या Opus से ही लिखना?

Opus से लिखें। Haiku पर Opus verifier hook का औसत $1.36 प्रति T6 run रहा और हर बार 60-turn की सीमा छुई; अकेले T6 लिखने वाले Opus का औसत $0.76 रहा, 0 गलत "done" के साथ।