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