एआई-जनरेटेड कोड रिव्यू ट्रेनिंग: डेवलपर्स को यह सिखाना कि मॉडल ने क्या लिखा है, उसका ऑडिट कैसे करें

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

यह एक उदाहरण मात्र है, कोई दस्तावेजी घटना नहीं। यह उस कमी को दर्शाता है जिसे एआई-जनरेटेड कोड रिव्यू ट्रेनिंग को दूर करना होगा: बुनियादी जांच में पास होने वाला जनरेटेड कोड भी ऑथराइजेशन या कॉन्करेंसी संबंधी त्रुटि से ग्रसित हो सकता है, और इसकी समीक्षा करने वाले व्यक्ति को इसे ढूंढना होगा और यह बताना होगा कि यह त्रुटि क्यों महत्वपूर्ण है।

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

एआई-जनरेटेड कोड रिव्यू ट्रेनिंग क्या है?

एआई-जनरेटेड कोड रिव्यू ट्रेनिंग डेवलपर्स को एक सहायक से स्पष्ट रूप से निर्देश लेने, फिर प्राप्त परिणामों का मूल्यांकन और ऑडिट करने का प्रशिक्षण देती है: क्या यह सही है, क्या यह सुरक्षित है, क्या यह एक साथ कई लोड होने पर भी ठीक से काम करता है, क्या यह पर्याप्त रूप से कुशल है? यह किसी विशेष टूल पर आधारित कोर्स नहीं है। यह एक ऐसी समीक्षा की आदत विकसित करता है जो टूल बदलने पर भी अपरिवर्तित रहती है।

त्वरित तथ्य

1. प्रदर्शन संबंधी समस्या का वर्णन करें।

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

शोध से पता चलता है कि इसके लिए जानबूझकर अभ्यास की आवश्यकता क्यों है। GitHub Copilot के एक अध्ययन में, पियर्स और उनके सहयोगियों ने ज्ञात कमजोरियों के प्रकारों के लिए चुने गए 89 परिदृश्यों में 1,689 प्रोग्राम उत्पन्न किए और पाया कि उनमें से लगभग 40 प्रतिशत असुरक्षित थे।पियर्स और सहकर्मी, 2021यह एक प्रारंभिक उपकरण और विशिष्ट परिदृश्यों का समूह था, इसलिए इस आंकड़े को आज के सहायकों के लिए एक मानक दर के रूप में न लें। एक अलग उपयोगकर्ता अध्ययन में प्रतिभागियों को एआई सहायक के साथ और उसके बिना कोड लिखने के लिए कहा गया। सहायक के साथ कोड लिखने वालों ने काफी कम सुरक्षित कोड लिखा, और उनके द्वारा लिखे गए कोड को सुरक्षित मानने की संभावना अधिक थी।पेरी और सहकर्मी, 2023इसी अध्ययन में पाया गया कि जिन प्रतिभागियों ने सहायक पर कम भरोसा किया और उसके निर्देशों के साथ अधिक जुड़ाव दिखाया, उनमें कम कमजोरियां पाई गईं।

प्रशिक्षण डिजाइन के लिए दो सबक मिलते हैं। विश्वसनीय परिणाम के लिए एक सक्रिय समीक्षक की आवश्यकता होती है। और आत्मविश्वास प्रमाण नहीं है, इसलिए अभ्यास में राय नहीं, बल्कि परीक्षण के लिए कहा जाना चाहिए।

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

2. सीखने और संदर्भ संबंधी कमियों का निदान करें

कुछ भी बनाने से पहले, उस कार्य की तुलना अपने वर्तमान कार्यक्रम में अपनाई जाने वाली प्रथाओं और मूल्यांकनों से करें। आमतौर पर तीन प्रश्न प्रशिक्षण की कमी को अन्य कमियों से अलग करते हैं:

1. क्या वर्तमान कार्यप्रणाली में वास्तविक कार्य का उपयोग किया जाता है? यदि प्रशिक्षण में प्रॉम्प्ट राइटिंग को शामिल किया जाता है लेकिन डेवलपर्स से आउटपुट की समीक्षा करने के लिए नहीं कहा जाता है, तो किसी ने भी ऑडिटिंग का अभ्यास नहीं किया है। यदि मूल्यांकन सुरक्षित कोडिंग नियमों पर आधारित बहुविकल्पीय परीक्षा है, तो यह स्मरण शक्ति का मापन करती है।
2. संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, कोड की सुरक्षा का आकलन करना और उसे साबित करने वाले परीक्षण का चयन करना विश्लेषण और मूल्यांकन स्तरों पर आता है, जबकि बेहतर समाधान या संशोधन तैयार करना सृजन स्तर पर आता है। इन स्तरों के अनुरूप गतिविधियों का विवरण हमारी मार्गदर्शिका में दिया गया है। ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना.
3. क्या कौशल के अलावा कोई और चीज बाधा बन रही है? समीक्षा का समय, उपकरण और स्वामित्व की जाँच करें। यदि समीक्षकों को प्रत्येक पुल अनुरोध के लिए पाँच मिनट का समय दिया जाता है, तो प्रशिक्षण के बिना ऑडिट पूरा नहीं होगा। यदि प्रक्रिया में कोई स्थिर विश्लेषण या परीक्षण प्रणाली नहीं है, तो डेवलपर जोखिम का पता तो लगा सकता है, लेकिन उसे साबित नहीं कर सकता। प्रशिक्षण से छूट प्राप्त न होने वाले कारणों की जानकारी उन लोगों को दें जो उन्हें ठीक कर सकते हैं।

3. डिजाइन की तैयारी और अभ्यास

एक बार जब आपको पता चल जाए कि प्रशिक्षण से किन कमियों को दूर किया जा सकता है, तो प्रत्येक चरण को एक अलग कार्य सौंप दें।

तैयार करना। एक संक्षिप्त निदान के साथ पूर्वापेक्षाओं की जाँच करें: आपके स्टैक में मौजूद सामान्य कमजोरियाँ, आपके परीक्षणों की संरचना, और आपकी टीम द्वारा उपयोग की जाने वाली समीक्षा चेकलिस्ट। इस चरण में स्व-गति से अध्ययन करना उपयुक्त है। एक पुनरावलोकन जाँच केवल पूर्वापेक्षाओं की पुष्टि करती है।

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

प्रतिक्रिया। इसे कुल स्कोर के बजाय निर्णयों से जोड़ें। "आपने साझा काउंटर पर लूप को चिह्नित किया लेकिन रेस को नहीं, और आपका परीक्षण इसे पकड़ नहीं पाता क्योंकि यह अनुरोधों को एक-एक करके चलाता है" यह वाक्य "3 में से 2 पाए गए" से अधिक उपयोगी है।

लाइव इनपुट या अतुल्यकालिक समीक्षा? जब जोखिम अस्पष्ट हो और डेवलपर्स किसी वरिष्ठ इंजीनियर से यह सुनकर सीख सकें कि वे मर्ज को क्यों रोक रहे हैं, तो लाइव इनपुट सबसे अधिक उपयोगी होता है। डेवलपर के निष्कर्षों की तुलना किसी विशेषज्ञ की समीक्षा से करने के लिए अतुल्यकालिक समीक्षा पर्याप्त है। कई टीमें दोनों तरीकों का उपयोग करती हैं: पहले स्वयं-आधारित तैयारी, फिर कठिन मामलों पर एक निर्देशित सत्र।

4. एक वास्तविक उदाहरण के माध्यम से काम करें

उदाहरण के तौर पर। इंजीनियरिंग मैनेजर को उपयोग करने से पहले मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।

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

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

पहला प्रयास। "सब ठीक लग रहा है। क्वेरी पैरामीटराइज़्ड है और टेस्ट पास हो गया है।" डेवलपर ने पास हुए टेस्ट को ही सबूत मान लिया है और यह नहीं पूछा कि टेस्ट में क्या शामिल नहीं है।

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

एक और मजबूत प्रयास। "सेशन चेक से यह साबित होता है कि कौन कॉल कर रहा है, न कि यह कि इनवॉइस उन्हीं का है। मैं एक ऐसा टेस्ट लिखूंगा जिसमें ग्राहक A, ग्राहक B से इनवॉइस ID मांगेगा और अस्वीकृति की उम्मीद करूंगा। काउंटर बिना सिंक्रोनाइज़ेशन के बढ़ता है, इसलिए एक साथ दो अनुरोधों से अपडेट छूट सकता है। मैं एक साथ कई टेस्ट चलाऊंगा और गिनती की तुलना करूंगा। क्वेरी स्वयं पैरामीटराइज़्ड है, इसलिए मैं इस पर समय नहीं लगाऊंगा।" ध्यान दें कि यह उत्तर जोखिमों को क्रमबद्ध करता है और प्रत्येक को एक टेस्ट से जोड़ता है।

प्रत्येक प्रतिक्रिया तर्कसंगत है या अपूर्ण है? प्रत्येक मूल्यांकन को स्वीकृत मानदंडों के आधार पर करें, न कि समीक्षक की पसंद के आधार पर। पहला प्रयास एक आदत के अनुरूप होता है लेकिन उसमें साक्ष्य की कमी होती है। बेहतर प्रयास विशिष्ट, प्राथमिकता-आधारित और परीक्षण योग्य होता है।

5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं

क्षमता का प्रमाण किसी ऐसे नए अभ्यास पर प्रदर्शन है जिसे शिक्षार्थी ने पहले कभी नहीं देखा हो। स्कोर सत्यापन की गुणवत्ता और प्रासंगिक कमियों की पहचान पर आधारित है। एक सरल मूल्यांकन मानदंड में प्रत्येक मापदंड के लिए 0 से 2 तक का पैमाना उपयोग किया जाता है:

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

स्थानांतरण की योजना सोच-समझकर बनाएं। अभ्यास के बाद, प्रत्येक डेवलपर को जनरेट किए गए कोड सहित एक वास्तविक पुल रिक्वेस्ट दें और उनके निष्कर्षों की एक साथ समीक्षा करें, या हाल ही में की गई किसी समीक्षा पर संक्षिप्त चर्चा करें जिसमें कुछ छूट गया हो।

जहां इंटरैक्टिव डिलीवरी मददगार होती है

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

जो परिवर्तन हुआ उसे मापें

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

वे बाधाएं जो बनी रह सकती हैं

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

इन समस्याओं के बारे में प्रायोजकों को पहले ही बता दें और अलग-अलग समाधानों की योजना बनाएं। प्रशिक्षण से डेवलपर की खोज और पुष्टि करने की क्षमता में सुधार होता है। इससे समय या उपकरण उपलब्ध नहीं होते।

ज़्यादातर पूछे जाने वाले सवाल

एआई-जनरेटेड कोड रिव्यू ट्रेनिंग क्या है?

यह डेवलपर्स को एआई सहायक द्वारा उत्पादित कोड को प्रॉम्प्ट करने, उसका मूल्यांकन करने और ऑडिट करने, सुरक्षा, समवर्तीता और दक्षता संबंधी समस्याओं का पता लगाने और प्रत्येक समस्या का परीक्षण करने का प्रशिक्षण देता है।

क्या जनरेट किया गया कोड मानव द्वारा लिखे गए कोड से कम सुरक्षित होता है?

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

आप यह आकलन कैसे करते हैं कि डेवलपर जेनरेट किए गए कोड का ऑडिट कर सकते हैं या नहीं?

एक नया कोड अभ्यास दें और सहमत मानदंडों के आधार पर सत्यापन गुणवत्ता और दोष पहचान का मूल्यांकन करें। सुरक्षित कोडिंग नियमों पर आधारित एक प्रश्नोत्तरी केवल पूर्वापेक्षाओं की पुष्टि करती है।

क्या आपको प्रशिक्षण के लिए कोड सैंडबॉक्स की आवश्यकता है?

आपको अभ्यास करने के लिए एक जगह की आवश्यकता होगी, जो आमतौर पर आपका अपना वातावरण होता है। किसी भी उपकरण का उपयोग करने से पहले यह सुनिश्चित कर लें कि वह आपकी आवश्यकताओं को पूरा करता है।

कहा से शुरुवात करे

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

यह देखने के लिए कि ऑडिट अभ्यास को आपकी अपनी टीम के साथ लाइव कैसे चलाया जा सकता है, और बाद में स्व-गति से इसका पुन: उपयोग कैसे किया जा सकता है, एक्सप्लोर करें AhaSlides.