यह टेस्ट क्यों महत्वपूर्ण है
AI-संचालित कोड असिस्टेंट अक्सर टीमों को रेपो (repo) में एक "rules" फ़ाइल डालने देते हैं और उम्मीद करते हैं कि मॉडल हर अनुरोध पर उसके निर्देशों का पालन करेगा। व्यवहार में, हो सकता है कि मॉडल उस फ़ाइल को कभी देख ही न पाए, या वह उसे देख ले लेकिन उसकी सामग्री को नज़रअंदाज़ कर दे। Claude Code के साथ किए गए एक हालिया प्रयोग ने ये दोनों समस्याएँ दिखाईं। टूल ने चुपचाप 72 KB की AGENTS.md फ़ाइल को छोड़ दिया; जब उसी फ़ाइल का नाम बदलकर CLAUDE.md कर दिया गया, तो असिस्टेंट ने उसे लोड कर लिया और प्रत्येक अनुरोध के लिए टोकन काउंट (token count) बढ़ गया। वह अतिरिक्त टोकन बजट लेटेंसी (latency), लागत को बढ़ाता है और किसी अनुरोध को मॉडल की सीमा से बाहर धकेल सकता है।
जो डेवलपर्स यह मान लेते हैं कि "फ़ाइल मौजूद है" का मतलब है "मॉडल नियमों का पालन करता है", वे छिपी हुई अक्षमताओं और अप्रत्याशित आउटपुट का जोखिम उठाते हैं। यह तीन-चरणीय टेस्ट प्रत्येक चरण में ठोस प्रमाण सुनिश्चित करता है: कॉन्फ़िगरेशन (configuration), लोडिंग (loading), और उपयोगिता (usefulness)।
पूछे जाने वाले तीन प्रश्न
- Configured (कॉन्फ़िगर किया गया) – क्या फ़ाइल वहीं रखी गई है जहाँ असिस्टेंट उसे ढूँढता है? अलग-अलग टूल्स में पाथ (paths) या फ़ाइल नाम के कन्वेंशन हार्ड-कोड होते हैं; तालमेल न होने का मतलब है कि फ़ाइल कभी प्रॉम्प्ट पाइपलाइन में नहीं आएगी।
- Loaded (लोड किया गया) – क्या असिस्टेंट इस बात का कोई प्रमाण देता है कि उसे फ़ाइल प्राप्त हुई है? एक हैश (hash) डिस्क पर फ़ाइल की पहचान की पुष्टि कर सकता है, लेकिन केवल एक डिलीवरी ट्रेस (जैसे, लॉग लाइन या टोकन काउंट) ही यह साबित करता है कि मॉडल ने वास्तव में उसे देखा है।
- Useful (उपयोगी) – क्या फ़ाइल की उपस्थिति कार्य के परिणाम में सुधार करती है? एक लोड की गई फ़ाइल जो टोकन तो बढ़ाती है लेकिन परिणाम को अपरिवर्तित छोड़ देती है, वह शुद्ध नुकसान है।
टेस्ट चलाना
यह प्रक्रिया जानबूझकर न्यूनतम रखी गई है ताकि इसे किसी भी प्लेटफॉर्म पर दोहराया जा सके।
एक दृश्य नियम बनाएँ – एक सरल, अवलोकन योग्य निर्देश लिखें। उदाहरण के लिए: "एडिट करने से पहले ठीक दो फ़ाइलों की सूची दें।" नियम के प्रभाव की जाँच असिस्टेंट के जवाब में की जा सकती है।
टूल का वर्शन और मॉडल जाँचें – एक नया सेशन खोलें, वर्शन स्ट्रिंग और मॉडल आइडेंटिफायर (identifier) नोट करें। अलग-अलग वर्शन उन फ़ाइल नामों को बदल सकते हैं जिन्हें वे पहचानते हैं।
दो रन (runs) निष्पादित करें Run A: एक ऐसा फ़ाइल नाम उपयोग करें जिसे टूल नहीं पहचानता (जैसे, AGENTS.md)। Run B: टूल के नेटिव फ़ाइल नाम का उपयोग करें (जैसे, CLAUDE.md)।
रिकॉर्ड करें:
- फ़ाइल का सोर्स हैश (यह साबित करने के लिए कि डिस्क पर मौजूद सामग्री नहीं बदली है)।
- उपयोग किया गया सटीक पाथ।
- फ़ाइल लोड करने के बारे में असिस्टेंट द्वारा लॉग किया गया कोई भी प्रमाण (टोकन काउंट में वृद्धि, स्पष्ट "loaded X.md" संदेश, आदि)।
- प्रत्येक अनुरोध के लिए टोकन काउंट।
- कार्य का परिणाम (क्या असिस्टेंट ने ठीक दो फ़ाइलों की सूची दी?)।
यदि Run B में नियम का पालन होता दिख रहा है और टोकन काउंट अपेक्षित मात्रा में बढ़ता है, तो फ़ाइल लोड भी हुई है और उपयोगी भी है। यदि टोकन बढ़ने के बावजूद नियम को नज़रअंदाज़ किया जाता है, तो इसका मतलब है कि फ़ाइल पढ़ी तो जा रही है लेकिन मॉडल का प्रॉम्प्ट पार्सिंग (parsing) निर्देश को हटा देता है। उस स्थिति में, फ़ाइल में अधिक टेक्स्ट जोड़ने से कोई मदद नहीं मिलेगी; इसके बजाय नियम को किसी हार्ड-कोडेड पॉलिसी गेट (policy gate) या टेस्ट हार्नेस (test harness) में स्थानांतरित कर दें।
डेटा क्या दर्शाता है
Claude Code के मामले ने कॉन्फ़िगरेशन और लोडिंग के बीच एक बड़ा अंतर दिखाया। 72 KB की फ़ाइल मौजूद थी, उसका हैश सही था, और वह रेपो के साथ सिंक थी, फिर भी असिस्टेंट ने कभी उसका संदर्भ नहीं दिया। फ़ाइल का नाम बदलकर नेटिव CLAUDE.md करने से लोडिंग शुरू हो गई, लेकिन इससे टोकन का काफी ओवरहेड (overhead) भी बढ़ गया। प्रत्येक अतिरिक्त टोकन कंप्यूट साइकिल (compute cycles) का उपयोग करता है और अनुरोध को रेट लिमिट (rate limits) से बाहर धकेल सकता है।
यह तीन-चरणीय टेस्ट ऐसे छिपे हुए खर्चों को प्रोडक्शन ब्लॉकर (production blockers) बनने से पहले ही सामने ले आता है। टोकन डेल्टा (token delta) को कैप्चर करके, टीमें यह तय कर सकती हैं कि क्या नियम का लाभ उसकी लागत से अधिक है।
निष्कर्ष
कभी यह न मानें कि केवल रेपो में होने से कोई नियम फ़ाइल काम कर रही है। उस धारणा को मापने योग्य प्रमाण में बदलने के लिए तीन-चरणीय टेस्ट—कॉन्फ़िगर करें, लोड करें, उपयोगिता सिद्ध करें—का उपयोग करें। जब प्रमाण से पता चले कि फ़ाइल केवल एक "टोकन सिंक" (token sink) है, तो लॉजिक को प्रॉम्प्ट से हटाकर एक डिटरमिनिस्टिक गेट (deterministic gate) में डाल दें। इसका परिणाम एक अधिक सुव्यवस्थित, तेज़ और अनुमानित AI कोडिंग वर्कफ़्लो होगा।