AI-जनरेटेड कोड की समीक्षा करने के लिए डेवलपर की गाइड
AI हर पुल रिक्वेस्ट का बढ़ता हिस्सा लिखता है। यहाँ जानें कि AI-जनरेटेड कोड की प्रभावी रूप से समीक्षा कैसे करें — क्या देखें, क्या भरोसा करें, और कब फिर से लिखें।
कोड रिव्यू हमेशा प्रोडक्शन तक पहुँचने से पहले गलतियों को पकड़ने के बारे में रहा है। लेकिन जब कोड किसी मानव सहकर्मी के बजाय AI असिस्टेंट द्वारा लिखा गया हो, तो समीक्षा की गतिशीलता मौलिक रूप से बदल जाती है। AI जो गलतियाँ करता है वे मानव द्वारा की गई गलतियों से अलग होती हैं, और जिन चीज़ों की आपको जाँच करने की आवश्यकता होती है वे वही नहीं हैं जो आप एक सहकर्मी समीक्षा में जाँचेंगे।
यह गाइड उन चीज़ों को शामिल करती है जो अनुभवी टीमों ने AI-जनरेटेड कोड की समीक्षा करने के बारे में सीखी हैं। यह उन मुद्दों की श्रेणियों द्वारा व्यवस्थित है जो AI मॉडल लगातार उत्पन्न करते हैं, ताकि आप मानव-लिखित कोड के लिए विकसित अंतर्ज्ञान पर भरोसा करने के बजाय एक व्यवस्थित चेकलिस्ट के माध्यम से चल सकें।
AI-जनरेटेड कोड को अलग समीक्षा मानदंडों की आवश्यकता क्यों है
मानव डेवलपर थकान, व्याकुलता और ज्ञान अंतराल के आसपास गलतियाँ करते हैं — एक थका हुआ डेवलपर एक एज केस चूक जाता है, एक विचलित व्यक्ति एक त्रुटि को संभालना भूल जाता है, एक जूनियर एक एंटी-पैटर्न का उपयोग करता है क्योंकि वे बेहतर नहीं जानते। AI मॉडल पूरी तरह से अलग अक्षों के आसपास गलतियाँ करते हैं: मतिभ्रम, संदर्भ अंधता, और शैलीगत असंगति।
एक मानव जो एक फ़ंक्शन लिखता है जो नल इनपुट को नहीं संभालता, शायद बेहतर जानता है और बस भूल गया। एक AI जो वही फ़ंक्शन लिखता है, वास्तव में नहीं जानता कि आपके कोडबेस में नल संभव है या नहीं जब तक आप उसे स्पष्ट रूप से नहीं बताते। यह अंतर मायने रखता है क्योंकि समाधान अलग है: मानव को एक अनुस्मारक की आवश्यकता है, लेकिन AI को समीक्षा में पकड़ी गई या प्रॉम्प्ट में एन्कोड की गई एक बाधा की आवश्यकता है।
इस अंतर को समझना प्रभावी AI कोड समीक्षा की नींव है। आप यह जाँच नहीं रहे हैं कि डेवलपर सावधान था या नहीं। आप यह जाँच रहे हैं कि क्या AI के पास सही कोड उत्पन्न करने के लिए पर्याप्त संदर्भ था, और क्या उसका आउटपुट आपके कोडबेस की अंतर्निहित परंपराओं से मेल खाता है जो वह नहीं देख सका।
चेकलिस्ट आइटम 1: मिथ्या API और इम्पोर्ट
AI-जनरेटेड कोड में सबसे आम समस्या उन लाइब्रेरी, फ़ंक्शन या API का उपयोग है जो मौजूद नहीं हैं। AI मॉडल को प्रशिक्षित किया जाता है कि वे प्रशंसनीय कोड उत्पन्न करें, और वे आत्मविश्वास से उन पैकेजों के लिए इम्पोर्ट उत्पन्न करेंगे जो कभी प्रकाशित नहीं हुए और उन विधियों को कॉल करेंगे जो कभी अस्तित्व में नहीं थे। यह दुर्भावनापूर्ण नहीं है — यह मॉडल द्वारा प्रशिक्षण के दौरान देखे गए वास्तविक पैकेजों के बीच प्रक्षेप करना और एक सेतु का आविष्कार करना है जो उचित दिखता है।
// AI-generated code that looks plausible but imports a non-existent function
import { renderAsync } from 'react-dom'; // renderAsync does not exist
import { optimize } from 'lodash/fp/string'; // This path does not exist in lodash
// What you actually need
import { renderToString } from 'react-dom/server';इसका समाधान सरल लेकिन महत्वपूर्ण है: प्रत्येक इम्पोर्ट और प्रत्येक API कॉल को वास्तविक दस्तावेज़ीकरण के विरुद्ध सत्यापित करें। यह न मानें कि क्योंकि कोड कम्पाइल होता है, API सही हैं — कुछ मिथ्या फ़ंक्शन के उचित दिखने वाले सिग्नेचर होते हैं जो TypeScript जाँच पास करते हैं लेकिन रनटाइम पर विफल होते हैं। समीक्षा में किसी भी इम्पोर्ट पर एक त्वरित सत्यापन जाँच शामिल होनी चाहिए जिसे आप नहीं पहचानते।
चेकलिस्ट आइटम 2: गायब एरर हैंडलिंग
AI मॉडल हैप्पी पाथ उत्पन्न करते हैं। वे एक फ़ंक्शन का मुख्य तर्क लिखने में उल्लेखनीय रूप से अच्छे हैं — लूप, ट्रांसफ़ॉर्मेशन, रिटर्न वैल्यू — और जब चीजें गलत होती हैं तो क्या होता है, इसे संभालने में उल्लेखनीय रूप से बुरे। नेटवर्क अनुरोधों में कैच ब्लॉक नहीं होते। फ़ाइल संचालन में त्रुटि प्रबंधन नहीं होता। Async फ़ंक्शन में रिजेक्शन हैंडलर नहीं होते।
ऐसा इसलिए नहीं है क्योंकि AI एरर हैंडलिंग नहीं लिख सकता। यदि आप स्पष्ट रूप से पूछते हैं, तो AI पूरी तरह से try-catch लॉजिक उत्पन्न करेगा। समस्या यह है कि मॉडल का डिफ़ॉल्ट व्यवहार सबसे सरल काम करने वाला संस्करण लिखना है, और एरर हैंडलिंग उस डिफ़ॉल्ट का हिस्सा नहीं है। प्रत्येक AI-जनरेटेड कोड समीक्षा में एक पास शामिल होना चाहिए जो केवल त्रुटि पथों को देखता है।
- प्रत्येक async फ़ंक्शन में कैच या रिजेक्शन हैंडलर होना चाहिए।
- प्रत्येक बाहरी API कॉल को नेटवर्क त्रुटियों, टाइमआउट और अप्रत्याशित प्रतिक्रिया प्रारूपों को संभालना चाहिए।
- प्रत्येक डेटा ट्रांसफ़ॉर्मेशन को null, undefined और अप्रत्याशित प्रकारों को संभालना चाहिए।
- प्रत्येक फ़ाइल या डेटाबेस संचालन को अनुमति त्रुटियों और लापता संसाधनों को संभालना चाहिए।
एक उपयोगी तकनीक है एक सरल परीक्षण चलाना: AI-जनरेटेड कोड से try-catch ब्लॉक हटाएँ और देखें कि क्या शेष तर्क अभी भी समझ में आता है। यदि ऐसा है, तो AI ने शायद एरर हैंडलिंग के बारे में गहराई से नहीं सोचा। यदि तर्क कार्य करने के लिए एरर हैंडलिंग पर निर्भर है, तो AI ने इसे ठीक से एकीकृत किया।
चेकलिस्ट आइटम 3: शैली और परंपरा बेमेल
प्रत्येक कोडबेस में अलिखित शैली परंपराएँ होती हैं। टीम अर्ली रिटर्न का उपयोग करती है, नेस्टेड if का नहीं। त्रुटि संदेश एक विशिष्ट प्रारूप का पालन करते हैं। वेरिएबल नाम एक विशेष पैटर्न का उपयोग करते हैं। लाखों सार्वजनिक रिपॉजिटरी पर प्रशिक्षित AI मॉडल उस कोड को उत्पन्न करेंगे जो उन सभी रिपॉजिटरी के सांख्यिकीय औसत को दर्शाता है, न कि आपके कोडबेस की विशिष्ट परंपराओं को।
परिणाम ऐसा कोड है जो काम करता है लेकिन विदेशी लगता है। यह आसपास के कोड से भिन्न नामकरण परंपरा, भिन्न मॉड्यूल संरचना, या भिन्न त्रुटि-प्रबंधन पैटर्न का उपयोग करता है। इस तरह की असंगति जल्दी बढ़ती है — पाँच अलग-अलग अंतर्निहित शैलियों के साथ लिखे गए पाँच AI-जनरेटेड फ़ंक्शन एक ऐसा कोडबेस बनाते हैं जो असंगत लगता है और बनाए रखना कठिन होता है।
सबसे अच्छा शमन आपके प्रॉम्प्ट में शैली उदाहरण शामिल करना है। उसी मॉड्यूल से एक प्रतिनिधि फ़ंक्शन पेस्ट करें और कहें इस शैली का उपयोग करें। यह AI को एक ठोस संदर्भ देता है जो उसके प्रशिक्षण डिफ़ॉल्ट को ओवरराइड करता है। समीक्षा के दौरान, जाँचें कि उत्पन्न कोड उसी व्यक्ति द्वारा लिखा जा सकता था जिसने आसपास के मॉड्यूल को लिखा था।
चेकलिस्ट आइटम 4: ओवर-इंजीनियरिंग और अनावश्यक अमूर्तता
AI मॉडल में अमूर्तता की ओर एक मजबूत पूर्वाग्रह है। एक सरल समस्या दिए जाने पर, वे अक्सर एक क्लास पदानुक्रम, एक इंटरफ़ेस, एक फ़ैक्टरी और तीन उपयोगिता फ़ंक्शन उत्पन्न करेंगे — जहाँ एक एकल फ़ंक्शन पर्याप्त होता। यह प्रवृत्ति प्रशिक्षण डेटा से आती है, जो अच्छी तरह से कारकित ओपन-सोर्स लाइब्रेरी को अधिक प्रस्तुत करता है और सरल स्क्रिप्ट और एक-बार के फ़ंक्शन को कम प्रस्तुत करता है।
AI मॉडल ओवर-इंजीनियरिंग की ओर डिफ़ॉल्ट होते हैं। आपकी समीक्षा को सादगी की ओर डिफ़ॉल्ट होना चाहिए। AI द्वारा पेश किए गए प्रत्येक अमूर्तन को एक सरल विकल्प के मुकाबले अपने अस्तित्व को उचित ठहराने की आवश्यकता है।
समीक्षा के दौरान, अपने आप से पूछें: क्या इस कोड को एक क्लास की आवश्यकता है, या एक फ़ंक्शन काम करेगा? क्या यह इंटरफ़ेस एक से अधिक कार्यान्वयन द्वारा उपयोग किया जाता है? क्या इस उपयोगिता को निकालने से इंडायरेक्शन को उचित ठहराने के लिए पर्याप्त पुनरावृत्ति बचती है? यदि इनमें से किसी का उत्तर नहीं है, तो AI ने शायद ओवर-इंजीनियर किया है, और सरल संस्करण बेहतर है।
चेकलिस्ट आइटम 5: सुरक्षा कमजोरियाँ
AI मॉडल ऐसे कोड पर प्रशिक्षित होते हैं जिसमें सुरक्षा कमजोरियाँ होती हैं। वे उस कोड से पैटर्न सीखते हैं, जिनमें कमजोर पैटर्न भी शामिल हैं। जबकि आधुनिक मॉडल SQL इंजेक्शन जैसी स्पष्ट समस्याओं से बचने में बेहतर हैं, वे अभी भी सूक्ष्म सुरक्षा समस्याओं वाला कोड उत्पन्न करते हैं जिन्हें समीक्षक को पकड़ने की आवश्यकता है।
- जनरेटेड कोड में हार्डकोडेड सीक्रेट, API कुंजियाँ या क्रेडेंशियल देखें।
- सत्यापित करें कि उपयोगकर्ता इनपुट उपयोग से पहले मान्य और शुद्ध किया गया है।
- जाँचें कि सुरक्षित संचालन पर प्रमाणीकरण और प्राधिकरण जाँच मौजूद हैं।
- सुनिश्चित करें कि उत्पन्न SQL क्वेरी पैरामीटरीकृत स्टेटमेंट का उपयोग करती हैं, स्ट्रिंग कॉन्केटनेशन का नहीं।
- सत्यापित करें कि फ़ाइल पथ अविश्वसनीय इनपुट से शुद्धिकरण के बिना निर्मित नहीं किए गए हैं।
AI-जनरेटेड कोड के लिए एक सुरक्षा-केंद्रित समीक्षा पास अनिवार्य है जो संवेदनशील डेटा या उपयोगकर्ता इनपुट को संभालता है। AI यह नहीं जानता कि आपके सिस्टम के कौन से हिस्से सुरक्षा-महत्वपूर्ण हैं जब तक आप उसे नहीं बताते। जब संदेह हो, तो मर्ज करने से पहले जनरेटेड कोड पर एक स्थैतिक विश्लेषण उपकरण चलाएँ।
चेकलिस्ट आइटम 6: मौजूदा आर्किटेक्चर के साथ संगति
AI मॉडल प्रत्येक अनुरोध को अलगाव में देखते हैं। वे नहीं जानते कि आपकी टीम ने पिछली तिमाही में सभी डेटा फ़ेचिंग के लिए React Query का उपयोग करने पर सहमति व्यक्त की थी, कि API हमेशा कैमलकेस कुंजियाँ लौटाता है, या कि प्रोजेक्ट एक विशिष्ट स्टेट मैनेजमेंट पैटर्न का उपयोग करता है। वे जो कोड उत्पन्न करते हैं वह आंतरिक रूप से सुसंगत होगा लेकिन वास्तु निर्णयों का उल्लंघन कर सकता है जो वर्तमान फ़ाइल में दिखाई नहीं देते।
यह वह जगह है जहाँ मानव समीक्षक सबसे अधिक मूल्य जोड़ता है। आप उन निर्णयों को जानते हैं जो आपके ADR में दस्तावेज़ीकृत हैं, वे पैटर्न जो टीम चर्चाओं से उभरे हैं, और वे डिज़ाइन बाधाएँ जो किसी एक फ़ाइल में कैप्चर नहीं की गई हैं। AI-जनरेटेड कोड की समीक्षा इन अदृश्य बाधाओं के विरुद्ध करें, न कि केवल शुद्धता और शैली के विरुद्ध।
एक स्थायी समीक्षा प्रक्रिया बनाना
जैसे-जैसे AI आपके कोडबेस का अधिक उत्पन्न करता है, समीक्षा प्रक्रिया को स्केल करने की आवश्यकता है। चार लोगों की टीम हर AI-जनरेटेड लाइन की मैन्युअल समीक्षा करके थक जाएगी। स्थायी दृष्टिकोण स्वचालित जाँच को केंद्रित मानव समीक्षा के साथ जोड़ता है।
स्वचालित जाँच को मिथ्या इम्पोर्ट, शैली उल्लंघन, गायब एरर हैंडलिंग और सामान्य सुरक्षा मुद्दों को पकड़ना चाहिए, इससे पहले कि कोई मानव कोड देखे। यह AI-विशिष्ट समीक्षा को चिंताओं के एक छोटे सेट तक कम कर देता है: वास्तु संगति, डिज़ाइन निर्णय, और वे सूक्ष्म समस्याएं जिन्हें लिंटर नहीं पहचान सकते।
लक्ष्य AI-जनरेटेड कोड की मानव समीक्षा को समाप्त करना नहीं है। यह उस समीक्षा को यथासंभव कुशल बनाना है, उन मुद्दों को छानकर जिन्हें उपकरण स्वचालित रूप से पकड़ सकते हैं और मानव ध्यान उन निर्णयों के लिए आरक्षित करना जो केवल मनुष्य ही कर सकते हैं। सही प्रक्रिया के साथ, AI-जनरेटेड कोड की समीक्षा मानव-लिखित कोड की समीक्षा से तेज़ और अधिक विश्वसनीय हो जाती है — क्योंकि AI की गलतियाँ अधिक पूर्वानुमानित होती हैं।
