कोई जूनियर डेवलपर AI सहायक से अनजान लाइब्रेरी इस्तेमाल करने को कह सकता है, काम करता हुआ कोड पा सकता है और आगे बढ़ सकता है। फ़ीचर तैयार हो सकता है, जबकि डेवलपर अभी यह न समझता हो कि वह काम क्यों करता है। अगली बार कोड टूटने, ज़रूरतें बदलने या किसी को यह तय करना हो कि सहायक का सुधार सुरक्षित है या नहीं—तब यह फ़र्क मायने रखता है।
सॉफ़्टवेयर इंजीनियर Alexandru Nedelcu ने यह चिंता अपने 22 सितंबर के निबंध में उठाई। उनका तर्क है कि डेवलपर कोड पढ़ने, विकल्प चुनने और गलतियों की ज़िम्मेदारी लेने से निर्णय-क्षमता विकसित करते हैं। कुछ कंपनियों द्वारा AI-विरोधी नीतियों का प्रचार करने की उनकी भविष्यवाणी राय है, उद्योग में देखा गया बदलाव नहीं। जनवरी में प्रकाशित एक अलग प्रयोग सीखने के सवाल को सीमित और जाँचने योग्य रूप देता है: AI की मदद से काम पूरा करने के तुरंत बाद प्रोग्रामर क्या समझ पाए? Anthropic का शोध-विवरण
बड़ा बदलाव
- क्या बदला: AI की मदद से बिना उसके तर्क को समझे तैयार सॉफ़्टवेयर जमा करना आसान हो जाता है। नए डेवलपर के उसे समझाने या ठीक करने के ज़रूरी फ़ैसलों का अभ्यास करने से पहले ही AI कार्यान्वयन दे सकता है।
- यह क्यों मायने रखता है: प्रबंधकों को आज अधिक काम मिल सकता है, पर इससे वह रास्ता कमज़ोर पड़ सकता है जिससे जूनियर कर्मचारी कल की विफलताओं की वजह ढूँढने वाले लोग बनते हैं। अनजानी अवधारणाओं वाले काम में जोखिम सबसे अधिक है; परिचित काम में मदद फिर भी उपयोगी हो सकती है।
- क्या देखना है: टीमें सीखने को काम पूरा करने का हिस्सा मानना शुरू कर सकती हैं और AI की मदद से बने काम को समझाने, उसकी समस्या ढूँढने और उसे बदलने के लिए समय रख सकती हैं। ऐसा होने पर भर्ती अभ्यास और कोडिंग उत्पाद गति के साथ प्रदर्शित समझ को भी महत्व दे सकते हैं।
काम पूरा होना और कौशल सीखना अलग-अलग नतीजे हैं
एक 52 प्रोग्रामरों का यादृच्छिक नियंत्रित अध्ययन में प्रतिभागियों ने Trio नाम की एक अनजान Python लाइब्रेरी का उपयोग करके कोडिंग के दो काम पूरे किए। आधे लोगों को कोडिंग वातावरण में AI सहायक मिला और आधे को नहीं। उन्हें पता था कि बाद में प्रश्नोत्तरी होगी। काम के तुरंत बाद हुई प्रश्नोत्तरी में अवधारणाओं, कोड पढ़ने और डीबगिंग की जाँच की गई।
AI समूह का औसत अंक 50% था, जबकि AI के बिना काम करने वाले समूह का 67%—यह 17 प्रतिशत-अंक का अंतर है, 17% की सापेक्ष गिरावट नहीं। डीबगिंग के सवालों में अंतर सबसे बड़ा था। AI समूह ने औसतन करीब दो मिनट जल्दी काम पूरा किया, लेकिन समय का यह अंतर सांख्यिकीय रूप से महत्वपूर्ण नहीं था। ये एक लाइब्रेरी के साथ थोड़े समय के अनुभव और तुरंत हुई परीक्षा के नतीजे हैं; डेवलपर के करियर या उत्पादन प्रणाली की गुणवत्ता का माप नहीं। शोधकर्ताओं के नतीजे और सीमाएँ
शोधकर्ताओं ने यह भी देखा कि प्रतिभागियों ने सहायक का उपयोग कैसे किया। कुछ ने कोड लिखने और डीबगिंग का अधिकतर काम सहायक को सौंप दिया; दूसरों ने स्पष्टीकरण माँगा या अवधारणाओं को खुद समझने की कोशिश की। अधिक सक्रिय ढंग से काम करने वाले समूहों के अंक आम तौर पर बेहतर थे, लेकिन इन छोटे समूहों की पहचान बाद में की गई। प्रतिभागियों को AI उपलब्ध होने या न होने के लिए यादृच्छिक रूप से बाँटा गया था, किसी खास बातचीत के तरीके के लिए नहीं। स्पष्टीकरण माँगना सीखने वाले की मदद कर सकता है, लेकिन यह अध्ययन साबित नहीं करता कि कोई एक प्रॉम्प्ट या कार्यप्रवाह सीखने के अंतर को रोकता है। शोधपत्र का संवाद-विश्लेषण
अक्सर गलती ही वह क्षण होती है जब नया डेवलपर समझता है कि लाइब्रेरी क्या मानकर चलती है। अगर सहायक शुरुआती कार्यान्वयन और उसे ठीक करने—दोनों की ज़िम्मेदारी ले ले, तो डेवलपर को ऐसी मान्यताएँ कम दिख सकती हैं। डीबगिंग के अंतर की यह एक संभावित वजह है।
गति अब भी मायने रखती है, और काम का प्रकार जवाब बदल देता है
अलग परिस्थितियों में AI की मदद से कोडिंग तेज़ भी हुई है। GitHub Copilot का एक नियंत्रित प्रयोग में 95 पेशेवर स्वतंत्र ठेकेदारों को JavaScript HTTP सर्वर बनाने का काम दिया गया। काम पूरा करने वालों में Copilot समूह ने औसतन करीब 71 मिनट में काम किया, जबकि नियंत्रण समूह को करीब 161 मिनट लगे—पूरा करने के समय में 55.8% की कमी। शोधकर्ताओं ने यह नहीं जाँचा कि प्रोग्रामरों ने बाद में क्या सीखा। यह सीमित दायरे वाला कार्यान्वयन था, न कि अनजान लाइब्रेरी का परिचय और उसके बाद समझ की परीक्षा।
दोनों नतीजे प्रबंधक के लिए उपयोगी हो सकते हैं। अनुभवी डेवलपर AI से दोहराव वाला काम जल्दी निपटाए, तो बचा समय वास्तविक लाभ हो सकता है। नया सिस्टम सीखने के काम में तेज़ नतीजे और गहरी समझ की अलग-अलग जाँच ज़रूरी है। AI पर पूरी तरह रोक लगाने से संभावित लाभ खो जाएँगे, पर यह जवाब नहीं मिलेगा कि लोग काम की निगरानी करना कैसे सीखें।
Nedelcu का निबंध प्रयोग से आगे जाता है। उनका तर्क है कि रखरखाव-योग्यता महीनों या वर्षों में दिखाई देती है और गलतियों की ज़िम्मेदारी से अनुभव बढ़ता है। अध्ययन लंबे समय के रखरखाव को नहीं मापता और न यह दिखाता है कि AI इस्तेमाल करने वाले सीखना पूरी तरह बंद कर देते हैं। उनकी उपयोगी चुनौती संगठन से जुड़ी है: अगर टीम अभ्यास वाले काम तेजी से सौंपने लगे, तो उसके भविष्य के समस्या-समाधानकर्ताओं को अभ्यास कहाँ मिलेगा? Nedelcu का निबंध
कोड चलने के बाद सीखने वाले से कुछ साबित करने को कहें
एक व्यावहारिक उपाय यह है कि नए कर्मचारी को AI-सहायता वाला काम दिया जाए और फिर सीखने की सफलता मानने से पहले उससे स्वतंत्र रूप से एक छोटी जाँच कराई जाए। यह हमारा सुझाया अभ्यास है, किसी भी अध्ययन में परखा गया हस्तक्षेप नहीं:
- समझाएँ: सहायक से पूछे बिना बताएँ कि कोड का अनजान हिस्सा क्यों काम करता है, वह क्या मानकर चलता है और किन स्थितियों में विफल होगा। वरिष्ठ इंजीनियर किए गए असली बदलाव से जुड़ा एक अगला सवाल पूछ सकता है।
- समस्या पहचानें: सुरक्षित परीक्षण शाखा में छोटी और यथार्थवादी विफलता पैदा करें। सीखने वाले से उसका कारण ढूँढने और यह बताने को कहें कि किस संकेत ने आकर्षक लेकिन गलत सुधार को ख़ारिज किया। मकसद तर्क समझना है, कोई आदेश रटना नहीं।
- बदलाव के अनुसार ढालें: कोई ज़रूरत बदलें, फिर सीखने वाले से कार्यान्वयन और उसके परीक्षणों में संशोधन करने को कहें। वह AI का उपयोग कर सकता है, लेकिन उसे नए व्यवहार का तर्क देना और यह बताना चाहिए कि अब भी क्या जाँचना बाकी है।
मिसाल के तौर पर, किसी सहायक के नया asynchronous काम लिखने के बाद समीक्षक पूछ सकता है कि बीच में रद्द होने पर क्या होगा। डेवलपर को प्रक्रिया समझा पाने और बदली हुई ज़रूरत का परीक्षण करने में सक्षम होना चाहिए। केवल कोड समीक्षा किसी ख़ामी को पकड़ सकती है, पर सीखने वाले को अगली ख़ामी सँभालने में असमर्थ छोड़ सकती है। सुझाया अभ्यास पूछता है कि क्या दिया गया कोड ज्ञान भी साथ लेकर आया।
इसका अर्थ यह नहीं कि हर नियमित टिकट को परीक्षा बना दिया जाए। टीम यह अभ्यास अनजान लाइब्रेरी, बार-बार होने वाली विफलताओं या ऐसे कामों के लिए रख सकती है जिनकी ज़िम्मेदारी आगे किसी जूनियर सहकर्मी को मिलने वाली हो। इसमें काम के घंटे और सिस्टम समझने वाला समीक्षक चाहिए। अगर प्रबंधन सिर्फ़ मर्ज हुए काम और बचाए गए समय को गिने, तो इन मदों में कटौती सबसे पहले हो सकती है। इससे आज का उत्पादन बढ़ने पर भी प्रशिक्षण की समस्या और कठिन होगी।
शागिर्दी का सवाल भर्ती और उत्पाद-डिज़ाइन तक पहुँचता है
जूनियर भूमिकाओं में अक्सर काम पूरा करना और निगरानी में अभ्यास करना—दोनों शामिल रहे हैं। जब कोई उम्मीदवार यह दिखाए कि उसने किसी फ़ीचर को प्रभावशाली ढंग से पूरा किया, पर यह न दिखाए कि उसने उस पर तर्क कैसे किया, तो AI इस संतुलन को बदल देता है। नियोक्ता चमकदार रिपॉज़िटरी को स्वतंत्र कौशल का प्रमाण मानने के बजाय उम्मीदवारों से छोटे काम को समझाने और उसमें बदलाव करने को कह सकते हैं। यह भर्ती के लिए सुझाया उपाय है, मौजूदा भर्ती-रुझान का प्रमाण नहीं। इसमें वही क्षमताएँ जाँची जानी चाहिए जिनकी भूमिका को सचमुच ज़रूरत है—हर आवेदक से बिना टूल काम करने की माँग नहीं।
कोडिंग उत्पादों के सामने भी इससे जुड़ा विकल्प है। कोई सहायक जल्दी जवाब देने को प्राथमिकता दे सकता है, या धारणाएँ जाँचना, अवधारणात्मक सवाल पूछना और हल दिखाने से पहले बदलाव आज़माना आसान बना सकता है। अध्ययन में दिखे संवाद-ढंग दूसरे डिज़ाइन को आज़माने का कारण देते हैं, हालाँकि वे यह साबित नहीं करते कि कोई खास इंटरफ़ेस बेहतर सिखाता है। नियोक्ताओं के लिए इससे जुड़ा खरीद का सवाल यह है कि क्या कोई टूल कर्मचारियों को उसके नतीजे की समीक्षा करना और उसे बदलना सिखाता है—सिर्फ़ यह नहीं कि वह कितना कोड बनाता है।
छोटी प्रश्नोत्तरी यह नहीं बता सकती कि पाँच साल में कौन विशेषज्ञ बनेगा। लेकिन यह दिखाती है कि अनजान काम में स्वीकार किया गया कार्यान्वयन, समझ के प्रमाण की जगह नहीं ले सकता। जो टीमें स्वचालन के साथ अगली पीढ़ी को सक्षम भी बनाना चाहती हैं, उन्हें अभ्यास के लिए जगह देनी होगी और यह जाँचना होगा कि जवाब बदलने पर लोग क्या कर सकते हैं।
