कोड समीक्षा अक्सर धीमी और असंगत होती है: डिफ कतारों में पड़े रहते हैं और फ़ीडबैक इस बात पर निर्भर करता है कि कौन ऑनलाइन है।

AI कोड समीक्षा तभी मदद करती है, जब समीक्षक के पास वास्तविक कोडबेस का संदर्भ हो।

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

#कोड समीक्षा के बारे में क्या बदला

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

कोडिंग एजेंट्स के साथ काम करने वाले डेवलपर्स अब बड़े बदलाव शिप कर रहे हैं। लाखों Cursor सेशंस के डेटा से पता चलता है कि प्रति PR जोड़ी गई पंक्तियाँ (p75) साल-दर-साल लगभग 2.5x बढ़ीं। 1,000+ बदली हुई पंक्तियों वाले मेगा PR, मर्ज का बढ़ता हुआ हिस्सा हैं, और जनवरी 2026 में एजेंट्स और मॉडल्स के बेहतर होने के साथ इसमें स्पष्ट उछाल आया। Agent सत्र और गहरे हुए: हाल की दो महीने की अवधि में प्रति सत्र औसत टूल कॉल्स लगभग 30% बढ़े। AI-लिखित कोड का अधिक हिस्सा टिक रहा है। 60 मिनट बाद भी मौजूद स्वीकृत AI पंक्तियाँ 2026 की शुरुआत से लगभग 76% से बढ़कर 81% हो गईं। अलग से मैन्युअल डिफ-स्वीकृति चरण के बिना कमिट्स तक पहुँचने वाले Agent-जनरेट किए गए परिवर्तन उस अवधि में 5x से अधिक बढ़े।

मानव समीक्षा क्षमता इनमें से किसी के साथ स्केल नहीं हुई। पारंपरिक peer-review मार्गदर्शन लंबे समय से यह मानता रहा है कि सावधानीपूर्वक पठन के लिए कुछ सौ पंक्तियाँ वह दायरा हैं, जहाँ गुणवत्ता बनी रहती है।

जब परिवर्तनों की मात्रा उन वरिष्ठ इंजीनियरों की संख्या से आगे निकल जाती है जो हर डिफ पढ़ सकते हैं, तब गुणवत्ता की कसौटी बनाए रखने का तरीका AI कोड समीक्षा है।

समीक्षा के तहत आने वाले कोड का बड़ा हिस्सा AI सहायता से लिखा गया था। मानव “यह यहाँ हमारे काम करने के तरीके से मेल नहीं खाता” जैसी बातें पकड़ने में अच्छे होते हैं। लेकिन वे किसी बड़े, विश्वसनीय, ज़्यादातर सही एजेंट पैच में छिपी उस एक सूक्ष्म गड़बड़ी को पहचानने में उतने अच्छे नहीं होते, जहाँ वास्तविक रेपो संदर्भ वाला समीक्षक मदद करता है। बड़ा परिवर्तन लिखना और उसकी जाँच करना अलग कौशल हैं, और समीक्षा वही जाँच है।

#AI कोड समीक्षा शुरू करने से पहले के प्रश्न

यदि आप AI कोड समीक्षा टूल का मूल्यांकन कर रहे हैं, तो पहले इन अवधारणाओं को समझें।

#AI कोड समीक्षा क्या है?

AI कोड समीक्षा ऐसा सॉफ़्टवेयर है जो किसी परिवर्तन को पढ़ता है (आमतौर पर एक पुल रिक्वेस्ट, और कभी-कभी एक स्थानीय डिफ) और मर्ज से पहले बग्स, रिग्रेशन और जोखिमों पर टिप्पणियाँ करता है। उपयोगी संस्करण सिर्फ़ अपने सामने बदली हुई पंक्तियों से आगे बढ़कर विश्लेषण करते हैं। वे संबंधित फ़ाइलें, टेस्ट, कॉन्फ़िग और टीम नियम भी शामिल करते हैं। कमज़ोर संस्करण डिफ को बस गद्य में दोहरा देते हैं या टिप्पणियों और नामकरण को लेकर टोकाटाकी करते हैं।

#यह linting या CI से अलग कैसे है?

Linters और typecheckers उन नियमों को औपचारिक रूप देते हैं, जिन्हें लिखना आप पहले से जानते हैं। CI उन जाँचों को चलाता है, जिन्हें आपने स्वचालित किया है। AI समीक्षा बाकी बचे मामलों के लिए है: तर्क संबंधी त्रुटियाँ, रेस कंडीशंस, auth से जुड़ी गलतियाँ, कुछ फ़ोल्डर दूर कुछ टूट जाता है, दस्तावेज़ और व्यवहार के बीच मेल न होना। इसका कुछ हिस्सा CI से मिलता-जुलता है। यह उसकी जगह नहीं लेता।

#क्या AI कोड समीक्षा मानव समीक्षा की जगह ले लेती है?

नहीं। यह बदल देती है कि लोग अपना समय किन चीज़ों पर लगाते हैं। वैसे भी, मानव समीक्षा की केवल लगभग आधी टिप्पणियाँ ही उसी PR में किसी परिवर्तन तक पहुँचती हैं। स्वस्थ समीक्षा संस्कृति में बाद में ठीक करने के नोट्स और FYI संदर्भ शामिल होते हैं। आपका लक्ष्य ऐसे बग्स को दूर करना है जिनकी पहचान मशीन भरोसे के साथ कर सकती है, ताकि लोग आर्किटेक्चर, उत्पाद जोखिम, और उस संस्थागत समझ पर ध्यान दे सकें जो अभी मॉडल के पास नहीं है।

#AI समीक्षा में शोर क्यों होता है?

शोर उन टिप्पणियों से आता है जो लोग बॉट से नहीं चाहते। शैली संबंधी टोका-टाकी, बिना किसी फेल होते टेस्ट के अस्पष्ट "टेस्ट जोड़ें" नोट, और बग न पकड़ने वाले पुनर्लेखन सुझाव—ये सभी लोगों को समीक्षा अनदेखा करने के लिए प्रेरित करते हैं। मॉडल क्या पकड़ सकता है और लोग वास्तव में किन चीज़ों को उसके द्वारा फ़्लैग किया जाना चाहते हैं, इन दोनों को अलग-अलग देखें। AI कोड समीक्षा को वास्तविक बग, अनजाने में किए गए कमिट, प्रदर्शन और सुरक्षा समस्याएँ, और वे जगहें फ़्लैग करनी चाहिए जहाँ दस्तावेज़ और कोड आपस में मेल नहीं खाते। जब Graphite ने अपनी AI समीक्षाओं को इसी ओवरलैप तक सीमित किया, तो लगभग 52% टिप्पणियों के कारण कोड में परिवर्तन हुआ (लगभग वही दर जो मानव समीक्षकों की होती है), और डाउनवोट 4% से कम रहे।

#हमें क्या मापना चाहिए?

समाधान दर: मर्ज के समय, क्या फ़्लैग की गई समस्या वास्तव में अंतिम कोड में ठीक की गई थी? समाधान दर टिप्पणी की संख्या से बेहतर मेट्रिक है।

यह वही मेट्रिक है जिसका उपयोग Cursor ने Bugbot को बेहतर बनाने के लिए किया: 40 एक्सपेरिमेंट्स में समाधान दर 52% से बढ़कर 70% से अधिक हो गई, प्रति run फ़्लैग किए गए बग्स 0.4 से 0.7 हो गए, और प्रति PR सुलझाए गए बग्स लगभग 0.2 से बढ़कर लगभग 0.5 हो गए, प्रति माह समीक्षित दो मिलियन से अधिक PRs में। May 2026 तक, डिफ़ॉल्ट-प्रयास पर मर्ज के समय सुलझाए गए बग्स की समाधान दर लगभग 80% तक पहुँच गई थी। यदि आपकी समाधान दर घटती है जबकि टिप्पणियों की संख्या बढ़ती है, तो बॉट सिर्फ़ शोर पैदा कर रहा है।

Bugbot डैशबोर्ड हर रिपॉज़िटरी के लिए समय के साथ समाधान दर का चार्ट दिखाता है। इसके साथ ही यह मिली और ठीक की गई समस्याओं की संख्या भी दिखाता है, ताकि बॉट की टिप्पणियों का दायरा बढ़ाने से पहले आप देख सकें कि समीक्षाएँ वास्तविक समस्याओं को पकड़ रही हैं और वे सुलझ रही हैं या नहीं।

#समीक्षा कब चलनी चाहिए: लोकली, PR पर, या दोनों?

दोनों, लेकिन अलग-अलग भूमिकाओं के लिए। स्थानीय समीक्षा (एक एजेंट कार्य के बाद, पुश से पहले) समस्याएँ तब पकड़ लेती है, जब संदर्भ अभी भी ताज़ा होता है और थ्रेड अभी बना नहीं होता। PR समीक्षा टीम का साझा अनुबंध है: साझा नियम, साझा इतिहास, और एक साझा मर्ज गेट। सुरक्षा-केंद्रित पास इस बात पर निर्भर करते हुए किसी भी तरफ रखे जा सकते हैं कि आप कैसे शिप करते हैं।

#क्या समीक्षा टूल का उसी उत्पाद में होना ज़रूरी है जिसमें एजेंट है?

आप एक standalone reviewer खरीद सकते हैं। कई टीमें ऐसा करती हैं। इसकी कीमत संदर्भ बदलना और कोड कैसे बना, इसकी कम स्पष्ट समझ है। जब समीक्षा उसी सिस्टम में चलती है जिसने यह परिवर्तन किया है, तो उसे खुली फ़ाइलें, रेपो मैप, और वे नियम पहले से पता होते हैं जिनका आप कोड के साथ रखरखाव करते हैं। सुधार सीधे एडिटर में deep-link हो सकते हैं या फ़ाइंडिंग लोड करके एक एजेंट स्पॉन कर सकते हैं। ऐसा लूप किसी bolt-on से बनाना मुश्किल है।

#Cursor में AI कोड समीक्षा कैसे चलाएँ

Cursor का तरीका है: एडिटर में स्थानीय समीक्षा, पुल रिक्वेस्ट पर Bugbot, और फिर एक फ़िक्स लूप जो आपको उसी टूलचेन में वापस ले जाता है।

स्थानीय। एजेंट के काम के बाद, एजेंट Review चलाएँ। आप एजेंट इनपुट में /agent-review टाइप कर सकते हैं, स्थानीय परिवर्तनों की तुलना अपनी मुख्य ब्रांच से करने के लिए इसे Source Control टैब से चला सकते हैं, या हर कमिट के बाद स्वचालित समीक्षाएँ चालू कर सकते हैं। पुश करने से पहले, आप /review-bugbot और /review-security कौशलों के ज़रिए Bugbot या Security एजेंट को स्थानीय रूप से भी चला सकते हैं। यहीं आप स्पष्ट समस्याएँ दूर कर सकते हैं, जबकि सत्र का संदर्भ अभी उपलब्ध है।

PR पर। Bugbot GitHub, GitLab और Bitbucket पर पुल रिक्वेस्ट्स की समीक्षा करता है। टीम के अपरिवर्तनीय नियमों को .cursor/BUGBOT.md में लिखें, साथ ही टीम नियम और रेपो नियम भी जोड़ें। सीखे गए नियम (@cursor remember) फ़ीडबैक को भविष्य के रनों में शामिल करते हैं। टिप्पणी श्रेणियों का विस्तार करने से पहले Bugbot स्वचालन में समाधान दर देखें।

फ़िक्स लूप। निष्कर्ष PR पर दिखाई देते हैं और Cursor में वापस जाने के पाथ देते हैं (Cursor में ठीक करें और वेब में ठीक करें)। Bugbot Autofix सुधार प्रस्तावित करने के लिए एक क्लाउड एजेंट शुरू कर सकता है। सुरक्षा के लिए, Cursor के Security Agents दो काम संभालते हैं: सुरक्षा समीक्षक मर्ज से पहले PR की जाँच करता है और भेद्यता स्कैनर निष्क्रिय कोडबेस को स्कैन करता है।

शुरू करें। दस्तावेज़ सेटअप की पूरी प्रक्रिया बताते हैं: अपना रेपो कनेक्ट करना, किन रेपो और लोगों से समीक्षाएँ ट्रिगर होंगी यह चुनना, प्रयास स्तर और .cursor/BUGBOT.md। cursor.com/docs/bugbot पर देखें।

#रूटिंग और स्वीकृति को स्वचालित करें

बग्स ढूँढना ही समीक्षा का पूरा काम नहीं है। दो Cursor स्वचालन इसके यांत्रिक हिस्सों को संभालते हैं।

कम-जोखिम वाले परिवर्तनों को ऑटो-स्वीकृत करें। Approval Agents हर पुल रिक्वेस्ट का जोखिम के आधार पर स्कोर करते हैं और आपके तय मानदंड पर खरी उतरने वाली रिक्वेस्ट को स्वीकृत करते हैं। कॉपी में बदलाव या कॉन्फ़िग अपडेट बिना किसी मानव की प्रतीक्षा किए मर्ज हो सकता है। आपकी जोखिम सीमा से ऊपर की हर चीज़ रोक दी जाती है। Bugbot और Security एजेंट के निष्कर्ष भी इस निर्णय में शामिल होते हैं, ताकि जोखिमपूर्ण परिवर्तन को यूँ ही स्वीकृति न मिल जाए।

सही समीक्षकों को रूट करें। जब किसी PR के लिए किसी व्यक्ति की आवश्यकता होती है, तो Approval Agents आपके द्वारा परिभाषित क्षेत्र-वार रूटिंग नीतियों का इस्तेमाल करके कोडबेस के प्रभावित हिस्से के आधार पर समीक्षकों को असाइन करते हैं। परिवर्तन साझा कतार में जाने के बजाय उस कोड की मालिक टीम के पास जाता है।

#समीक्षा कोड के करीब रखें

AI कोड समीक्षा वह तरीका है, जिससे टीमें एक गुणवत्ता की कसौटी बनाए रख सकती हैं, जबकि एजेंट परिवर्तनों के आकार और गति को बढ़ाते हैं। जो तरीके काम करते हैं, उनमें रेपो संदर्भ, सीमित टिप्पणी नीति, और ऐसा मेट्रिक होता है जो यह ट्रैक करता है कि मिले निष्कर्ष ठीक हो रहे हैं या नहीं।

समीक्षा वहीं के करीब होनी चाहिए जहाँ कोड तैयार हुआ है, उन्हीं नियमों और उसी समाधान पाथ के साथ। किसी व्यस्त रेपो के लिए Bugbot चालू करें, Bugbot स्वचालन में एक हफ्ते तक समाधान पर नज़र रखें, और उसके बाद ही तय करें कि किन श्रेणियों को अधिक मात्रा मिलनी चाहिए।