पहले मैप, फिर समीक्षा

पुल रिक्वेस्ट के दोनों ओर दो अलग-अलग काम बैठे हैं। एजेंट के लिखने से पहले, उसे उस ट्री के मैप की ज़रूरत होती है जिसे वह बदलने वाला है। एजेंट के PR खोलने के बाद, कुछ को उस बदलाव को बाकी सिस्टम के मुकाबले पढ़ना चाहिए और मनुष्य के लिए कार्रवाई योग्य टिप्पणी छोड़नी चाहिए।

ये काम दूर से एक जैसे दिखते हैं क्योंकि दोनों में ‘कोडबेस को समझना’ शामिल है। यह एक ही उत्पाद नहीं है। एक जवाब देता है ‘यह बदलाव कहाँ उतरना चाहिए?’। दूसरा जवाब देता है ‘इस diff में क्या टूटता है जिसे लाइन-दर-लाइन लिंटर मिस कर देगा?’। इन्हें मिलाने से बदतर पहला ड्राफ्ट और शोरगुल भरी समीक्षा मिलती है।

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

यह विभाजन क्यों उपयोगी है

एक कोडिंग एजेंट जो प्रशिक्षण पूर्वाग्रह और कुछ चिपकाई गई फ़ाइलों से शुरू होता है, वह एक प्रशंसनीय पथ का आविष्कार करेगा और उसे संपादित करेगा। यह ‘गलत फ़ाइल’ विफलता है, और यह एक पुनर्प्राप्ति समस्या है। Maguyva एक रिमोट MCP कोडबेस संदर्भ परत है: semantic, structural (AST), graph/dependency, और text पुनर्प्राप्ति एक रैंक किए गए परिणाम में मिलती है, साथ ही सिंबल सर्च और फ़ाइल पुनर्प्राप्ति भी। आधारित जवाब path/file.ext:line के रूप में वापस आते हैं, ताकि आप पैच बनने से पहले गलती को अस्वीकार कर सकें। जो दावा किया गया है वह जानबूझकर मामूली है: कम भ्रामक बदलाव। मॉडल फिर भी अनुमान लगा सकता है। बस पहला कदम अब अनुमान नहीं रहता।

Greptile एक AI-संचालित कोड समीक्षा एजेंट है। अपने ही शब्दों में, यह कोडबेस की पूरी समझ के साथ हर पुल रिक्वेस्ट की स्वचालित रूप से समीक्षा करता है, और इसे उन पारंपरिक लिंटर के मुकाबले रखता है जो पूरे सिस्टम के बजाय फ़ाइलों को अलग-अलग जाँचते हैं। सेटअप में GitHub या GitLab ऐप इंस्टॉल करना और एक रिपॉज़िटरी चुनना शामिल है। कोई स्थानीय इंडेक्स नहीं जो आपको चलाना पड़े। होस्टिंग Greptile Cloud है (वे SOC 2 Type II अनुपालन बताते हैं, जिसकी रिपोर्ट अनुरोध पर उपलब्ध है), साथ ही एंटरप्राइज़ के लिए सेल्फ़-होस्ट का विकल्प भी दिया गया है।

उनका अपना क्रमांकित प्रवाह है: कनेक्ट करें और हर फ़ंक्शन, क्लास व dependency का dependency ग्राफ़ बनाएँ; हर पुल रिक्वेस्ट पर, उस पूर्ण repo ग्राफ़ का उपयोग करके बदलाव का विश्लेषण करें और लगभग तीन मिनट में सुझाए गए सुधारों के साथ निष्कर्षों को PR टिप्पणी के रूप में प्रकाशित करें; हर टिप्पणी उस मुद्दे को टीम के पहले से उपयोग किए जा रहे कोडिंग एजेंट को सौंप सकती है। वे यह भी बताते हैं कि टीम के कोड मानकों को सीखने और शोरगुल वाले सुझावों को कम करने के लिए वे समय के साथ पिछली मानवीय PR टिप्पणियाँ पढ़ते हैं। उनका सीखने का सिस्टम, उनके अपने अनुसार, समायोजित होने में 2-3 सप्ताह लेता है।

यह समीक्षा है, ड्राफ्टिंग नहीं। Greptile की ताकत PR में पहले से उतरे बदलाव के विरुद्ध पूर्ण repo ग्राफ़ संदर्भ है, इसके बाद एक बंद लूप जो निष्कर्षों को Claude Code, Codex, Conductor, Cursor, या Devin को भेजता है। Maguyva की ताकत वह रैंक किया गया मैप है जिसे एजेंट बदलाव लिखे जाने से पहले पूछता है। दोनों का उपयोग करें। एक से दूसरे का काम करने के लिए न कहें।

Maguyva और Greptile के बीच कोई प्रथम-पक्ष उत्पाद एकीकरण नहीं बताया गया है। आपको इसकी ज़रूरत भी नहीं है। Maguyva MCP के ज़रिए एजेंट्स से बात करता है। Greptile अपने ऐप के ज़रिए GitHub या GitLab से बात करता है। वे पुल रिक्वेस्ट पर मिलते हैं। कोई जोड़-तोड़ वाली स्क्रिप्ट नहीं, कोई cron नहीं जो एक टूल को दूसरे में फीड करे। इस जोड़ी को bash की ज़रूरत नहीं क्योंकि हर उत्पाद पहले से ही उस सतह पर बैठा है जो उसकी है।

यह क्या नहीं है

यह Greptile को नीचा दिखाना नहीं है। यह ‘अपना समीक्षक बदलें’ पेज नहीं है। Greptile Hacker News पर 5 मार्च, 2024 को Y Combinator W24 कंपनी के रूप में लॉन्च हुआ, और वह थ्रेड कई लोगों के इस उत्पाद से पहली बार परिचित होने का तरीका था। अगर आप उन्हें इसी तरह से जानते हैं, तो उनका उपयोग जारी रखें। यह पेज उस लूप का लापता अगला हिस्सा है: एजेंट को पहले आधार देना ताकि Greptile जो PR देखे वह पहले से ही सही फ़ाइलों को लक्ष्य कर रहा हो।

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

भाषा कवरेज उसी तरह की ईमानदारी है। Greptile समर्थन को सूचीबद्ध सूची के बजाय सभी प्रोग्रामिंग भाषाओं को कवर करने के रूप में फ्रेम करता है; सटीक संख्या नहीं बताई गई है। Maguyva 279 से अधिक भाषाओं और टेक्स्ट-आधारित तकनीकों के लिए समर्थन प्रकाशित करता है, जब सवाल तकनीकी हो तो साइट पर एक तकनीकी विभाजन (पार्सर-समर्थित AST बनाम केवल-टेक्स्ट) के साथ। ये अलग-अलग दावे करने वाले अलग-अलग उत्पाद हैं। इन्हें न मिलाएँ।

Greptile की क़ीमत इस लेख की उपयोग योग्य सामग्री में नहीं बताई गई है। भुगतान योजनाएँ मौजूद हैं; उनका मूल्य निर्धारण पेज देखें। Maguyva सीट्स के बजाय प्रति वर्कस्पेस चार्ज करता है। योजनाएँ मुफ़्त से शुरू होती हैं। मूल्य निर्धारण पेज अगर आपको वर्कस्पेस संख्याएँ चाहिए तो प्रकाशित स्तर सूचीबद्ध करता है।

वर्कफ़्लो

तीन नामित चरण। इसी क्रम में चलाएँ। पहली बार जब आप इस जोड़ी को आज़माएँ तो इनमें से किसी को न छोड़ें।

1. Maguyva संदर्भ

एक ऐसी repository को इंडेक्स करें जिसे आप पहले से जानते हैं। उस MCP क्लाइंट को कनेक्ट करें जहाँ आप पहले से लिखते हैं — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, या कोई अन्य MCP-संगत क्लाइंट। Maguyva के पास 24 दस्तावेज़ीकृत MCP क्लाइंट्स के लिए सेटअप गाइड है और यह अन्य क्लाइंट्स से बात कर सकता है जो मानक MCP कॉन्फ़िगरेशन का समर्थन करते हैं।

किसी के लिखने से पहले एक ऐसा सवाल पूछें जिसे आप आंक सकें। ‘सत्र समाप्ति कहाँ संभाली जाती है, और इसे कौन कॉल करता है?’ ‘auth ठीक करो’ से बेहतर पहला कदम है। उद्धरण मांगें। file.ext:line परिणाम खोलें। सिंबल का पीछा करें। उन डिपेंडेंसी की पुष्टि करें जिन्हें आप छूने वाले हैं।

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

स्नैपशॉट टाइमस्टैम्प किए जाते हैं, ताकि एजेंट बता सके कि यह ट्री का कौन सा संस्करण पढ़ रहा है। ईमानदार सीमा असिंक्रोनाइज़्ड स्थानीय काम है। अगर कोई बदलाव केवल वर्किंग ट्री में मौजूद है और पुश नहीं हुआ, तो होस्टेड मैप में अभी भी वह बदलाव नहीं है। इंस्ट्रक्शन फ़ाइलें (CLAUDE.md, AGENTS.md) फिर भी यहाँ एक जगह रखती हैं, कन्वेंशन और जो नहीं छूना चाहिए उसके लिए। यह जीवित मैप नहीं है। व्यवहार के लिए इसका उपयोग करें। तथ्यों के लिए Maguyva का उपयोग करें।

उद्धरण repo के संपर्क में टिकने से पहले एजेंट को PR खोलने न दें। वह गेट इस चरण का पूरा उद्देश्य है।

2. एजेंट का PR

वही एजेंट अब उस क्लाइंट में बदलाव लिखता है जिसके लिए आप पहले से भुगतान करते हैं। Maguyva न तो एडिटर है, न समीक्षक। एजेंट फिर भी diff बनाता है। आप फिर भी GitHub या GitLab पर पुल रिक्वेस्ट खोलते हैं जैसा आप पहले से करते हैं।

जो अलग होना चाहिए वह है पहली फ़ाइल। PR को उस असली हैंडलर का नाम लेना चाहिए जो व्यवहार को लागू करता है, वे कॉलर जो टूटेंगे, और वे टेस्ट जो अगर बदलाव गलत है तो विफल होंगे। अगर चरण 1 छोड़ दिया गया, तो चरण 3 अपनी टिप्पणी गलत पैकेज में उतरे बदलाव पर बर्बाद करेगा। Greptile फिर भी प्रणालीगत समस्याएँ ढूँढ सकता है। इसे भ्रामक पथ से भी उबरना नहीं पड़ना चाहिए।

PR को छोटा रखें। एक आधारित पहली फ़ाइल किसी मॉड्यूल को फिर से लिखने का लाइसेंस नहीं है। यह पूरक जोड़ी तब काम करती है जब एजेंट मैप के साथ एक काम करता है, फिर समीक्षक से सीमित diff पर दूसरा काम करने को कहता है।

3. Greptile की समीक्षा

Greptile पहले से ही GitHub या GitLab ऐप के ज़रिए repository से जुड़ा हुआ है। एक नए पुल रिक्वेस्ट पर, यह उस पूर्ण repo ग्राफ़ का उपयोग करके बदलाव का विश्लेषण करता है जिसे उसने बनाया है, और सुझाए गए सुधारों के साथ निष्कर्षों को टिप्पणी के रूप में प्रकाशित करता है। उनकी अपनी सामग्री इस चरण को लगभग तीन मिनट पर रखती है।

टिप्पणी को उसी तरह पढ़ें जैसे आप एक चौकस टीममेट को पढ़ेंगे: उद्धृत स्थान खोलें, तय करें कि निष्कर्ष सही है या नहीं, फिर कार्रवाई करें। जहाँ Greptile ‘Fix with your Agent’ प्रस्तुत करता है, यह मुद्दे को — फ़ाइल पथ, लाइन नंबर, सुझाया गया कोड — Claude Code, Codex, Conductor, Cursor, या Devin को भेजता है। ‘Fix All’ उस समीक्षा में सभी मुद्दों को एक साथ भेजता है। वे उस हैंडऑफ़ के लिए Greptile MCP और एक Claude Code प्लगइन भी प्रदान करते हैं। Maguyva उस नामित लक्ष्य सूची में नहीं है; वह अनुपस्थिति समस्या नहीं है। Maguyva ने अपना काम चरण 1 में पहले ही कर लिया। जिस कोडिंग एजेंट ने PR लिखा वह वह पक्ष है जिसे फ़िक्स पेलोड मिलना चाहिए।

पहले 2-3 सप्ताह के दौरान शोरगुल की उम्मीद करें जब Greptile का सीखने वाला सिस्टम उन वास्तविक टिप्पणियों के अनुकूल होता है जो आपकी टीम छोड़ती है। यह वह समयसीमा है जो वे बताते हैं, जोड़ी की खामी नहीं। मानवीय समीक्षा उस लूप में रहती है। Greptile एक स्वचालित पहला कदम है, मर्ज बटन नहीं।

अगर Greptile की टिप्पणी किसी ऐसी फ़ाइल की ओर इशारा करती है जिसे चरण 1 में एजेंट ने कभी नहीं पूछा, तो यह एक उपयोगी संकेत है। या तो मैप ने एक कॉलर मिस किया, या एजेंट ने एक उद्धरण छोड़ दिया। टिप्पणी के अनुसार ड्राफ्ट ठीक करें। समीक्षक को अक्षम न करें।

इस पूरक को ईमानदार कैसे रखें

• Maguyva हमेशा पहले। गलत फ़ाइल के साथ PR की समीक्षा फिर भी गलत फ़ाइल की समीक्षा ही है।
• Greptile हमेशा बाद में। अच्छी तरह उद्धृत ड्राफ्ट को भी सिस्टम-स्तरीय diff रीडिंग की ज़रूरत होती है।
• Maguyva से PR टिप्पणियाँ प्रकाशित करने के लिए न कहें। यह ऐसा नहीं करता।
• Greptile को एजेंट की पहली पुनर्प्राप्ति परत बनने के लिए न कहें जबकि वह अभी भी पथ चुन रहा है। यह उनके GitHub या GitLab ऐप के लिए डिज़ाइन किया गया काम नहीं है।
• ऐसी bash पाइपलाइन का आविष्कार न करें जो दोनों को ‘सिंक’ करती है। PR ही वह इंटरफ़ेस है।
• दोनों पक्षों को अलग-अलग सत्यापित करें। उस repo को इंडेक्स करें जिसे आप पहले से जानते हैं। एक सवाल पूछें जिसे आप सत्यापित कर सकते हैं। फिर एक छोटा PR खोलें और पढ़ें कि Greptile वास्तव में क्या टिप्पणी करता है।

एक बार नाम दिए जाने के बाद यह लूप साधारण बन जाता है। पहले मैप। एजेंट का PR। बाद में समीक्षा। हर उत्पाद पुल रिक्वेस्ट के उस पक्ष पर रहता है जिसमें वह विशेषज्ञ है।

// map first. review second. in that order.