एआई इंजीनियरों के विकास को कैसे बदलता है

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

यह एक गंभीर प्रश्न था, और कई बुद्धिमान लोगों ने इसे गंभीरता से लिया।

उस समय, मेरा उत्तर यह था कि अन्य पेशों ने पहले से ही इस समस्या के संस्करणों का समाधान कर लिया है। मेडिकल स्कूल से स्नातक होने और तुरंत स्वतंत्र रूप से ओपन-हार्ट सर्जरी करने वाले डॉक्टर नहीं हैं। डॉक्टर वर्षों तक पर्यवेक्षण के तहत छाया, इंटर्न, निवास, और अभ्यास करते हैं trước कि प्रणाली उन्हें अकेले काम करने के लिए विश्वास करती है।

कार्यकारी नेतृत्व में भी यही पैटर्न है। कॉलेज से स्नातक होने और तुरंत एक फॉर्च्यून 500 कंपनी का प्रबंधन करने वाले लोग नहीं हैं। लोग छोटी टीमों का प्रबंधन करते हैं, फिर बड़े व्यवसायिक इकाइयों का, और धीरे-धीरे निर्णय लेने की क्षमता प्राप्त करते हैं क्योंकि भूमिका की जटिलता बढ़ती है।

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

तीन उदाहरण

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

उनके अनुसार, सबसे बड़ा अंतर यह था कि उनके प्राथमिक ट्यूटर वास्तव में चैटजीपीटी था।

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

मानव ट्यूटर अच्छे थे। वे केवल उपलब्धता, पुनरावृत्ति और व्यक्तिगतीकरण का मिलान नहीं कर सके।

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

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

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

उसे यह पसंद आया।

एक बार उसने मजाक में कहा, “अगर कोडिंग इतनी आसान है, तो मैं विचारों से बाहर हो जाऊंगा।”

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

तेजी से प्रतिक्रिया लूप

इन उदाहरणों में से कोई भी वास्तव में चेक, भौतिकी या कोड समीक्षा के बारे में नहीं है।

वे अत्यधिक व्यक्तिगत प्रतिक्रिया के निरंतर उपलब्ध होने के उदाहरण हैं।

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

एआई प्रतिक्रिया लूप को ही बदलता है।

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

सबसे महत्वपूर्ण बात यह है कि प्रतिक्रिया तब आती है जब इंजीनियर अभी भी समस्या के अंदर है, न कि दो दिन बाद जब संदर्भ फीका पड़ जाता है।

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

वरिष्ठ इंजीनियरों के साथ बैंडविद्थ बोतलनेक अब धीरे-धीरे सीखने वाले के साथ बैठता है।

सुरक्षा जाल में सुधार

एक और बदलाव है जो उतना ही महत्वपूर्ण है।

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

कई क्लासिक त्रुटियां अब तुरंत ध्वजांकित हो जाती हैं: हार्डकोडेड प्रमाण पत्र, निगली गई अपवाद, असुरक्षित क्वेरी, सुरक्षा समस्याएं, स्पष्ट वास्तुकला समस्याएं, खराब स्कोप वाली निर्भरताएं। खराब पुल अनुरोध अब बढ़ते ही पकड़े जाते हैं इससे पहले कि वे कभी लैपटॉप छोड़ें।

यह जूनियर कार्य के लिए फर्श को बदलता है।

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

यह मार्गदर्शन या पर्यवेक्षण की आवश्यकता को समाप्त नहीं करता है। यह बताता है कि मार्गदर्शन सबसे अधिक मूल्यवान कहां है।

अंतर बढ़ता है

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

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

एआई कभी भी बौद्धिक निष्क्रियता का समाधान नहीं था।

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

संज्ञानात्मक प्रयास गायब नहीं हुआ। यह लूप में पहले स्थानांतरित हो गया और दोहराने के लिए सस्ता हो गया।

यह संभवतः जुड़े हुए इंजीनियरों और निष्क्रिय लोगों के बीच की खाई को चौड़ा करता है।

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

उत्पाद निर्णय अधिक मायने रखता है

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

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

इंजीनियरिंग भूमिकाएं उत्पाद-उन्मुख सोच की ओर बढ़ रही हैं क्योंकि कार्यान्वयन घर्षण जारी रहता है। प्लंबिंग काम उतना मायने नहीं रखता जितना यह समझना महत्वपूर्ण है कि निर्मित प्रणाली वास्तव में सही समस्या का समाधान करती है या नहीं।

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

एआई के साथ प्रशिक्षित एक इंजीनियर शायद किसी ऐसे व्यक्ति से बहुत अलग सोचेगा जिसे पंद्रह साल पहले प्रशिक्षित किया गया था।

वे मानेंगे कि पुनरावृत्ति सस्ती है। वे तेजी से कई दृष्टिकोणों का प्रोटोटाइप बनाएंगे और एक के बारे में दिनों तक बहस नहीं करेंगे। वे उपयोगकर्ताओं और कार्यान्वयन के बीच बहुत तंग प्रतिक्रिया लूप की अपेक्षा करेंगे क्योंकि चीजों को आजमाने की लागत लगातार गिर रही है।

यह एक अलग प्रकार का इंजीनियर बनाता है, जो बहुत छोटे चक्रों द्वारा आकार दिया जाता है जो विचार और कार्यान्वयन के बीच होते हैं।

संगठनों को नौकरी के विज्ञापन, मूल्यांकन, मार्गदर्शन और पदोन्नति के बारे में पुनर्विचार करने की आवश्यकता होगी। लेकिन सॉफ्टवेयर पहले से ही कई बार ऐसे संक्रमण से गुजर चुका है: जब वेब आया, जब मोबाइल आया, जब क्लाउड इंफ्रास्ट्रक्चर ने ऑन-प्रिमिस सिस्टम को बदल दिया।

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

परिचालन निहितार्थ

जूनियर इंजीनियरों के लिए सलाह विशेष रूप से ग्लैमरस नहीं है।

वास्तविक परियोजनाओं का चयन करें। एक छाया समीक्षक के रूप में एआई का उपयोग करते हुए काम करें। प्रतिक्रिया को ध्यान से पढ़ें। कभी-कभी इसका विरोध करें। अनुवर्ती प्रश्न पूछें। उन पैटर्न का ट्रैक रखें जो यह त्रुटियों को पकड़ता है।

यह निर्णय लेने की क्षमता विकसित करने के लिए सबसे तेज़ मार्गों में से एक है, एक व्यस्त वरिष्ठ इंजीनियर के लिए मार्गदर्शन के लिए अंततः समय निकालने की प्रतीक्षा करने से बहुत तेज़।

प्रबंधकों के लिए, बोतलनेक भी बदलता है।

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

जो संगठन इन प्रणालियों को अच्छी तरह से संरचित करते हैं वे संभवतः पिछली पीढ़ियों की तुलना में प्रतिभा का विकास तेजी से करेंगे।

और नेतृत्व टीमों के लिए, यह शायद जूनियर इंजीनियरों को मुख्य रूप से प्रतिस्थाप्य निष्पादन क्षमता के रूप में देखना बंद करने के लिए समझ में आता है। कई संगठनों में, वे प्रयोग, ऊर्जा और रचनात्मक पुनरावृत्ति के सस्ते स्रोतों में से एक बन सकते हैं।

एक अलग पीढ़ी के इंजीनियर

मेरे मित्र ने चेक सीखा क्योंकि उन्होंने अपनी जेब में एक व्यक्तिगत ट्यूटर ले जाने में सक्षम थे। मेरे बेटे को भौतिकी में एक ऐसा इंटरैक्टिव फीडबैक मिल रहा है जिसका मुझे कभी उपयोग नहीं मिला। मेरे भतीजे को अब रात में सुझावित सुधार और बाजार अनुसंधान मिलता है जब वह सोता है।

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

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