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