ज़्यादा स्मार्ट मॉडल से बेहतर हैं एआई कोडिंग एजेंट गार्डरेल्स

एक समीक्षक ने मेरा कोड देखा और उसमें एक बग पाया। एक रूट को 404 त्रुटि देनी चाहिए थी, लेकिन वह 500 त्रुटि दे रहा था। उसने फ़ाइल और लाइन के साथ अपनी खोज साफ़-साफ़ बताई।

मेरे एजेंट ने वह रूट ठीक कर दिया। बस वही एक।

पाँच दूसरे रूट में बिल्कुल वही बग था। वे बिना छुए वहीं पड़े रहे, जबकि एजेंट ने बताया कि काम पूरा हो गया — और वह झूठ नहीं बोल रहा था। जो चीज़ दिखाई गई थी, उसने उसे ठीक कर दिया था। उसने बस यह पूछने की नहीं सोची कि वही गलती और कितनी जगह छिपी हुई है।

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

एआई कोडिंग एजेंट चुपचाप कहाँ गलत हो जाते हैं

जिन विफलताओं में मेरा सबसे ज़्यादा समय गया, तकनीकी तौर पर उनमें कुछ भी समान नहीं था। संरचना के स्तर पर उनमें एक बात समान थी: हर मामले में कोई ज़रूरी चीज़ लिखकर दर्ज करने के बजाय किसी के दिमाग़ में रखी जा रही थी।

“उसने कहा काम हो गया। हुआ नहीं था।”

तुम्हें काम पूरा होने का संदेश मिलता है। कार्य-सूची की हर चीज़ पर निशान लगा होता है। फिर तुम देखते हो कि जहाँ लॉजिक होना चाहिए वहाँ TODO है, या कोई फ़ंक्शन खाली सूची लौटा रहा है, या कोई उपकार्य चुपचाप छोड़ दिया गया है।

यह बात समझने में मुझे बहुत ज़्यादा समय लगा। एजेंट झाँसा नहीं दे रहा होता। उसने अभी जो लिखा है, उसकी अपनी याद के आधार पर वह अपना काम जाँच रहा होता है, और वह याद सचमुच भरोसेमंद लगती है। हरे टेस्ट और कोड लिखने की साफ़-साफ़ याद मिलकर बिल्कुल ऐसा एहसास देते हैं जैसे काम पूरा हो गया हो।

इसके बजाय इसे दर्ज करो: ऐसा सबूत देखे बिना किसी चीज़ को पूरा मत मानो जिसे तुम खुद जाँच सको। यह दावा नहीं कि वह पास हुआ। असली आउटपुट, असली फ़ाइल, असली लाइन।

“उसने कोड ठीक करने के बजाय मेरा टेस्ट बदल दिया।”

यह ज़्यादा चुभता है, क्योंकि एजेंट वही कर रहा होता है जो तुमने कहा था। तुमने टेस्ट पास कराने को कहा। किसी विफल टेस्ट को पास कराने के दो तरीके हैं, और उनमें से एक बहुत आसान है।

इसके बजाय इसे दर्ज करो: काम शुरू होने से पहले मानदंड लिखो और उसके बाद उन्हें केवल पढ़ने योग्य मानो। अगर नतीजा उनसे मेल नहीं खाता, तो नतीजा गलत है। मानदंड नहीं। यह तब तक बिल्कुल स्पष्ट लगता है जब तक लक्ष्य को आधा इंच खिसकाने का मन तुम्हारा अपना न हो।

लंबी CLAUDE.md एजेंटों से निर्देश अनदेखे क्यों करवाती है

मेरी पहली सहज प्रतिक्रिया भी बाकी सब जैसी थी। सब कुछ CLAUDE.md में लिख दो। हर विफलता एक नया नियम बन गई और फ़ाइल बढ़ती गई।

हालात बदतर हुए। नाटकीय ढंग से नहीं — बस लगातार, ऐसे कि इसकी वजह किसी एक चीज़ को ठहराना मुश्किल था। नियम ऐसे तरीकों से एक-दूसरे का विरोध करने लगे जिन्हें मैं देख नहीं पाता था, और मॉडल चुपचाप कोई एक अर्थ चुन लेता तथा टकराव का ज़िक्र कभी नहीं करता। और जब शोधकर्ताओं ने रिपॉज़िटरी कॉन्टेक्स्ट फ़ाइलों को सचमुच परखा, तो वास्तविक समस्याओं पर इन फ़ाइलों से कार्य-सफलता बिल्कुल नहीं सुधरी। उन्होंने इन्फ़रेंस के बिल में 20% से ज़्यादा जोड़ दिया। निष्कर्ष यह था कि कॉन्टेक्स्ट फ़ाइल में केवल न्यूनतम ज़रूरी बातें रखी जाएँ।

यानी छोटे रूप में यही पूरी समस्या है। लंबी नियम फ़ाइल का मतलब है कि तुम भूलने वाली प्रणाली से और मेहनत से याद रखने को कह रहे हो। उसमें संभालने के लिए चीज़ें बढ़ती हैं, घटती नहीं।

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

बातें दर्ज करने की पाँच जगहें

यही पूरा विचार है। हर पंक्ति में ऐसी चीज़ है जो दिमाग़ में रखने पर विफल होती है, और उसके सामने वह जगह है जहाँ उसे दर्ज किया जाना चाहिए।

दिमाग़ में रखी चीज़	कहीं दर्ज की गई चीज़
“पूरा” होने का मतलब क्या होना था	काम से पहले लिखे गए मानदंड
क्या सच में जाँच हुई थी	ऐसा सबूत जिसे तुम देख सको
क्या तुम्हारा अपना काम अच्छा है	कोई अलग मॉडल जो उसे जाँचे
तीन घंटे पहले तुमने क्या तय किया था	डिस्क पर एक फ़ाइल
क्या यह कदम उठाना सुरक्षित है	ऐसा गेट जो इंसान के पास आकर रुकता है

इनमें से तीन को थोड़ा समझाना ज़रूरी है।

“अंत में मुझे अब भी सब कुछ खुद ही जाँचना पड़ता है।”

अगर तुमने आउटपुट पर भरोसा करना छोड़ दिया है, तो अब तुम खुद रुकावट हो और एजेंट से तुम्हें कोई लाभ नहीं मिला।

एजेंट से अपना ही काम जाँचने को कहना मदद नहीं करता, और इसकी वजह पर ठहरकर सोचना चाहिए: गलती उसी कॉन्टेक्स्ट में पैदा हुई थी, इसलिए वह उन्हीं तर्कों तक पहुँचता है। वह काम को परखने के बजाय उसका बचाव करेगा।

इसके बजाय इसे दर्ज करो: समीक्षा किसी अलग मॉडल को भेजो, बेहतर होगा कि वह किसी अलग कंपनी का हो। अलग प्रशिक्षण, अलग अनदेखे पहलू। मेरे पाँच-रूट वाले बग को खोजने वाला मॉडल वह नहीं था जिसने उसे लिखा था, और यह संयोग नहीं है।

“किसी चीज़ ने खुद को मंज़ूरी दे दी, और वह मैं नहीं था।”

एजेंट बहुत-सा ऐसा टेक्स्ट पढ़ते हैं जो उन्होंने नहीं लिखा — इश्यू थ्रेड, दस्तावेज़, वेब पेज और टूल आउटपुट। इनमें से किसी में भी “approved” शब्द हो सकता है। इन प्रणालियों के लिए OWASP की जोखिम सूची में प्रॉम्प्ट इंजेक्शन पहले स्थान पर है, और OWASP साफ़ कहता है कि सामान्य बचाव इसे पूरी तरह कम नहीं कर पाते।

इसके बजाय इसे दर्ज करो: मंज़ूरी का संबंध इस बात से है कि वह कहाँ से आई, न कि उसमें क्या लिखा है। किसी इंसान ने हाँ कहा, या डिस्क पर हस्ताक्षरित आर्टिफ़ैक्ट हाँ कहता है। बाकी सब कुछ जिसमें केवल “approved” शब्द मौजूद है, महज़ टेक्स्ट है।

“कम्पैक्शन ने चार घंटे का कॉन्टेक्स्ट निगल लिया।”

लंबा सेशन चलता है, कॉन्टेक्स्ट भर जाता है और बातचीत का सार बना दिया जाता है। सार में क्या हुआ था बचा रहता है, क्यों हुआ था खो जाता है। एक घंटे बाद तुम उस फ़ैसले पर फिर बहस कर रहे होते हो जिसे पहले ही तय कर चुके थे, और समझ नहीं पाते कि सावधानी बरत रहे हो या गोल-गोल घूम रहे हो।

इसके बजाय इसे दर्ज करो: एक फ़ाइल। फ़ैसले, मौजूदा स्थिति और अगला काम। सेशन फेंका जा सकता है; फ़ाइल नहीं। किसी चीज़ को पूरा बताने से पहले उसे दोबारा पढ़ो।

एआई कोडिंग एजेंट गार्डरेल्स की लागत

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

बँटवारा दिलचस्प है। मेरे खर्च का लगभग 80% भारी काम करने वाले सस्ते मॉडल पर गया, करीब 17% योजना और निर्णय करने वाले महँगे मॉडल पर, और करीब 3% दूसरी राय वाली समीक्षा पर — वही कदम जिसे लोग छोड़ देते हैं। सुरक्षा पूरे बिल में बहुत बड़े अंतर से सबसे सस्ती मद थी। कीमतें बदलने पर भी मेरी परियोजनाओं में यह बँटवारा लगभग ऐसा ही रहा।

संख्या की बात करें तो: जिन ज़्यादातर परियोजनाओं पर मैंने काम किया है, उनमें पुराने सिस्टम में यह व्यवस्था जोड़ने पर अगस्त 2026 की कीमतों के हिसाब से API उपयोग में लगभग $100 से $200 लगे। डॉलर से ज़्यादा अनुपात मायने रखता है — इतना बजट रखो और प्रयोग करने की उम्मीद भी। तुम एक-दो फ़ैसले वापस लोगे और कोई चरण फिर चलाओगे, और वह इस अनुमान में शामिल है।

तुम्हारी संख्या अलग होगी, और उसे बदलने वाली बातें साफ़ हैं: कोडबेस कितना बड़ा है, तुम कितनी बार अपना फ़ैसला बदलते हो और कितना काम सस्ते स्तर को सौंपते हो।

नई परियोजना शुरू करने में मेरा खर्च बहुत कम हुआ, और यही ज़्यादा उपयोगी तथ्य है। पैसा फ़्रेमवर्क पर नहीं लगता। वह तालमेल बिठाने पर लगता है — एक-एक करके यह तय करने पर कि गार्डरेल्स तुम्हारे मौजूदा टूल और आदतों में से किनकी जगह लेंगे और किनके हिसाब से उन्हें ढलना होगा। मेरे इंटीग्रेशन में फ़्रेमवर्क के अपने टेस्ट कमांड नहीं बचे; उन्हें हटाकर उन स्क्रिप्टों से बदल दिया गया जिन्हें परियोजना पहले से इस्तेमाल करती थी। नई परियोजना में तालमेल बिठाने के लिए कुछ नहीं होता।

एक से शुरू करो

तुम्हें पाँचों की ज़रूरत नहीं है। इस हफ़्ते जिस विफलता से तुम्हारा सबसे ज़्यादा नुकसान हो रहा है, उसे चुनो और उस एक चीज़ को कहीं दर्ज कर दो।

अगर तय नहीं कर पा रहे कि कौन-सी, तो स्वतंत्र समीक्षा से शुरू करो — पहले मॉडल के काम को देखने वाला दूसरा मॉडल। पाँचों में यह सबसे सस्ता है और समस्याओं की सबसे बड़ी विविधता पकड़ता है, उन समस्याओं सहित जिन्हें खोजने का ख़याल भी तुम्हें कभी नहीं आता।

पाँच-रूट वाला बग अब भी मेरा पसंदीदा उदाहरण है, क्योंकि उसमें कुछ भी मुश्किल नहीं था। एजेंट को बस एक निर्देश चाहिए था जो उसके पास नहीं था: कुछ ठीक करने से पहले उस जैसी बाकी हर चीज़ ढूँढ़ो। वह निर्देश अब एक फ़ाइल में रहता है। अगले सेशन में भी वह वहीं होगा, और उसके बाद वाले में भी, हम सभी के यह भूल जाने के बहुत बाद तक कि वह लिखा ही क्यों गया था।

सभी गार्डरेल्स और उन्हें अपनाने के चरणों वाला पूरा फ़्रेमवर्क GitHub पर है।

---

संसाधन

• वास्तविक समस्याओं पर परखी गई रिपॉज़िटरी कॉन्टेक्स्ट फ़ाइलें (ETH Zurich SRI)
• OWASP LLM01: प्रॉम्प्ट इंजेक्शन
• AGENTS.md, रिपॉज़िटरी कॉन्टेक्स्ट फ़ाइल का फ़ॉर्मैट
• Claude Code मेमोरी और CLAUDE.md
• गार्डरेल्स और उन्हें अपनाने के चरणों वाला एजेंटिक फ़्रेमवर्क

---