AI कोड कॉम्प्रिहेंशन चेक बनाम टेस्ट: कब कौन जीतता है

यहाँ एक ऐसी स्थिति है जो अब आम होती जा रही है: आपका कोडिंग एजेंट चार फ़ाइलों में 600 लाइनें लिखता है, टेस्ट पास हो जाते हैं, लिंटर भी खुश है, और आप merge कर देते हैं। दो हफ़्ते बाद production में कुछ टूटता है और आप diff को ऐसे घूरते हैं जैसे किसी अजनबी ने लिखा हो, क्योंकि कार्यात्मक रूप से किसी और ने ही लिखा था। विफलता कोड में नहीं थी। वह कोड और आपकी उसके बारे में मानसिक समझ के बीच के अंतर में थी। AI कोड कॉम्प्रिहेंशन चेक ऐसे गेट हैं जो shipping से पहले diff पर आपसे सवाल पूछते हैं, और यही अंतर पाटने की कोशिश कर रहे हैं। इस हफ़्ते Sphinx नाम का एक नया ओपन-सोर्स Git hook काफ़ी चर्चा में रहा, जो ठीक यही करता है: आपका push होने से पहले वह diff पढ़ता है और पूछता है कि चीज़ें गड़बड़ होने पर कोड क्या करता है।

एक पूर्व ML इंजीनियर के तौर पर मेरी पहली प्रवृत्ति संदेह की थी। एक और गेट? एक और रस्म? लेकिन जितना मैंने उन विफलता पैटर्न पर सोचा जो मैं एजेंट-जनित कोड में असल में देखता हूँ, उतना ही लगता है कि यह विचार ऐसी चीज़ को निशाना बनाता है जिसे टेस्ट संरचनात्मक रूप से पकड़ नहीं सकते। तो चलिए ईमानदार तुलना करते हैं: कॉम्प्रिहेंशन चेक बनाम वह ऑटोमेटेड सेफ़्टी नेट जो आपके पास पहले से है, यानी टेस्ट, लिंटर, type checker, CI, और कब हर एक सचमुच जीतता है।

टेस्ट और लिंटर असल में क्या सत्यापित करते हैं

ऑटोमेटेड चेक एक ही सवाल का जवाब देते हैं: क्या कोड उसी तरह व्यवहार करता है जैसा चेक उम्मीद करते हैं? यह लूप पूरी तरह मशीन के भीतर बंद होता है। टेस्ट किसी इंसान की सही व्यवहार के बारे में धारणा को कोड में लिखता है; कोड या तो उसे पूरा करता है या नहीं, और merge के समय किसी मानवीय समझ की ज़रूरत नहीं होती। यह एक खूबी है। इसी की वजह से सौ इंजीनियर बिना एक-दूसरे का काम पढ़े एक ही repo में shipping कर पाते हैं।

समस्या इस मॉडल में छिपी धारणा में है: कि merge करने वाले व्यक्ति के पास इस बात की सटीक मानसिक तस्वीर है कि कोड को क्या करना चाहिए, और टेस्ट suite उसे दर्शाता है। हाथ से लिखे कोड में यह धारणा ज़्यादातर सही बैठती है: आपने उसे लिखा, उससे जूझे, आप जानते हैं कि कहाँ क्या दबा है। एजेंट-जनित कोड में यह चुपचाप टूट जाती है। आपने एक लक्ष्य बताया, एजेंट ने implementation बनाया, और टेस्ट पास हो गए क्योंकि वे भी एजेंट ने ही लिखे। अब हरा checkmark यह प्रमाणित कर रहा है कि एजेंट का कोड एजेंट के टेस्ट से मेल खाता है। आपकी समझ लूप में कभी थी ही नहीं।

यह वही जाल है जिस पर मैंने AI benchmarks असल काम का ज़्यादातर हिस्सा क्यों नहीं माप पाते में लिखा था: कोई भी metric केवल वही प्रमाणित कर सकता है जो वह मापता है। टेस्ट suite उन मामलों पर व्यवहारिक अनुरूपता मापता है जिन्हें किसी ने लिखना सोचा। उसे यह नहीं पता कि retry logic Stripe timeout पर किसी ग्राहक से दोबारा पैसे तो नहीं काट लेता, एजेंट ने पूरी तरह गलत endpoint तो नहीं चुना, या 'fix' किसी exception को निगलकर race condition पर पर्दा तो नहीं डाल रहा। ये कॉम्प्रिहेंशन की विफलताएँ हैं, और ये CI से बेरोक-टोक निकल जाती हैं।

कॉम्प्रिहेंशन चेक वह क्या पकड़ते हैं जो टेस्ट छूट जाते हैं

कॉम्प्रिहेंशन चेक सत्यापन की दिशा पलट देता है। यह पूछने के बजाय कि 'क्या कोड काम करता है?', यह पूछता है कि 'इसे shipping करने वाला व्यक्ति जानता है कि चीज़ें गड़बड़ होने पर यह क्या करता है?' Sphinx का उदाहरण अच्छा है: आपका webhook handler अब charge() को कॉल करने से पहले Stripe event ID सेव करता है। timeout के बाद retry पर क्या होता है? अगर आप कहें 'ग्राहक से दो बार पैसे कटते हैं', तो आप गलत हैं, क्योंकि सेव किया गया ID retry को छोटा कर देता है। लेकिन फिर अगला सवाल: अगर charge() खुद फेल हो जाए, तो अगला retry क्या करेगा? वह charge को छोड़ देगा। ग्राहक से कभी पैसे नहीं लिए जाएँगे, और कोई टेस्ट फेल नहीं होगा, क्योंकि यह एक सही दिखने वाला idempotency पैटर्न है जो गलत क्रम में लगाया गया है।

ध्यान दीजिए कि यह किस तरह का bug है। यह syntax error, type error या फ़ेल होने वाला assertion नहीं है। यह एक डिज़ाइन दोष है जो केवल एक खास विफलता क्रम में सामने आता है, और production से पहले इसे सस्ते में पकड़ने का एकमात्र तरीका है कि कोई इंसान failure path पर सोचे। टेस्ट इसे पकड़ सकते थे, अगर कोई 'event ID सेव होने के बाद charge फेल' का टेस्ट लिखता। लेकिन जो व्यक्ति वह टेस्ट लिखता, वही क्रम के जोखिम को समझता, और अगर ऐसा व्यक्ति होता तो हम यहाँ नहीं होते। कॉम्प्रिहेंशन चेक ठीक उसी समझ की जाँच करते हैं जो गायब टेस्ट लिख देती।

एक दूसरा फ़ायदा है, जो बग पकड़ने से ज़्यादा एक धीमी skill leak को उलटने के बारे में है। कई डेवलपर्स यही अनुभव बताते हैं: एजेंट को काम करने वाले नतीजे तक धकेलने में असली ऊर्जा लगती है, पर पीछे कुछ सीखा हुआ नहीं बचता। आप ज़्यादा shipping करते हैं और कम समझते हैं, और यह अंतर बढ़ता जाता है। push के समय एक quiz diff के तर्क का कम से कम एक उथला पुनर्निर्माण करवा देता है, और अक्सर इतना ही काफ़ी होता है 'वह कोड जिसे मैंने approve किया' को वापस 'वह कोड जो मेरा है' में बदलने के लिए। मैं पहले भी लिख चुका हूँ कि AI tools चुपचाप डेवलपर्स की सोच बदल रहे हैं; ऐसे gates उन पहले औज़ारों में से हैं जो उल्टी दिशा में धकेलते हैं।

जब ऑटोमेटेड टेस्ट जीतते हैं

आइए मानवीय गेट को महान न बनाएँ। कई क्षेत्रों में टेस्ट निर्णायक रूप से जीतते हैं, और इसे नज़रअंदाज़ करना ही वह तरीका है जिससे आप एक quiz को अपने एकमात्र सेफ़्टी नेट के रूप में रख लेते हैं।

• बड़े पैमाने पर regression पकड़ना। 30,000 लाइन के refactor को कोई भी मानसिक मॉडल नहीं झेल सकता। टेस्ट हर commit पर हज़ारों व्यवहारों को कौड़ियों में फिर से सत्यापित कर देते हैं। कॉम्प्रिहेंशन चेक एक diff के शायद तीन सवालों जितना ही कवर कर सकता है।
• मशीनी सटीकता। Off-by-one errors, गलत format strings, गड़बड़ time zones: मशीनें इन्हें सब जगह जाँचने में किसी इंसान से बेहतर हैं, जो समय के दबाव में सवालों का जवाब दे रहा हो।
• दोहराव योग्यता। टेस्ट हमेशा एक जैसा चलता है। quiz के सवाल की गुणवत्ता इस पर निर्भर करती है कि उसे किस model ने बनाया और शुक्रवार शाम 5 बजे आप कितने जागे हुए हैं।
• Refactoring में भरोसा। जब व्यवहार बिल्कुल नहीं बदलना चाहिए, तब टेस्ट ही एकमात्र सार्थक जाँच हैं। कोड को समझना यह सत्यापित करने में मदद नहीं करता कि आपने उसे बदला नहीं।

कुछ प्रकार का कोड ऐसा भी है जहाँ कॉम्प्रिहेंशन चेक बिना मूल्य के बस झंझट जोड़ते हैं: generated boilerplate, यांत्रिक migrations, dependency bumps, config बदलाव। मुझसे Prettier reformat के बारे में सवाल पूछना एक gate नहीं, बल्कि एक कर है। इस क्षेत्र के किसी भी टूल को कम-जोखिम वाले diffs के लिए अच्छा जवाब चाहिए, नहीं तो लोग उसके आसपास से निकल जाएँगे। और दिलचस्प बात यह है कि Sphinx इसकी उम्मीद रखता है, उसके पास sphinx yolo वाला escape hatch है जो हर skip को लॉग करता है। यह लॉगिंग दिखने से ज़्यादा मायने रखती है: जिस gate को सब चुपचाप बायपास करें, वह कोई gate न होने से भी बुरा है।

जब कॉम्प्रिहेंशन चेक जीतते हैं

कॉम्प्रिहेंशन चेक ठीक उन जगहों पर जीतते हैं जहाँ इंसान सबसे कमज़ोर कड़ी होता है, और एजेंट-सहायित development में यह हम मानने से ज़्यादा बार होता है।

• Failure-path पर तर्क। Retries, timeouts, आंशिक writes, distributed transactions: वे code paths जो तभी चलते हैं जब कुछ और पहले से टूटा हो। एजेंट happy path पर ठीक-ठाक हैं और sad path के बारे में लापरवाह।
• बहुत अधिक असर वाले diffs। Payments, auth, data migrations, या कुछ भी जो ऐसी systems को छूता है जिन्हें तबाही से बचना चाहिए। यहाँ गलत जवाब की कीमत दो मिनट के quiz की झंझट से कहीं ज़्यादा है।
• ऐसा कोड जो आपने नहीं लिखा और मुश्किल से review किया। किसी गैर-डेवलपर सहकर्मी का 1,500 लाइन वाला PR, या एजेंट की रात भर चली autonomous branch। एक practitioner ने बताया कि वे ठीक ऐसे PRs की संरचित review के दौरान ध्यान बनाए रखने के लिए 'इस PR पर मुझसे quiz करो' prompt इस्तेमाल करते हैं।
• Onboarding और skill बनाए रखना। अगर आपकी टीम एजेंट का कोड किसी के domain सीखने से तेज़ shipping कर रही है, तो कॉम्प्रिहेंशन gate उपलब्ध सबसे सस्ता forcing function है।

समान धागा यह है: कॉम्प्रिहेंशन चेक तब अपनी कीमत वसूलते हैं जब diff महत्वपूर्ण हो और इंसान की मानसिक तस्वीर संदिग्ध हो। यह एक खास निचला क्षेत्र है, सार्वभौमिक समाधान नहीं।

गेट की अपनी विफलताएँ

अगर मैं आपको उन तरीकों की ईमानदार सूची न दूँ जिनसे यह गलत हो सकता है, तो मैं आपके साथ अन्याय करूँगा, क्योंकि संशयवादियों के पास असली तर्क हैं।

पहला, confirmation fatigue। हम पहले भी यहाँ आ चुके हैं: cookie banners, 'क्या आप निश्चित हैं?' वाले dialogs, security questions जिन्हें सब बिना सोचे क्लिक कर देते हैं। ऐसा gate जो हर push पर चले, लोगों को जल्दी जवाब देना सिखाता है, सोचना नहीं, और एक महीने में quiz एक रस्म भर रह जाता है। इसका उपाय है दायरा तय करना: इसे feature branch के हर commit पर नहीं, बल्कि protected branches और उच्च-जोखिम वाले paths पर चलाना।

दूसरा, सवालों की गुणवत्ता। quiz को एक LLM diff पढ़कर बनाता है, इसलिए वह LLM की सारी विफलताएँ विरासत में लेता है: उथले सवाल, गलत 'सही' जवाब, स्पष्ट बदलाव पर अटक जाना और सूक्ष्म बदलाव को छोड़ देना। एक समीक्षक ने बताया कि उनके संस्करण ने review को व्यवस्थित करने में मदद की, पर गलत endpoint चुनने जैसे खराब फ़ैसलों को नहीं पकड़ा। एक खराब सवाल किसी सवाल न पूछने से भी बुरा है, क्योंकि वह ऐसी समझ को प्रमाणित कर देता है जिसकी जाँच ही नहीं हुई। यह एक असली सीमा है और मुझे नहीं लगता कि यह पूरी तरह हल हो सकती है; यही कारण है कि इन टूल्स में agent harness डिज़ाइन अक्सर model चुनने से ज़्यादा मायने रखता है।

तीसरा, और इस पर मुझे हँसी आई क्योंकि यह सच है, कोई न कोई एजेंट को gate की ओर मोड़कर उसके सवालों के जवाब उसी से दिलवाएगा। टूल के डिज़ाइन में इसकी जागरूकता दिखती है: आपके जवाब कोड एजेंट तक नहीं पहुँचते और secrets बंद रहते हैं। लेकिन कोई दृढ़ डेवलपर सवाल को chat window में चिपकाने से नहीं रोका जा सकता। तब यह टूल वास्तव में धोखाधड़ी की इच्छा को माप रहा होता है, जो एक संस्कृति की समस्या है जिसे कोई hook ठीक नहीं कर सकता।

एक कॉम्प्रिहेंशन gate कोड को सत्यापित नहीं करता। वह सत्यापित करता है कि संदर्भ और जवाबदेही रखने वाले किसी इंसान ने उससे वाकई जुड़ाव किया, और यही वह चीज़ है जिसे एजेंट workflows चुपचाप हटा चुके हैं।

Gate को असली workflow में लगाना

अगर आप इसे आज़माना चाहते हैं, तो आपके पास दो व्यावहारिक विकल्प हैं। कम-घर्षण वाला रास्ता है आपके मौजूदा एजेंट में एक prompt-based skill: 'PR खोलने से पहले मुझसे इस branch पर quiz करो।' कई लोगों ने ठीक यही बनाया है और उनका कहना है कि यह review को व्यवस्थित करने में अच्छा काम करता है। पर ध्यान दें कि यह आपके इसे चलाने के चुनाव पर निर्भर है, जो ठीक तब फ़ेल होता है जब आप सबसे ज़्यादा जल्दी में हों।

लागू करने वाला रास्ता है Git hook। Sphinx एक मिनट में इंस्टॉल हो जाता है: npm install -g sphinx-understand, फिर sphinx install, जो Git और आपके coding agents को जोड़ता है और पूछता है कि review कौन सा model करे। यह Claude Code, Codex, Cursor और अन्य के साथ काम करता है, या सादे Git के साथ, और किसी भी OpenAI-compatible endpoint से चल सकता है। अगर आप अपना खुद बनाना चाहें, तो ढाँचा एक pre-push hook है:

#!/usr/bin/env bash
# .git/hooks/pre-push — quiz gate for protected branches
protected_branch="main"
current_branch=$(git rev-parse --abbrev-ref HEAD)
if [ "$current_branch" != "$protected_branch" ]; then
exit 0  # only gate the branches that matter
fi
diff=$(git diff origin/main...HEAD)
if [ -z "$diff" ]; then
exit 0
fi
# Send the diff to your model of choice, get a scenario question,
# check the answer. Pseudocode for the core loop:
question=$(quiz_generate "$diff")
echo "$question"
read -r answer
if ! quiz_verify "$diff" "$question" "$answer"; then
echo "Not quite — here's why. Push blocked; try again."
exit 1
fi

दो डिज़ाइन फ़ैसले कोड से ज़्यादा मायने रखते हैं। Gate pushes नहीं, branches पर लगाएँ: main और release branches पर push होने पर चलाएँ, और आदर्श रूप से 'review माँगें' पर भी, क्योंकि slop को टीममेट का ध्यान खर्च होने से पहले पकड़ना शायद सबसे ज़्यादा मूल्य वाली जगह है। और हर bypass को लॉग करें। escape hatch ज़रूरी है; ईमानदार रखने वाली चीज़ audit trail है।

यह भी सोचें कि यह मानव review के सापेक्ष कहाँ बैठता है। मैंने लिखा है कि review की हर परत टीम को धीमा करती है, और मैं उस पर कायम हूँ, इसलिए इसे सब कुछ के ऊपर न जोड़ें। इसका इस्तेमाल पहली, सबसे उथली review को बदलने के लिए करें: वह पास जो पूछता है 'क्या लेखक को भी पता है कि यह क्या करता है?' यही वह पास है जिसे कॉम्प्रिहेंशन चेक सचमुच स्वचालित करते हैं।

सिफ़ारिश

टेस्ट और कॉम्प्रिहेंशन चेक प्रतिस्पर्धी नहीं हैं, वे अलग विषयों को सत्यापित करते हैं। टेस्ट कोड को सत्यापित करते हैं; कॉम्प्रिहेंशन चेक उस व्यक्ति को सत्यापित करते हैं जो उसके लिए जवाबदेह है। एजेंट-सहायित development ने उस निहित धारणा को तोड़ दिया कि दोनों एक ही चीज़ हैं, और ये gates एक व्यावहारिक पैच हैं, कोई गिमिक नहीं।

मेरी सिफ़ारिश: अपने टेस्ट suite को मुख्य सेफ़्टी नेट के रूप में रखें, इसकी जगह कुछ नहीं ले सकता, और कॉम्प्रिहेंशन gate को सीमित रूप से जोड़ें, protected branches और उच्च-जोखिम paths पर, लॉग किए गए escape hatch के साथ। अगर आप ज़्यादातर कोड हाथ से लिखते हैं, तो आपको इसकी ज़रूरत नहीं; इस gate का मूल्य इस पर निर्भर करता है कि आपके diff का कितना हिस्सा आपने नहीं लिखा। और अगर quiz एक ऐसा काम लगने लगे जिसे आप बायपास करते हैं, तो यह भी एक संकेत है: इसका मतलब है कि आप ऐसा कोड इतनी तेज़ी से shipping कर रहे हैं जो आप समझते नहीं, और दो मिनट का ठहराव भी महँगा लगने लगा है। इस पर सोचें। इस टूल की थीसिस का असहज संस्करण ही सही है: आप सोचना outsource कर सकते हैं, पर समझ आपकी ही रहनी चाहिए, क्योंकि रात 3 बजे जब retry loop किसी का बिल नहीं बनाता, तब ड्यूटी पर एजेंट नहीं होता। आप होते हैं।