जूनियर-डेवलपर सवाल: क्या AI-सहायता प्राप्त कोड सीखना गिना जाता है?

उपयोगी कसौटी यह नहीं है कि डेवलपर ने कितना कोड टाइप किया। यह है कि क्या वे जो शिप करते हैं, उसे समझा सकते हैं, परख सकते हैं और बनाए रख सकते हैं।

एक पुल रिक्वेस्ट असली सवाल छिपा सकता है

एक जूनियर डेवलपर एक काम करने वाला फ़ीचर सबमिट करता है। एक AI कोडिंग टूल ने पहले ड्राफ़्ट का ज़्यादातर हिस्सा तैयार किया। टेस्ट पास हो जाते हैं, लेकिन मैनेजर सोचता है: क्या डेवलपर ने कुछ सीखा, और क्या कोड मर्ज करने के लिए सुरक्षित है?

ये दो अलग-अलग सवाल हैं। एक डेवलपर की तरक़्क़ी के बारे में है। दूसरा सॉफ़्टवेयर की तैयारी के बारे में है। इन्हें मिला देने से ख़राब फ़ैसले होते हैं, जैसे उपयोगी टूल पर पाबंदी लगाना या सिर्फ़ इसलिए कोड स्वीकार करना कि वह डेमो में काम करता है।

AI-सहायता प्राप्त कोडिंग तब सीखना गिना जाता है जब डेवलपर सक्रिय रूप से आउटपुट को समझता और बेहतर बनाता है। यह तब सीखना नहीं गिना जाता जब जनरेट किया गया कोड जाँच, तर्क और फ़ीडबैक की जगह ले लेता है।

टाइप करना कभी सीखने जैसा नहीं रहा

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

AI सहायता का पैमाना बदल देता है। यह डेवलपर द्वारा समस्या समझने से पहले ही एक पूरा दिखने वाला समाधान तैयार कर सकता है। इससे कमज़ोर समझ को पहचानना मुश्किल हो जाता है। एक प्रशंसनीय जवाब एक सरल टेस्ट पास कर सकता है, जबकि फिर भी वह त्रुटियों, सुरक्षा सीमाओं, समवर्तीता (concurrency) या कोडबेस की परंपराओं को ग़लत तरीक़े से संभाल रहा हो।

सही सवाल यह नहीं है, “क्या यह AI ने लिखा?” यह है, “क्या डेवलपर इसकी ज़िम्मेदारी ले सकता है?”

एक लर्निंग लूप जो डेवलपर को नियंत्रण में रखता है

जनरेट किए गए कोड के प्रतिशत से ज़्यादा यह लूप मायने रखता है। एक डेवलपर बहुत कम टाइप करके भी व्यवहार को ट्रेस करके, विकल्पों की तुलना करके और विफलताओं को ठीक करके गहराई से सीख सकता है। दूसरा सब कुछ मैन्युअल रूप से टाइप करके भी किसी ऐसे पैटर्न को दोहराकर कम सीख सकता है जिसे वह समझता नहीं।

सीखने के सबूत को रिलीज़ के सबूत से अलग रखें

मैनेजरों को विकास और डिलीवरी दोनों के लिए सबूत चाहिए।

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

यह एक आम ग़लती से भी बचाता है: टूल इस्तेमाल को दुर्व्यवहार मानना जबकि सामान्य कोड गुणवत्ता नियंत्रण कमज़ोर छोड़ देना। कोड को समीक्षा और सबूत के ज़रिए भरोसा कमाना चाहिए, चाहे उसे किसी ने भी या किसी भी चीज़ ने ड्राफ़्ट किया हो।

AI किसमें अच्छा है—और जूनियरों को कहाँ सावधानी बरतनी चाहिए

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

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

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

मैनेजरों को क्या बदलना चाहिए

तर्क की समीक्षा करें, प्रॉम्प्ट इतिहास की नहीं। डेवलपर से समझाने को कहें कि बदलाव इस तरह क्यों डिज़ाइन किया गया, क्या विफल हो सकता है और उन्होंने कौन-सा विकल्प ख़ारिज किया। मक़सद समझ को परखना है, पूछताछ का मंचन करना नहीं।

सामान्य इंजीनियरिंग सबूत की माँग करें। जनरेट किए गए कोड को भी टेस्ट, समीक्षा, सुरक्षा जाँच और परिचालन सोच चाहिए। इसे न तो कम मानक मिलना चाहिए, न कोई जादुई ऊँचा मानक।

ऐसे काम बनाएँ जो समझ को उजागर करें। डेवलपर से समाधान में बदलाव करने, जानबूझकर डाली गई विफलता का निदान करने या रिक्वेस्ट पाथ समझाने को कहें। ये अभ्यास बताते हैं कि क्या ज्ञान जनरेट किए गए जवाब से आगे भी स्थानांतरित होता है।

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

जूनियर डेवलपर्स को क्या करना चाहिए

AI-सहायता प्राप्त कोड के लिए पुल रिक्वेस्ट खोलने से पहले, इनका जवाब देने में सक्षम हों:

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

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

जानें, इस्तेमाल करें या महारत हासिल करें?

जानें: हर डेवलपर को समझना चाहिए कि जनरेट किया गया कोड समझे जाने से पहले भी पूरा दिख सकता है।

इस्तेमाल करें: जूनियर डेवलपर्स और समीक्षकों को रोज़ के काम पर जाँच–परीक्षण–व्याख्या लूप का अभ्यास करना चाहिए।

महारत हासिल करें: इंजीनियरिंग मैनेजरों और तकनीकी लीड को ऐसी समीक्षा, मेंटरिंग और मूल्यांकन प्रणालियाँ डिज़ाइन करनी चाहिए जो टाइपिंग स्पीड के बजाय निर्णय-क्षमता और तरक़्क़ी को मापें।

व्यावहारिक जवाब

हाँ, AI-सहायता प्राप्त कोडिंग सीखना गिना जा सकता है। सबूत यह नहीं है कि फ़ीचर एक बार काम करता है। सबूत यह है कि डेवलपर इसे समझा सकता है, परख सकता है, बदल सकता है और विफल होने पर प्रतिक्रिया दे सकता है।

संगठनों को कोड के लिए एक सबूत-आधारित रिलीज़ मानक और डेवलपर्स के लिए एक दिखाई देने वाला सीखने का मानक रखना चाहिए। यह इससे कहीं ज़्यादा निष्पक्ष—और सुरक्षित—है कि कितनी लाइनें किसी इंसानी कीबोर्ड से आईं, यह मापने से।

आगे पढ़ें

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 10 July 2025. एक रैंडमाइज़्ड अध्ययन जो दिखाता है कि अनुभव की गई गति और मापा गया कार्य-समय अलग क्यों हो सकते हैं। September 2026 में समीक्षा की गई।
• We Are Changing Our Developer Productivity Experiment Design — METR, 24 February 2026. अपने फ़ॉलो-अप कार्य में चयन और मापन की समस्याओं को समझाता है। September 2026 में समीक्षा की गई।
• Google Engineering Practices: How to Do a Code Review — Google. व्यावहारिक समीक्षा मार्गदर्शन जो इंसानी और AI-सहायता प्राप्त कोड दोनों पर लागू होता है। September 2026 में समीक्षा की गई।
• 2025 Stack Overflow Developer Survey: AI — Stack Overflow, 2025. AI टूल के साथ डेवलपर के इस्तेमाल, भरोसे और निराशा पर सर्वेक्षण सबूत। September 2026 में समीक्षा की गई।