एआई कोड जनरेशन से कोड समीक्षा की बोतलने की समस्या उत्पन्न हो रही है, क्योंकि इंजीनियर कठिनाई का सामना कर रहे हैं

लेखक: The Pragmatic Engineer

स्ट्रीम टेकफ्लो

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

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

मैंने सुना है कि इंजीनियरिंग नेताओं की सबसे बड़ी चिंता लगातार बढ़ते कोड रिव्यू लोड का सामना करना है। यह विषय कुछ समय से मौजूद है, और अब ऐसी बातचीत अधिक आम होती जा रही है।

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

फरवरी 2024 के बाद से, लोड में वृद्धि के जवाब में AI कोड समीक्षा उपकरणों में विस्फोटक वृद्धि हुई है, जिसमें CodeRabbit, Greptile, Qodo, SonarQube (अब Gitar के साथ) जैसे विशिष्ट AI कोड समीक्षा उपकरणों का प्रयोग और अपनाया जाना विस्फोटक रूप से बढ़ा है। इसके अलावा, Claude Code review, Cursor review, GitHub Copilot review जैसे कोडिंग उपकरणों द्वारा स्वयं प्रदान किए गए उपकरण भी हैं। फिर, जो उपकरण पहले कोड समीक्षा में शामिल नहीं थे लेकिन कोडबेस के लिए संदर्भ रखते थे, वे भी इस क्षेत्र में शामिल हो रहे हैं, जैसे Sentry के Seer AI reviews, Linear code reviews।

बड़ी कंपनियाँ कोड समीक्षा अनुभव को बेहतर बनाने के लिए आंतरिक उपकरण बना रही हैं। यूबर का कोड इनबॉक्स एक उदाहरण है:

स्मार्ट असाइनमेंट Code Inbox के अंतर्गत एक फीचर है जो समीक्षा प्रक्रिया को आगे बढ़ाने के लिए उपयोग किया जाता है:

चित्र: कोड इनबॉक्स का स्मार्ट असाइनमेंट सेटिंग, जो समीक्षा प्रक्रिया को आगे बढ़ाता है। स्रोत: The Pragmatic Engineer

साथ ही, परिवर्तनों के प्रभाव का मूल्यांकन करने के लिए जोखिम प्रोफाइल फ़ंक्शन है, जो विकासकर्ताओं को उच्च जोखिम वाले परिवर्तनों पर विशेष ध्यान देने के लिए प्रोत्साहित करता है:

चित्र: Code Inbox का रिस्क प्रोफाइल्स फीचर, जो कोड बदलाव के जोखिम का अनुमान लगाता है और ध्यान केंद्रित करने के लिए सुझाव देता है। स्रोत: The Pragmatic Engineer

हमने रिपोर्ट किया है कि यूबर कैसे सॉफ्टवेयर विकास के लिए AI का उपयोग करता है, और केवल यूबर ही नहीं: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) और कई अन्य कंपनियाँ ऐसे टूल बना चुकी हैं जो उनके कोड रिव्यू प्रक्रिया को अधिक चिकना बनाते हैं, क्योंकि उन्हें पाया गया कि आंतरिक विकास, विक्रेता के समाधानों के समाकलन से बेहतर परिणाम देता है।

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

अत्यधिक विस्तृत कोड रिव्यू इंजीनियर्स को थका रहे हैं और रिव्यू की गुणवत्ता में कमी ला रहे हैं। मुझे कई अफवाहें सुनाई दी हैं कि डेवलपर्स देख रहे हैं कि दूसरे लोग अब कोड की अच्छी तरह से जांच नहीं कर पा रहे हैं, और अगर AI कोड रिव्यू में कोई महत्वपूर्ण टिप्पणी नहीं है, तो वे सीधे स्वीकार कर लेते हैं। इसी बीच, जो डेवलपर्स पहले की तरह ही कोड रिव्यू पर समान ऊर्जा और समय लगा रहे हैं, वे AI द्वारा भेजे गए कचरा PR से डूबते हुए महसूस कर रहे हैं।

समस्या मौजूद है, लेकिन समाधान अधिक प्रयोगात्मक लगता है।