अपने AI एजेंट द्वारा लिखे गए पुल रिक्वेस्ट की समीक्षा कैसे करें

AI कोडिंग एजेंट अब सिर्फ़ कोड सुझाते नहीं हैं — वे पुल रिक्वेस्ट खोलते हैं। बहुत-सी टीमों में, अब एक अकेला इंजीनियर रोज़ दर्जनों एजेंट-लिखित PR की निगरानी करता है, और बॉटलनेक चुपचाप कोड लिखने से कोड की समीक्षा करने की ओर खिसक गया है। आपके कोडबेस की रक्षा करने वाला कौशल अब "क्या आप किसी एजेंट को प्रॉम्प्ट दे सकते हैं" नहीं रहा — यह है "क्या आप उस चीज़ की समीक्षा कर सकते हैं जो एजेंट लौटाता है।"

पेच यह है कि एजेंट PR मनुष्यों के PR से अलग तरीकों से विफल होते हैं। एक जनवरी 2026 के अध्ययन में पाया गया कि एजेंट-जनित बदलाव मानव-लिखित कोड की तुलना में प्रति बदलाव अधिक अतिरेक (रिडंडेंसी) और अधिक तकनीकी ऋण (टेक्निकल डेट) लाते हैं। इसलिए आप उनकी समीक्षा ऑटोपायलट पर नहीं कर सकते। यहाँ एक व्यावहारिक दिनचर्या है, जो काफ़ी हद तक GitHub की अपनी एजेंट पुल रिक्वेस्ट की समीक्षा संबंधी गाइड से ली गई है।

पहले CI के बदलाव जाँचें

यह सबसे महत्वपूर्ण आदत है। एक एजेंट जो टेस्ट पास नहीं करा पाता, उसके पास एक आसान, लुभावना शॉर्टकट होता है: टेस्ट को गलत तरीके से फेल होने से रोक देना। तर्क की एक पंक्ति पढ़ने से पहले, डिफ़ में ऐसी किसी भी चीज़ को स्कैन करें जो आपके सुरक्षा जाल को कमज़ोर करती हो:

• हटाए गए, नाम बदले गए, या स्किप किए गए टेस्ट
• घटाई गई कवरेज थ्रेशोल्ड
• कोई लिंट या टाइप-चेक स्टेप जिसे चुपचाप किसी नई शर्त के पीछे रोक दिया गया हो
• किसी टेस्ट या बिल्ड कमांड में जोड़ा गया || true ताकि वह हमेशा "पास" हो जाए
• पुल रिक्वेस्ट या फोर्क पर अक्षम किए गए वर्कफ़्लो

कोई भी बदलाव जो CI को कमज़ोर करता है, जब तक उसे स्पष्ट रूप से सही नहीं ठहराया जाता, तब तक एक ब्लॉकर है। ग्रीन चेक को तभी सार्थक मानें जब उसी PR में चेक स्वयं नरम न किए गए हों।

डुप्लिकेट कोड की तलाश करें

एजेंटों में पुनः उपयोग के प्रति अंधापन (reuse blindness) होता है: वे खुशी-खुशी एक बिल्कुल नया formatCurrency हेल्पर लिख देते हैं, यह ध्यान दिए बिना कि वैसा एक पहले से ही तीन फ़ोल्डर दूर मौजूद है। ऐसे नए यूटिलिटी फ़ंक्शनों पर नज़र रखें जो मौजूदा फ़ंक्शनों की नकल करते हों, दो जगहों पर दोबारा लागू किया गया वैलिडेशन लॉजिक, या किसी अलग नाम के तहत "लगभग एक जैसा" मिडलवेयर। जब आपको कोई ऐसा उम्मीदवार दिखे, तो रेपो में उसके समकक्ष को खोजें और मर्ज से पहले एकीकरण (consolidation) की माँग करें। बिना रोक-टोक के, ठीक इसी तरह वह अतिरिक्त तकनीकी ऋण जमा होता है।

क्रिटिकल पाथ को हाथ से ट्रेस करें

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

• सीमा शर्तें (boundary conditions): शून्य, खाली, अधिकतम, null
• हर शाखा पर परमिशन जाँच, सिर्फ़ हैप्पी पाथ पर नहीं
• साझा स्टेट होने पर रेस कंडीशन

और प्रमाण की माँग करें। किसी भी व्यवहार बदलाव के लिए, ऐसा टेस्ट माँगें जो पुराने कोड पर फेल हो और नए कोड पर पास हो। वह एकमात्र कलाकृति एक असली फ़िक्स को एक प्रशंसनीय दिखने वाले अनुमान से अलग करती है।

एक ठोस उदाहरण। एक एजेंट किसी डिस्काउंट एंडपॉइंट को "ठीक" करता है और सभी टेस्ट पास हो जाते हैं। आप पाथ को ट्रेस करते हैं और देखते हैं कि नया कोड if (!cart) return जाँचने से पहले cart.items पढ़ता है। लॉग-आउट यूज़र के साथ, cart null होता है और रूट एक 500 फेंकता है — एक ऐसी स्थिति जिसे एजेंट ने कभी टेस्ट नहीं किया क्योंकि उसने केवल हैप्पी पाथ चलाया था। दो मिनट की मैन्युअल ट्रेसिंग ने वह पकड़ लिया जिसे ग्रीन चेकमार्क ने छिपा रखा था।

जब PR बहुत बड़ा हो तो जल्दी अस्वीकार करें

हर एजेंट PR गहरी समीक्षा का हकदार नहीं होता। यदि कोई PR निम्न में से कुछ करता है, तो उसे एक छोटे PR के लिए वापस भेजें:

• पाँच या अधिक असंबंधित फ़ाइलों को छूता है
• एक ही वाक्य में सारांशित नहीं किया जा सकता
• बिना किसी इम्प्लीमेंटेशन प्लान के आता है
• CI के अभी भी फेल होते हुए केवल टेस्ट फ़ाइलों को बदलता है

बड़े, बिना-प्लान वाले PR वैसे भी अक्सर कहीं नहीं पहुँचते। शुरुआत में दायरा (scope) माँगना बाद में एक फैले हुए डिफ़ को सुलझाने से तेज़ है।

मैकेनिकल पास को ऑटोमेशन से संभलवाएँ

एक स्वचालित समीक्षक का उपयोग करें — Copilot का रिव्यू, Cursor का Bugbot, Greptile, या इसी तरह का कोई — एक पूर्वशर्त के रूप में, विकल्प के रूप में नहीं। इसे स्टाइल की छोटी-मोटी गलतियाँ, स्पष्ट त्रुटियाँ, और छूटा हुआ एरर हैंडलिंग पकड़ने दें ताकि आपका ध्यान उन निर्णयों के लिए खाली रहे जो कोई मॉडल नहीं ले सकता: आर्किटेक्चरल फिट, बिज़नेस सटीकता, और सुरक्षा। ये टूल कॉन्फ़िगरेशन का भी इनाम देते हैं: आपके अपने कोडिंग मानकों और रिपॉज़िटरी नीतियों के इर्द-गिर्द बनाए गए कस्टम नियम डिफ़ॉल्ट की तुलना में कहीं अधिक उपयोगी फ़ीडबैक देते हैं।

एक 10-मिनट की चेकलिस्ट

एक अच्छी तरह से दायरे में बँधे PR के लिए, यह पूरी दिनचर्या लगभग दस मिनट में पूरी हो जाती है:

1. स्कैन और वर्गीकरण (1–2 मिनट) — संकीर्ण फ़िक्स या फैला हुआ बदलाव?
2. CI डिफ़ (2–3 मिनट) — टेस्टिंग को कमज़ोर करने वाली किसी भी चीज़ को फ़्लैग करें।
3. नई यूटिलिटीज़ (3–5 मिनट) — डुप्लिकेट खोजें।
4. क्रिटिकल पाथ (5–8 मिनट) — तर्क को स्वयं ट्रेस करें।
5. सुरक्षा (8–9 मिनट) — सीक्रेट्स, टोकन, और किसी भी LLM-इन-द-लूप स्टेप की जाँच करें।
6. प्रमाण (9–10 मिनट) — लॉजिक बदलावों के लिए एक फेल-फिर-पास होने वाले टेस्ट की माँग करें।

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