क्या आपको अभी भी अपने AI एजेंट के कोड की समीक्षा करनी चाहिए?

हर टीम में बहस एक ही तरह से शुरू होती है। एक पक्ष कहता है कि एजेंट अब आधे पुल अनुरोधों की तुलना में साफ कोड भेजते हैं, तो हम हर लाइन क्यों पढ़ रहे हैं? दूसरा पक्ष कहता है कि क्योंकि हम ही हैं जिन्होंने स्वीकृति दी है।

दोनों पक्ष सही हैं। यही कारण है कि यह बहस कभी खत्म नहीं होती। यह खत्म नहीं होती क्योंकि सवाल गलत है, और जब आप सवाल को ठीक करते हैं तो जवाब लगभग उबाऊ हो जाता है।

हर लाइन पढ़े बिना शिपिंग के लिए मामला

सबसे मजबूत सकारात्मक तर्क से शुरू करें, क्योंकि यह अधिकांश समीक्षकों की स्वीकृति से अधिक मजबूत है।

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

मानव समीक्षा भी पहले से ही टूट चुकी थी जब एजेंट आए। कोई भी जिसने एक वास्तविक टीम में काम किया है, LGTM रिफ्लेक्स को जानता है: समीक्षक की ध्यान कुछ सौ लाइनों के बाद गिर जाती है, और जो अनुमोदन होते हैं वे सामाजिक होते हैं, तकनीकी नहीं। हमने कठोर समीक्षा का एक स्वर्ण युग नहीं खोया। हमने एक अनुष्ठान खो दिया जो पहले से ही ज्यादातर नाटक था।

फिर मात्रा है। एक डेवलपर जो पांच एजेंटों को समानांतर में चला रहा है, प्रति घंटे अधिक डिफ़ उत्पन्न करता है जितना कोई मानव सावधानी से पढ़ सकता है। यदि आपका नियम "सब कुछ पढ़ें" है, तो आपने चुपचाप खुद को फिर से उस बाधा के रूप में स्थापित कर लिया है जिसे आपने अभी स्वचालित किया था। एक मानव जो 900 लाइन के डिफ़ को स्किम करता है, बिना ज्ञान उत्पन्न किए एक हस्ताक्षर उत्पन्न करता है, और यह बिल्कुल भी समीक्षा न करने से बदतर है, क्योंकि यह वहां कोई आश्वासन उत्पन्न करता है जहां कोई नहीं है।

डिफ़ पर मानव को बनाए रखने के लिए मामला

अब दूसरा पक्ष, जो उत्साही लोगों की स्वीकृति से अधिक मजबूत है।

जवाबदेही स्थानांतरित नहीं होती। मॉडल को 3 बजे पेज नहीं किया जाता। यह घटना समीक्षा में नहीं है, यह उस ग्राहक से बात नहीं करता जिसका डेटा लीक हुआ, और यह परिवर्तन के परिणाम को अगले तिमाही में नहीं ले जाता। जो भी मर्ज करता है, वह परिणाम का मालिक होता है, और समीक्षा करना यह है कि स्वामित्व कैसे लागू किया जाता है न कि केवल घोषित किया जाता है।

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

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

बहस गलत तरीके से फ्रेम की गई है

यहाँ वह पुनःफ्रेमिंग है जो बैठक को समाप्त करता है।

आप कोड की समीक्षा नहीं कर रहे हैं क्योंकि आप लेखक पर भरोसा नहीं करते। आप इसे इसलिए समीक्षा कर रहे हैं क्योंकि आप ही हस्ताक्षर करते हैं। ये पूरी तरह से अलग गतिविधियाँ हैं, और पूरी बहस इनसे भ्रमित होने से आती है।

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

तो जवाब न तो "सब कुछ समीक्षा करें" है और न ही "एजेंट पर भरोसा करें" है। यह है:

आप लाइनों की समीक्षा करना बंद कर देते हैं। आप जोखिम की समीक्षा करना शुरू करते हैं।

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

"एजेंट ने गड़बड़ की" वास्तव में कैसा दिखता है

आप जो सबसे उपयोगी चीज अपने टीम में वापस ला सकते हैं, वह एक राय नहीं है, यह वस्तुनिष्ठ संकेतों की एक सूची है। "कोड अजीब लगता है" नहीं, बल्कि संकेत जो आप एक डिफ़ पर एक मिनट से कम समय में जांच सकते हैं। ये वही हैं जिन्होंने अपनी जगह अर्जित की है।

1. परीक्षण उसी कमिट में बदले गए जैसे कोड जो वे कवर करते हैं। हरा बनाया गया था, देखा नहीं गया। यह सूची में सबसे उच्च-संकेत वाला संकेत है, और इसे पहले जांचना चाहिए।
2. एक कथन कमजोर किया गया या एक परीक्षण अक्षम किया गया। एक skip, एक only, एक कथन जो नए कोड द्वारा लौटाए गए को स्वीकार करने के लिए विस्तारित किया गया, एक try/catch जो उस त्रुटि को निगलता है जिसे परीक्षण को उजागर करना था।
3. डिफ़ कार्य से बड़ा है। किसी ने भी मांगा नहीं था कि फ़ाइलें छुई गईं। एक एजेंट में स्कोप क्रीप उत्साह नहीं है, यह एक संकेत है कि एजेंट ने कहीं न कहीं लक्ष्य को फिर से व्याख्यायित किया।
4. एक आविष्कृत सतह। एक API विधि, एक कॉन्फ़िग विकल्प या एक पथ जो मौजूद नहीं है। यह एजेंट के सिर में संकलित होता है और कहीं और नहीं।
5. पर्यावरण कोड के बजाय ठीक किया गया। एक हार्डकोडेड पूर्ण पथ, एक मशीन विशिष्ट मान, एक व्यक्तिगत टोकन, एक उपयोगकर्ता नाम। लक्षण एजेंट की मशीन पर गायब हो गया और सभी अन्य पर चला गया।
6. एक निर्भरता बिना मांगे प्रकट हुई। नई आपूर्ति श्रृंखला, नया लाइसेंस, नया रखरखाव सतह, कुछ द्वारा तय किया गया जो इसे बनाए नहीं रखेगा।
7. पुनरावृत्ति के बजाय पुन: उपयोग। यह पहले से मौजूद एक सहायक को फिर से लागू करता है जो बीस लाइनों की दूरी पर है। यह मापी गई ऋण के पीछे का तंत्र है: प्रत्येक परिवर्तन स्थानीय रूप से उचित लगता है और कोडबेस चुपचाप एक ही काम करने का एक तीसरा तरीका प्राप्त करता है।
8. सारांश डिफ़ से मेल नहीं खाता। "ठीक किया गया और परीक्षण किया गया" जब कोई परीक्षण नहीं चला। वर्णन उसी आत्मविश्वास के साथ उत्पन्न होता है चाहे काम हुआ हो या नहीं, इसलिए इसे सत्यापित करने के लिए एक दावे के रूप में मानें, कभी भी एक रिपोर्ट के रूप में नहीं।
9. निर्देशों का पालन करना बंद कर दिया। छोटे नियम चुपचाप गिराए गए हैं कि एक सत्र कैसे बिगड़ता है इससे पहले कि यह पूरी तरह से हॉलुसिनेट करना शुरू कर दे। यदि आप अपने संदर्भ फ़ाइल में कनारी का उपयोग करते हैं, तो यह ठीक वही है जो इसे पकड़ने के लिए वहाँ है।
10. संवेदनशील क्षेत्र को पार किया गया। एक .env पढ़ा गया, एक नया आउटबाउंड नेटवर्क कॉल, एक नया लॉग लाइन जो उपयोगकर्ता डेटा ले जा रहा है, एक विशेषता कमिट में बंडल किया गया माइग्रेशन।

सूची में क्या नहीं है, इस पर ध्यान दें: शैली, नामकरण, प्रारूपण, "मैंने इसे अलग तरीके से किया होता"। ये हमेशा मानव समीक्षा का सबसे कमजोर हिस्सा थे और अब ये वास्तव में एक मानव की बर्बादी हैं। इन्हें अपनी समीक्षा से हटा दें और आप ऊपर दिए गए दस आइटम के लिए आवश्यक ध्यान वापस खरीद लेते हैं।

एक परिवर्तन को कितनी समीक्षा मिलनी चाहिए?

विस्फोटक क्षेत्र, न कि डिफ़ का आकार, निर्णय लेता है। तालिका जिसे आपकी टीम आज दोपहर अपनाएगी:

डिफ़ का आकार आपको बताता है कि समीक्षा में कितना समय लगता है। विस्फोटक क्षेत्र आपको बताता है कि क्या यह वैकल्पिक है।

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

यदि आपका उत्पाद यूरोप में व्यक्तिगत डेटा को संभालता है, तो एक और पंक्ति आपके लिए कानून द्वारा लिखी गई है न कि स्वाद द्वारा: GDPR के तहत एक AI-निर्मित विशेषता को क्या सम्मान करना चाहिए एक निर्णय कॉल नहीं है, और "एक एजेंट ने इसे लिखा" कभी भी एक रक्षा नहीं रही है।

जब पांच एजेंट एक साथ चलते हैं तो क्या बदलता है

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

यह एक उपकरण समस्या है, और यही कारण है कि AgentsRoom समीक्षा को एजेंटों के पास रखता है न कि पुल अनुरोध के अंत में:

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

इनमें से कोई भी निर्णय को प्रतिस्थापित नहीं करता। यह इसे लागू न करने के लिए बहाने हटा देता है।

मशीन को लाइनों का मालिक बनाना

यदि आप लाइनों को पढ़ना बंद करना चाहते हैं, तो कुछ और उन्हें पढ़ना होगा। व्यावहारिक रूप से, चार चीजें उस बोझ को उठाती हैं:

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

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

गेट्स जो थकते नहीं हैं। प्रकार, लिंट, गुप्त स्कैनिंग, कवरेज फ्लोर, एक CI जो एक विशेषता के साथ बंडल की गई माइग्रेशन को अस्वीकार करता है। हर नियम जिसे आप एक गेट के रूप में व्यक्त कर सकते हैं, एक नियम है जिसे आपको फिर कभी नोटिस करने की आवश्यकता नहीं है।

एक लूप जो अपने आप पर बंद होता है। एक एजेंट जो निर्माण करता है, योजना के खिलाफ अपना काम चलाता है और कुछ भी सौंपने से पहले पुनरावृत्ति करता है, आपकी समीक्षा से "यह भी नहीं चला" की पूरी श्रेणी को हटा देता है। यह स्व-संशोधित एजेंट लूप है, और यह एक एजेंट के बीच का अंतर है जो एक डिफ़ उत्पन्न करता है और एक जो एक परिणाम उत्पन्न करता है। यह सवाल का जवाब नहीं देता कि क्या एक मानव को हस्ताक्षर करना चाहिए। इसका मतलब केवल यह है कि मानव कुछ ऐसा हस्ताक्षर कर रहा है जो पहले से ही काम करता है।

तो, क्या आप अभी भी समीक्षा करते हैं?

हाँ, और आज से कम।

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

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

आपकी स्टैंडअप में बहस वास्तव में इस बारे में नहीं है कि क्या एजेंट अच्छे हैं। यह इस बारे में है कि कौन हस्ताक्षर करने के लिए तैयार है। इसका उत्तर दें, और समीक्षा नीति अपने आप लिख लेगी।

अक्सर पूछे जाने वाले प्रश्न

क्या आपको अभी भी AI जनित कोड की समीक्षा करनी चाहिए?

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

क्या एक AI एजेंट दूसरे AI एजेंट के कोड की समीक्षा कर सकता है?

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

आप कैसे जानते हैं कि एक AI एजेंट ने गलती की?

शैली के लिए पढ़ने के बजाय डिफ़ में वस्तुनिष्ठ संकेतों की तलाश करें। सबसे मजबूत: परीक्षण उसी कमिट में बदले गए जैसे कोड जो वे कवर करते हैं, जिसका मतलब है कि हरा बनाया गया था और देखा नहीं गया। अन्य में स्कोप क्रीप, एक अक्षम या कमजोर किया गया कथन, एक आविष्कृत API, एक हार्डकोडेड स्थानीय पथ और एक सारांश शामिल हैं जो डिफ़ से मेल नहीं खाता।

क्या AI एजेंट मानव कोड समीक्षकों को प्रतिस्थापित करेंगे?

उन्होंने पहले से ही अधिकांश लाइन पढ़ने को प्रतिस्थापित कर दिया है। वे हस्ताक्षर को प्रतिस्थापित नहीं कर सकते। जवाबदेही एक मॉडल में स्थानांतरित नहीं होती, इसलिए एक मानव अभी भी किसी भी चीज़ पर मर्ज करने के निर्णय का मालिक होता है जो पूर्ववत करना कठिन है।

क्या आपको AI कोड की लाइन दर लाइन समीक्षा करने की आवश्यकता है?

केवल जहां विस्फोटक क्षेत्र इसे उचित ठहराता है। लाइन दर लाइन की समीक्षा कुछ एजेंटों के समानांतर चलने के बाद स्केल नहीं करती, और एक मानव जो 900 लाइन के डिफ़ को शाम 6 बजे स्किम करता है, बिना ज्ञान उत्पन्न किए एक हस्ताक्षर उत्पन्न करता है। उस ध्यान को उन परिवर्तनों पर खर्च करें जो पूर्ववत करने के लिए महंगे हैं।

क्या कभी भी मानव समीक्षा के बिना मर्ज नहीं किया जाना चाहिए?

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