आपके AI कोडिंग एजेंट फ़ाइल पथों का भ्रम क्यों बनाते हैं

यह संकेत गलत फ़ंक्शन बॉडी नहीं है। यह एक ऐसी फ़ाइल पर आत्मविश्वासी बदलाव है जो मौजूद ही नहीं है, या एक ऐसी फ़ाइल पर जो मौजूद है लेकिन वह उस व्यवहार को लागू नहीं करती।

आपने सत्र समाप्ति का फ़िक्स मांगा। एजेंट src/auth/session.ts खोलता है। पथ प्रशंसनीय है। यह गलत भी है। असली हैंडलर apps/api/src/middleware/expiry.ts में रहता है, जिसका नाम दो पुनर्संरचनाओं पहले बदला गया था। एजेंट आपसे झूठ नहीं बोल रहा। यह प्रशिक्षण पूर्वाग्रह और संदर्भ विंडो में पहले से मौजूद जो कुछ भी है, उसके आधार पर पथ-आकार की स्ट्रिंग पूरी कर रहा है।

यह वास्तविक रिपॉज़िटरी पर एक सामान्य विफलता पैटर्न है। मॉडल कोड लिख सकता है। इसकी गलती इसे लिखने के लिए गलत जगह चुनना है।

एजेंट्स पथों का आविष्कार क्यों करते हैं

कोडिंग एजेंट्स टूल्स से लैस अगला-टोकन भविष्यवाणी मॉडल हैं। जब आप कहते हैं ‘सत्र समाप्ति ठीक करो’, इसे कुछ भी पढ़ने या पैच करने से पहले एक फ़ाइल का नाम लेना चाहिए। अगर इसके पास पहले से आधारित मैप नहीं है, तो यह इनसे पथ बनाता है:

1. नामकरण कन्वेंशन जो इसने अन्य रिपॉज़िटरी में देखी हैं। src/auth/session.ts एक सामान्य रूप है।
2. फ़ाइलें जो पहले से बातचीत में हैं, जो वह फ़ाइल हो सकती है जो आपने पिछले हफ़्ते चिपकाई थी, न कि जो अभी मायने रखती है।
3. एक डायरेक्टरी लिस्टिंग जो इसने संयोग से चलाई, एक बड़े ट्री पर अधूरी।
4. इंस्ट्रक्शन फ़ाइलें। CLAUDE.md और AGENTS.md एजेंट को व्यवहार करने का तरीका बताती हैं। यह सिंबल, कॉलर, या वर्तमान पथों का जीवित इंडेक्स नहीं है।

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

Grep यहाँ आपको नहीं बचाता अगर एजेंट पहले सही स्ट्रिंग की खोज ही नहीं करता। एजेंट एक पथ का अनुमान लगाता है, फिर वह पथ जो लौटाता है उसे पढ़ता है, फिर उसे संपादित करता है। पहला गलत कदम पथ है, पैच नहीं।

फ़ाइलें पढ़ना सही खोजने के समान भी नहीं है। Claude Code, Cursor, Codex, और इसी तरह के टूल आपके द्वारा दिखाई गई किसी भी चीज़ को खोल सकते हैं। सवाल यह है कि क्या वे संपादित करने से पहले विश्वसनीय रूप से सही फ़ाइल, महत्वपूर्ण सिंबल, डिपेंडेंसी, टेस्ट, और ब्लास्ट रेडियस ढूँढते हैं। बिना मैप के फ़ाइल एक्सेस अभी भी अनुमान से शुरू होता है।

गलत फ़ाइल संपादित करना एक पुनर्प्राप्ति समस्या है

आविष्कृत पथ को एक पुनर्प्राप्ति गलती के रूप में सोचें, कोई चरित्र दोष नहीं।

अगर एजेंट को संपादित करने की अनुमति देने से पहले path/file.ext:line वापस लाना पड़े, तो दो चीज़ें होती हैं। पहला, आप उद्धरण खोल सकते हैं और दस सेकंड में काम को अस्वीकार कर सकते हैं। दूसरा, एजेंट को कुछ ऐसा पूछना पड़ता है जो वास्तव में उस ट्री को जानता है।

यही कोडबेस संदर्भ परत का काम है। अकेले semantic सर्च पर्याप्त नहीं है। एक उद्धरण जो ‘सत्र समाप्ति जैसा लगता है’ फिर भी एक अप्रचलित पैकेज में उतर सकता है। आपको सटीक टेक्स्ट भी चाहिए जब आप स्ट्रिंग जानते हैं, सिंबल सर्च जब आप नाम जानते हैं, structural सर्च जब आप आकार जानते हैं, और dependency ग्राफ़ जब आपको कॉलर व ब्लास्ट रेडियस चाहिए।

Maguyva MCP-संगत कोडिंग एजेंट्स के लिए वह परत है। यह एडिटर नहीं है। Claude Code, Cursor, Codex CLI, VS Code, Windsurf, और अन्य MCP क्लाइंट्स अपनी जगह पर बने रहते हैं। एजेंट एक लाइन छूने से पहले रैंक किए गए मैप को पूछता है।

जो दावा किया गया है वह जानबूझकर मामूली है: कम भ्रामक बदलाव। Maguyva मॉडल से अनुमान लगाने की क्षमता नहीं छीनता। यह डिफ़ॉल्ट पहले कदम को ‘प्रशंसनीय पथ का आविष्कार करो’ से बदलकर ‘रैंक किए गए, उद्धृत स्थान मांगो’ कर देता है।

एक आधारित जवाब कैसा दिखता है

‘सत्र समाप्ति कहाँ संभाली जाती है’ का उपयोगी जवाब एक पैराग्राफ नहीं है। यह छोटे स्थानों की एक सूची है:

• apps/api/src/middleware/expiry.ts:48 - हैंडलर
• apps/web/src/lib/auth-client.ts:112 - कॉलर
• apps/api/tests/expiry.test.ts:20 - टेस्ट जो अगर बदलाव गलत है तो विफल होगा

आप इन लाइनों को खोल सकते हैं। अगर गलत हैं, तो आप रुक जाते हैं। अगर सही हैं, तो एजेंट संपादित कर सकता है। सत्यापन ही मुख्य बात है, नारा नहीं।

Maguyva सर्च, सिंबल, dependency विश्लेषण, फ़ाइल पुनर्प्राप्ति, रिपॉज़िटरी संदर्भ, और नियतात्मक यूटिलिटी-टूल वर्कफ़्लो में 11 ग्राहक-सामना करने वाले MCP टूल उजागर करता है। चार पुनर्प्राप्ति मोड (semantic, structural, graph/dependency, और text) एक रैंक किए गए परिणाम में मिलते हैं; सिंबल सर्च एक अलग MCP टूल है (find_symbol)। आधारित जवाब फ़ाइल पथों और लाइन नंबरों के साथ वापस आते हैं, ताकि आप उन्हें अपने सामने के ट्री के मुकाबले आंक सकें।

दस्तावेज़ीकरण सबसे छोटा पथ बताता है: मुफ़्त में शुरू करें, उस repo को इंडेक्स करें जिसे आप पहले से जानते हैं, क्लाइंट कनेक्ट करें, फिर एक सवाल पूछें जिसे आप सत्यापित कर सकते हैं।

वह लूप जो पहला बदलाव बदल देता है

आपको एक नए वर्कफ़्लो धर्म की ज़रूरत नहीं है। आपको पहली लिखाई से पहले एक अतिरिक्त कदम चाहिए।

1. एक ऐसा सवाल पूछें जिसे आप पहले से आंक सकते हैं। ‘लॉगिन और सत्र समाप्ति किस कोड में संभाली जाती है?’ ‘auth ठीक करो’ से बेहतर है।
2. उद्धरण मांगें। फ़ाइल पथ और लाइन नंबर, न कि ‘auth मॉड्यूल’ का सारांश।
3. उद्धृत फ़ाइल खोलें। सिंबल का पीछा करें। उन डिपेंडेंसी की पुष्टि करें जिन्हें आप छूने वाले हैं।
4. उसके बाद ही एजेंट को पैच करने दें।

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

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

एक संबंधित विफलता है लगभग-सही फ़ाइल: एजेंट auth.ts खोलता है जबकि व्यवहार auth-client.ts में रहता है, या स्रोत के बजाय जनरेट की गई फ़ाइल को पैच करता है, या packages/legacy में एक प्रतिलिपि को संपादित करता है क्योंकि नाम मेल खाता है। उद्धरण इन गलतियों को असंभव नहीं बनाते। वे इन्हें diff उतरने से पहले दिखाई देने योग्य बनाते हैं।

मैप आपके लिए क्या ठीक नहीं करेगा

आपको जो मिलता है उसके बारे में ईमानदार रहें। एक आधारित मैप हर बदलाव को सही नहीं बनाएगा — आपका एजेंट फिर भी बिल्कुल सही फ़ाइल पर एक खराब पैच लिख सकता है। अगर आपका कोडबेस डायनामिक डिस्पैच, रिफ़्लेक्शन, या मंकी-पैचिंग पर निर्भर है, तो कुछ सिंबल सर्च आपकी उम्मीद से पतले परिणाम देंगे, क्योंकि रनटाइम अप्रत्यक्षता किसी भी स्टेटिक इंडेक्स के साथ यही करती है। और अगर आप एक प्रतिशत की उम्मीद कर रहे हैं — ‘भ्रामक पथ X% कम हुए’ — तो आपको यह यहाँ नहीं मिलेगा, क्योंकि कोई भी आपके repo के लिए वह संख्या ईमानदारी से आपके सिवा किसी और के लिए माप नहीं सकता।

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

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

// it doesn't know the file. it knows how to find it.