7.1 जनरेटिव AI प्रतिमान बदलाव

अवलोकन और प्रेरणा

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

इस विषय का मूल दावा यह है कि यह एक प्रतिमान बदलाव है, एक वृद्धिशील टूलिंग परिवर्तन नहीं। एक प्रतिमान बदलाव बदल देता है कि आपके मौजूदा उपकरण वास्तव में क्या मापते हैं, केवल वे कौन-से मान रिपोर्ट करते हैं यह नहीं। एक कार का इंजन बदलने के बाद भी एक स्पीडोमीटर गति मापता रहता है; इस पुस्तक के कई मेट्रिक्स इस संक्रमण को इतनी स्वच्छता से नहीं झेलते। डिप्लॉयमेंट फ़्रीक्वेंसी (विषय 2.10) इसलिए बढ़ सकती है क्योंकि AI ने वास्तव में मूल्यवान काम को तेज़ किया, या क्योंकि AI ने कई छोटे, कम-मूल्य वाले परिवर्तनों को उत्पन्न करना तुच्छ रूप से आसान बना दिया; अकेली संख्या अब दोनों में अंतर नहीं कर सकती, उस तरह से जैसे यह पहले उचित सावधानी के साथ अधिकांशतः कर सकती थी। वही तर्क कच्ची कमिट गिनतियों, कोड की पंक्तियों, और पुल रिक्वेस्ट मात्रा पर और भी अधिक बल के साथ लागू होता है, जिनके विरुद्ध विषय 3.4 ने पहले ही व्यक्तिगत मेट्रिक्स के रूप में चेतावनी दी थी, अब टीम और संगठनात्मक स्तर पर भी एक प्रासंगिक जोखिम में बढ़ाया गया।

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

प्रमुख सिद्धांत

• यह मेट्रिक्स क्या मापते हैं इसमें एक प्रतिमान बदलाव है, एक वृद्धिशील परिवर्तन नहीं। कुछ मौजूदा मेट्रिक्स चुपचाप वह अर्थ रखना बंद कर चुके हैं जो वे पहले रखते थे।
• आउटपुट मात्रा कभी मूल्य का विश्वसनीय प्रॉक्सी नहीं थी, और यह अब सक्रिय रूप से अविश्वसनीय हो गई है। विषय 3.4 की चेतावनी हमेशा सही थी; यह बदलाव इसे अनदेखा करना कहीं अधिक महंगा बनाता है।
• AI अपनाने की गति और माप अनुकूलन गति के बीच का अंतर वास्तविक जोखिम है। संगठन अपने मेट्रिक्स को फिर से देखने से तेज़ी से टूलिंग अपनाते हैं।
• इस पुस्तक में हर मेट्रिक समान रूप से प्रभावित नहीं है। परिणाम मेट्रिक्स (भाग 5) गतिविधि और कच्चे आउटपुट मेट्रिक्स की तुलना में इस बदलाव के प्रति कहीं अधिक लचीले हैं।
• यह बदलाव उद्योग-व्यापी और चल रहा है, एक बार का समायोजन नहीं। जैसे-जैसे टूलिंग और इसके अपनाने के पैटर्न विकसित होते रहते हैं निरंतर परिवर्तन की अपेक्षा करें।

सिफ़ारिशें

AI-युग वैधता के लिए अपने मौजूदा मेट्रिक सेट का स्पष्ट रूप से ऑडिट करें

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

विशेष रूप से डिप्लॉयमेंट फ़्रीक्वेंसी और लीड टाइम की फिर से जाँच करें, बढ़े हुए गार्डरेल ध्यान के साथ

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

कोड समीक्षा क्षमता को एक नए, महत्वपूर्ण बॉटलनेक के रूप में मानें

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

यह न मानें कि AI-उत्पन्न कोड मानव-लिखित कोड के समान दोष प्रोफ़ाइल रखता है

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

इस बदलाव के लिए स्पष्ट रूप से अपने मेट्रिक्स चार्टर और गवर्नेंस प्रक्रिया को अपडेट करें

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

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
बिना बदले AI-पूर्व मेट्रिक्स की रिपोर्टिंग जारी रखना	कोई व्यवधान नहीं, परिचित रिपोर्टिंग	उन मेट्रिक्स का जश्न मनाने का जोखिम जो चुपचाप मूल्य के साथ सहसंबंधित होना बंद कर चुके हैं
पूर्ण मेट्रिक-सेट ऑडिट और जान-बूझकर संशोधन	विश्वसनीय माप बहाल करता है	वास्तविक विश्लेषणात्मक प्रयास और संगठनात्मक परिवर्तन प्रबंधन की आवश्यकता
गतिविधि और आउटपुट मेट्रिक्स को पूरी तरह त्यागना	सबसे उजागर जोखिम को सीधे हटाता है	कुछ वैध रूप से उपयोगी प्रासंगिक संकेत खो देता है (विषय 3.4 की चेतावनी)
पूर्ण ऑडिट के बिना गार्डरेल कड़े करना	लागू करना तेज़	उन मेट्रिक्स को चूक सकता है जिनकी उजागरता सबसे स्पष्ट मामलों से कम स्पष्ट है

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

2. क्या AI कोडिंग सहायता अपनाने के बाद से हमारी डिप्लॉयमेंट फ़्रीक्वेंसी या कमिट मात्रा बढ़ी है, और क्या हमने जाँच की है कि क्या चेंज फ़ेल्योर रेट या दोष दर संबंधित रूप से बढ़ी? किसी सकारात्मक या नकारात्मक परिणाम को मानने की बजाय वास्तविक जोड़ा गया डेटा खींचें।

3. क्या हमारी कोड समीक्षा क्षमता AI-सहायता प्राप्त कोड मात्रा में किसी भी वृद्धि के साथ गति बनाए रख रही है, या क्या समीक्षा गहराई बढ़े हुए दबाव के तहत चुपचाप क्षरित हो रही है? रबर-स्टैंप जोखिम के तीव्र होने के संकेतों के लिए विशेष रूप से समीक्षा-चरण मेट्रिक्स (विषय 2.9) की जाँच करें।

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

5. क्या हमने इस बदलाव के प्रकाश में जान-बूझकर अपने मेट्रिक्स चार्टर (विषय 1.4) को फिर से देखा है, या क्या हमारी माप प्रथा बस अपरिवर्तित जारी रही है? यदि ईमानदार उत्तर बाद वाला है, तो वह अंतर ठीक वही है जिसे यह विषय पहले बंद करने की सिफ़ारिश करता है।

6. इस बदलाव से हमारे संगठन को असावधान पकड़ा जाना कैसा दिखेगा, एक ऐसे मेट्रिक का जश्न मनाना जिसने पहले से ही वह अर्थ रखना बंद कर दिया था जो हम सोचते थे कि इसका है? यह ठोस, थोड़ा असहज विचार प्रयोग उस परिदृश्य के वास्तव में होने से पहले, बाद में नहीं, इस विषय द्वारा सुझाए गए ऑडिट को प्रेरित करने में मदद करता है।

क्षेत्र दृष्टिकोण

स्टार्टअप। तेज़ AI उपकरण अपनाना सामान्य है और अक्सर एक वास्तविक प्रतिस्पर्धी लाभ है, लेकिन वही गति जो अपनाने को आकर्षक बनाती है वह अनजाँचे मेट्रिक बहाव को अधिक संभावित बनाती है। अकेले वेलोसिटी सुधारों की रिपोर्ट करने की बजाय, AI अपनाने से रिपोर्ट की गई किसी भी दक्षता लाभ के साथ-साथ परिणाम मेट्रिक्स (भाग 5) की जाँच करने की आदत बनाएँ।

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

एंटरप्राइज़। यहाँ इस जोखिम का पैमाना काफ़ी हद तक संयोजित होता है, क्योंकि दर्जनों या सैकड़ों टीमों में एक साथ AI अपनाना किसी भी एकल टीम द्वारा स्थानीय रूप से पैटर्न नोटिस करने से पहले संगठन-व्यापी मेट्रिक वैधता बदल सकता है। इस विषय द्वारा सुझाया गया मेट्रिक-सेट ऑडिट संगठनात्मक स्तर पर करें, केवल टीम-दर-टीम नहीं, और गवर्नेंस (विषय 1.4) को केंद्रीय और स्पष्ट रूप से अपडेट करें।

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

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

• स्तर 1, आरंभ: AI-पूर्व-युग मेट्रिक्स बिना बदले रिपोर्ट किए जाते हैं, इस जागरूकता के बिना कि AI अपनाने ने उनकी वैधता को प्रभावित किया हो सकता है।
• स्तर 2, विकास: बदलाव की कुछ जागरूकता मौजूद है, लेकिन मौजूदा मेट्रिक सेट का कोई व्यवस्थित ऑडिट नहीं किया गया है।
• स्तर 3, मानकीकरण: एक पूर्ण मेट्रिक-सेट ऑडिट किया गया है, गार्डरेल कड़े किए गए हैं और मेट्रिक्स को संगठन-व्यापी प्रभावित या लचीले के रूप में दस्तावेज़ीकृत किया गया है।
• स्तर 4, प्रबंधन: यह मानने की बजाय परीक्षण करने के लिए दोषों और गुणवत्ता परिणामों को AI-सहायता स्तर द्वारा सक्रिय रूप से टैग और ट्रैक किया जाता है कि क्या संगठन के ऐतिहासिक गुणवत्ता संबंध अभी भी टिकते हैं।
• स्तर 5, संयोजन: संगठन के पास अपने मेट्रिक्स की फिर से जाँच करने की एक परिपक्व, चल रही प्रथा है क्योंकि AI टूलिंग और अपनाने के पैटर्न विकसित होते रहते हैं, और यह इस बदलाव के जवाब में सक्रिय रूप से किए गए विशिष्ट गवर्नेंस निर्णयों की ओर इशारा कर सकता है, एक समस्या सामने आने के बाद प्रतिक्रियात्मक रूप से नहीं।

चर्चा के लिए विचार

1. हमारे वर्तमान मेट्रिक्स में से कौन-सा भारी रूप से AI सहायता का उपयोग करने वाली लेकिन अधिक वास्तविक मूल्य उत्पन्न न करने वाली एक टीम को सबसे अधिक बेहतर दिखाएगा?
2. क्या AI अपनाने के बाद से हमारी डिप्लॉयमेंट फ़्रीक्वेंसी बढ़ी है, और क्या चेंज फ़ेल्योर रेट इसके साथ चली है?
3. क्या हम गुणवत्ता परिणामों को AI-सहायता स्तर द्वारा टैग करते हैं, और वह डेटा क्या दिखाएगा?
4. क्या हमारी समीक्षा क्षमता AI-उत्पन्न कोड मात्रा में किसी भी वृद्धि के साथ गति बनाए रख रही है?
5. हम वर्तमान में किस उद्योग बेंचमार्क के विरुद्ध स्वयं की तुलना करते हैं, और क्या यह स्वयं इस दबाव के तहत बदला है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (परिणाम-आधारित माप आधार जिसे यह विषय तर्क देता है कि इस बदलाव के तहत कम नहीं, अधिक महत्वपूर्ण हो जाता है)।
• GitHub का AI पेयर प्रोग्रामिंग और डेवलपर उत्पादकता पर शोध (AI-सहायता प्राप्त विकास के मापने योग्य प्रभावों पर उद्योग शोध)।
• Google Cloud का DevOps Research and Assessment कार्यक्रम, dora.dev (हाल के वर्षों में AI-अपनाने की खोजों को शामिल करने वाला चल रहा State of DevOps शोध)।
• The Tyranny of Metrics, by Jerry Z. Muller (मात्रा-आधारित मेट्रिक्स के प्रति संशयवाद का सामान्य मामला, सीधे प्रासंगिक क्योंकि आउटपुट मात्रा सस्ती होती जाती है)।