कोपायलट ने लिखा, लेकिन इसका मालिक कौन है? गवर्नेंस गैप जिसे इंजीनियरिंग टीमें नजरअंदाज कर सकती हैं

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

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

AI और कोडिंग अब अनिवार्य हो रही है

AI कोडिंग टूल तेजी से लोकप्रिय हो रहे हैं और मुख्यधारा के विकास में प्रवेश कर रहे हैं। according to the 2025 स्टैक ओवरफ़्लो डेवलपर सर्वेक्षण, 84% उत्तरदाताओं ने कहा कि वे अपने विकास प्रक्रिया में AI टूल का उपयोग कर रहे हैं या करने की योजना बना रहे हैं।

हालांकि वेब डेवलपर्स के कार्यप्रवाह में AI को लागू करना अधिक सामान्य हो रहा है, फिर भी इसकी विश्वसनीयता को लेकर हिचकिचाहट बनी हुई है। उसी सर्वेक्षण में पाया गया कि 46% को AI आउटपुट की सटीकता पर पूर्ण भरोसा नहीं था, और लगभग 66% ने AI समाधान को “लगभग सही, लेकिन पूरी तरह नहीं” कहकर निराशा व्यक्त की।

AI कोडिंग पर चल रही बहस अधिकतर इसकी विश्वसनीयता के बारे में है, न कि इस बात पर कि वह कोड अधिक मूल्य बनाता है या इसे सुनिश्चित करने के लिए कौन जिम्मेदार है।

AI घंटे और आउटपुट के बीच संबंध को तोड़ रहा है

सॉफ़्टवेयर विकास के लिए पारिश्रमिक हमेशा इस मान्यतानुसार रहा है कि इंजीनियरिंग आउटपुट सीधे इंजीनियरिंग प्रयास से जुड़ा है। हालांकि, जेनरेटिव AI अब इस समीकरण को जटिल बना रहा है।

95 डेवलपर्स पर किए गए एक नियंत्रित प्रयोग में पाया गया कि GitHub Copilot तक पहुँच वाले प्रतिभागियों ने एक विशिष्ट जावास्क्रिप्ट HTTP सर्वर कार्य को 55.8% तेज़ी से पूरा किया।

यह दर्शाता है कि AI विकास को तेज़ कर सकता है, संभवतः गुणवत्ता से समझौता किए बिना। लेकिन ये आंकड़े केवल इसलिए सफल हुए क्योंकि प्रयोग में बहुत विशिष्ट प्रोग्रामिंग कार्य किया गया था। जबकि कार्य तेज़ी से पूरा हुआ, इसका यह अर्थ नहीं कि Copilot पूरे इंजीनियरिंग संगठन को 55.8% अधिक उत्पादक बनाता है।

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

AI के कोडिंग समय को धीमा करने के प्रमाण भी मौजूद हैं। एक METR द्वारा किया गया यादृच्छिक अध्ययन में 16 अनुभवी ओपन‑सोर्स डेवलपर्स को 246 वास्तविक मुद्दों पर काम करने के लिए कहा गया, जिन्हें वे अपने रेपोजिटरी में अच्छी तरह जानते थे। 2025 की शुरुआत में उपलब्ध टूल्स, जैसे Claude Sonnet 3.5, 3.7 और Cursor Pro, का उपयोग करते हुए, उन्होंने अपने कार्यों को पूरा करने में लगभग 19% अधिक समय लिया, जबकि कई ने माना था कि ये टूल समय बचाएंगे।

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

वह मूल्य निर्धारण समस्या जिसके बारे में कोई नहीं बात करता

Time & Material (T&M) वेब विकास में सॉफ़्टवेयर खरीदने के लिए एक सामान्य मॉडल है, क्योंकि यह एक बार-बार आने वाली उद्योग समस्या को हल करता है: विकसित होते प्रोजेक्ट।

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

हालांकि, AI इस सिद्ध मॉडल में बाधाएँ उत्पन्न कर रहा है। जब पारिश्रमिक सीधे इंजीनियरिंग घंटों से जुड़ा हो, तो अधिक कुशल विकास समय का मतलब क्लाइंट के लिए कम बिल योग्य घंटे हो सकता है। यदि AI समान परिणाम कम समय में देता है, तो तकनीक क्लाइंट के लिए मूल्य बनाती है, लेकिन बिल योग्य घंटों में कमी प्रदाता के राजस्व को घटा देती है।

समाधान यह नहीं है कि डेवलपर्स को धीरे‑धीरे काम करने के लिए प्रोत्साहित किया जाए। T&M मॉडल अब मूल्य निर्धारण और प्रोत्साहनों के डिजाइन में एक संरचनात्मक समस्या का सामना कर रहा है। घंटा‑दर के आधार पर मूल्य निर्धारित करना सीमित हो सकता है। एक खरीदार को प्रत्येक इंजीनियरिंग घंटे की लागत पता हो सकती है, फिर भी वह कुल निवेश के बारे में अनिश्चित रह सकता है जो वांछित परिणाम प्राप्त करने के लिए आवश्यक है।

जैसे-जैसे AI इंजीनियरिंग उत्पादकता को बदलता है, प्रश्न बदल सकता है:

“एक डेवलपर घंटे की लागत क्या है?” → “जब कम डेवलपर घंटे आवश्यक हों तो मूल्य पर क्या प्रभाव पड़ता है?”

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

गवर्नेंस गैप के चार मालिक हैं

AI‑सहायता प्राप्त विकास के आसपास गवर्नेंस पर चर्चा केवल उन नीतियों तक सीमित नहीं होनी चाहिए जो तय करती हैं कि डेवलपर्स कौन‑से टूल उपयोग कर सकते हैं।

इंजीनियरिंग संगठनों को कम से कम चार प्रकार के स्वामित्व को परिभाषित करना चाहिए।

1. कोड का मालिक कौन है?

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

2. जोखिम का मालिक कौन है?

तेज़ कोड तभी मूल्यवान है जब वह अन्यत्र समस्याएँ न पैदा करे। एक AI‑जनित कोड पर अनुभवजन्य अध्ययन ने जांचे गए Python स्निपेट्स में 29.5% और JavaScript स्निपेट्स में 24.2% में सुरक्षा कमजोरियाँ पाईं। शोध ने 43 Common Weakness Enumeration श्रेणियों में भी कमजोरियों की पहचान की।

हालांकि, अध्ययन ने पाया कि स्थिर‑विश्लेषण चेतावनियों को Copilot Chat में फ़ीड करने से पहचानी गई सुरक्षा समस्याओं में से 55.5% तक को ठीक किया जा सकता है। यह शोध दर्शाता है कि AI कोड समस्याएँ बना और हल कर सकता है, लेकिन संगठनों को इसके आउटपुट को सत्यापित करने की प्रक्रियाएँ स्थापित करनी होंगी।

NIST का SP 800-218A इस सिद्धांत को विस्तारित करता है, जिसमें जेनरेटिव AI और द्वि‑उपयोग आधार मॉडल को संबोधित करने वाले सर्वोत्तम अभ्यासों को Secure Software Development Framework में जोड़ा गया है।

3. उत्पादकता वृद्धि का मालिक कौन है?

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

जो चीज़ स्थिर रहती है वह है पारदर्शी प्रक्रियाओं और सहमत गुणवत्ता वाले कार्य की डिलीवरी की आवश्यकता।

4. प्राथमिकता निर्धारण का मालिक कौन है?

AI फीचर निर्माण को सस्ता और तेज़ बना सकता है, लेकिन यह तय नहीं कर सकता कि वे फीचर आवश्यक हैं या नहीं।

वास्तव में, विकास क्षमता में वृद्धि से प्राथमिकता निर्धारण और अधिक महत्वपूर्ण हो सकता है। जब टीमें तेज़ी से बना और प्रयोग कर सकती हैं, तब भी किसी को यह तय करना होगा कि कौन‑से परिणाम उपलब्ध बजट को उचित ठहराते हैं, और कौन‑से विचारों को त्यागना चाहिए।

AI गवर्नेंस अब एक वित्तीय मुद्दा बन रहा है

इन प्रश्नों ने AI गवर्नेंस को अधिक प्रासंगिक बना दिया है। कल्पना करें दो विकास साझेदार समान घंटा‑दर ले रहे हों।

एक ने AI को एक मजबूत इंजीनियरिंग प्रक्रिया में एकीकृत किया है और आवश्यक परिणाम काफी तेज़ी से प्राप्त करता है, जबकि दूसरा अधिक समय लेता है। केवल उनकी घंटा‑दर की तुलना करने से खरीदार को उनके प्रक्रियाओं के बारे में अधिक जानकारी नहीं मिलती।

खरीदारों को मूल्यांकन करना होगा:

• कुल अपेक्षित निवेश
• ओवररन की जिम्मेदारी
• AI‑जनित कार्य के आसपास गुणवत्ता नियंत्रण
• दक्षता लाभ कैसे साझा किए जाएँगे

यदि दोनों पक्ष अनिश्चितता को जानबूझकर स्वीकार करते हैं, तो T&M दोनों के लिए उपयोगी बना रह सकता है। जब आवश्यकताएँ और डिलिवरेबल स्थिर हों, तो फिक्स्ड‑प्राइस व्यवस्था भी काम कर सकती है।

लेकिन AI वैकल्पिक संरचनाओं को भी आकर्षक बनाता है। एक दृष्टिकोण यह है कि अधिकतम वित्तीय सीमा निर्धारित की जाए जबकि स्कोप लचीला रहे। फिर फीचर को व्यवसाय मूल्य के अनुसार प्राथमिकता दी जा सकती है।

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

वही AI बातचीत

इंजीनियरिंग नेताओं को यह समझना चाहिए कि वाणिज्यिक प्रोत्साहन डिलीवरी को कैसे प्रभावित करते हैं। वित्त और प्रोक्योरमेंट टीमों को AI‑सहायता प्राप्त इंजीनियरिंग में पर्याप्त दृश्यता चाहिए ताकि वे यह आकलन कर सकें कि दावा किया गया दक्षता मापने योग्य मूल्य प्रदान कर रही है या नहीं।

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

लेकिन एक दूसरा स्वामित्व प्रश्न है जो प्रौद्योगिकी बजट पर बहुत बड़ा प्रभाव डाल सकता है: जब AI सॉफ़्टवेयर निर्माण की गति बदलता है तो निर्मित या खोए हुए मूल्य का मालिक कौन है?

वे संगठन जो यह निर्धारित करेंगे कि तेज़ इंजीनियरिंग वास्तव में बेहतर उत्पाद बनाती है, निवेश को नियंत्रित करती है, और मापने योग्य व्यावसायिक परिणाम प्राप्त करती है, वही प्रतिस्पर्धियों से आगे रहने में सक्षम होंगे।

यदि आपका विकास टीम कल AI अपनाता है, तो क्या आपका वर्तमान गवर्नेंस और वाणिज्यिक मॉडल आपको यह बता पाएगा कि इससे डिलीवरी अधिक मूल्यवान हुई है या नहीं?