How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study
100 पेशेवरों के एक मिश्रित-पद्धति अध्ययन के माध्यम से, यह शोध पत्र प्रकट करता है कि सॉफ्टवेयर इंजीनियरिंग एजेंटों का निर्माण कोडिंग से हटकर आवश्यकताओं और समन्वय जैसी गैर-कोडिंग गतिविधियों की ओर विकास संबंधी बाधाओं को स्थानांतरित कर देता है, जिससे एक मूल्यांकन-संचालित वर्कफ़्लो को बढ़ावा मिलता है जो एक सात-चरणीय प्रक्रिया और अविश्वसनीय मूल्यांकन संकेतों एवं बोध ऋण (comprehension debt) जैसी चुनौतियों द्वारा अभिलक्षित है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि सॉफ्टवेयर डेवलपमेंट पहले एक हथौड़े और आरी से घर बनाने जैसा था। आपको हर एक तख्ते को खुद काटना पड़ता था, हर एक शिंगल को हाथ से ठोकना पड़ता था और हर सतह को हाथ से घिसना पड़ता था। यह धीमा, थकाऊ था, और "कठिन हिस्सा" बस हथौड़ा चलाना था।
अब, कल्पना कीजिए कि कोई आपको एक जादुई, अति-तेज रोबोट देता है जो पलक झपकते ही पूरा घर काट सकता है, ठोक सकता है और घिस सकता है। अचानक, हथौड़ा समस्या नहीं रह जाता। समस्या यह है कि रोबोट इतना तेज़ है कि आपके ब्लूप्रिंट (नक्शा) बनाने से पहले ही वह एक पूरी हवेली खड़ी कर देता है।
यही हुआ जब डेवलपर्स ने SE एजेंट्स (AI रोबोट जो कोड लिखते हैं) का उपयोग करना शुरू किया। शोधकर्ताओं द्वारा 12 अलग-अलग कंपनियों के 20 बिल्डर्स से बात करने और 80 अन्य का सर्वेक्षण करने वाले एक नए अध्ययन से पता चला कि हालांकि रोबots ने कोड लिखना सस्ता और तेज़ बना दिया, लेकिन उन्होंने काम को गायब नहीं किया। इसके बजाय, "बॉटलनेक" (प्रक्रिया में ट्रैफिक जाम) सड़क के एक अलग हिस्से में चला गया।
यहाँ शोधकर्ताओं ने क्या खोजा, एक जिज्ञासु खोजकर्ता की भाषा का उपयोग करते हुए दिया गया है।
नया सात-चरणीय नृत्य (The New Seven-Step Dance)
पेपर सुझाव देता है कि इन AI एजेंट्स को बनाना अब एक सीधी रेखा नहीं है; यह सात चरणों वाला एक लूपिंग डांस है। यह एक फैक्ट्री असेंबली लाइन की तरह कम और एक वीडियो गेम की तरह अधिक है जहाँ आप उच्च स्कोर प्राप्त करने के लिए स्तरों को बार-बार खेलते हैं।
- ब्लूप्रिंट (आवश्यकताएं): आप रोबोट को बताते हैं कि क्या करना है। लेकिन अब, आपको निर्देशों को इतना स्पष्ट रूप से लिखना होगा कि इंसान और रोबोट दोनों उन्हें पढ़ सकें।
- स्कोरकार्ड (मूल्यांकन): यह सबसे महत्वपूर्ण नया चरण है। आप काम के अंत में केवल जांच नहीं करते हैं; आप रोबोट को काम करते समय दिशा देने के लिए एक स्कोरकार्ड का उपयोग करते हैं।
- ईंधन (डेटा): आप रोबोट को सीखने के लिए अच्छे काम के उदाहरण खिलाते हैं।
- निर्माण (सिस्टम कंस्ट्रक्शन): आप रोबोट के लिए एक 'दिमाग' (एक मॉडल) चुनते हैं और उसके चारों ओर एक "हारनेस" (टूल्स और मेमोरी वाला कवच) बनाते हैं।
- टेस्ट ड्राइव (परीक्षण और परिनियोजन): आप रोबोट को चलने देते हैं और देखते हैं कि क्या वह क्रैश होता है।
- फीडबैक लूप (मानवीय फीडबैक): आप देखते हैं कि वह क्या करता है और उसे बताते हैं, "नहीं, इसे इस तरह करो," या "हाँ, यह बहुत बढ़िया था।"
- ट्यून-अप (अनुकूली रखरखाव): रोबोट के दिमाग को उसके निर्माता से अपडेट मिल सकता है, जिससे उसके सोचने का तरीका बदल सकता है। आपको अपने हारनेस को तालमेल बिठाने के लिए लगातार ट्यून करना होगा।
महान बदलाव: हथौड़ा चलाने वाले से रोबोट मैनेजर तक
अध्ययन में पाया गया कि क्योंकि रोबोट कोड इतनी तेज़ी से लिख सकते हैं, इसलिए "कोडिंग ही कठिन हिस्सा है" वाली पुरानी धारणा रद्द हो गई है। शोधकर्ता तर्क देते हैं कि कोडिंग कभी सबसे कठिन हिस्सा नहीं थी; यह बस सबसे शोर करने वाला हिस्सा था।
अब जब रोबोट भारी काम कर रहा है, तो असली काम समीक्षा (reviewing) और मूल्यांकन (evaluating) की ओर स्थानांतरित हो गया है।
- "वाइब कोडिंग" प्रभाव: क्योंकि रोबोट चीज़ें इतनी तेज़ी से बना सकता है, इसलिए "शोधकर्ता," "इंजीनियर," और "मैनेजर" के बीच की रेखाएं धुंधली हो रही हैं। एक व्यक्ति अब पूरे काम को कर सकता है, विचार सोचने से लेकर अंतिम बग को ठीक करने तक।
- "ब्लैक बॉक्स" समस्या: शोधकर्ता सुझाव देते हैं कि क्योंकि रोबोट एक "ब्लैक बॉक्स" है (आप ठीक से नहीं देख सकते कि वह कैसे सोचता है), आप बस उस पर भरोसा नहीं कर सकते। आपको एक सख्त इवैल्यूएशन-ड्रिवन डेवलपमेंट शैली की आवश्यकता है। इसका मतलब है कि आप शुरू करने से पहले सफलता के नियम परिभाषित करते हैं, और आप लगातार जांचते हैं कि क्या रोबोट वास्तव में बेहतर हो रहा है, न कि केवल तेज़।
छह जाल (चुनौतियां)
सुपर-फास्ट रोबोटों के साथ भी, बिल्डर्स को छह बड़ी बाधाओं का सामना करना पड़ा। पेपर सुझाव देता है कि ये वास्तविक, कठिन समस्याएं हैं, न कि केवल मामूली गड़बड़ियाँ।
- टूटा हुआ स्कोरकार्ड: आपको कैसे पता चलेगा कि रोबोट ने अच्छा काम किया? शोधकर्ताओं ने पाया कि रोबोट को ग्रेड करने के लिए उपयोग किए जाने वाले "टेस्ट" अक्सर टूटे हुए होते हैं। कभी-कभी रोबोट टेस्ट की अपेक्षा से बेहतर समाधान ढूंढ लेता है, लेकिन टेस्ट उसे "फेल" कहता है क्योंकि वह पुराने उत्तर की तलाश में होता है। दूसरी ओर, टेस्ट को हर बार चलाना बहुत महंगा होता है।
- "कुछ न बदलें, सब कुछ बदल दें" का श्राप: यह एक डरावना अनुभव है। शोधकर्ताओं ने पाया कि यदि कंपनी जो रोबोट के दिमाग को बनाती है वह उसे अपडेट करती है (भले ही आपने अपना कोड नहीं छुआ हो), तो आपका रोबलेट अचानक अलग व्यवहार करने लग सकता है। एक टूल जो कल काम कर रहा था, आज टूट सकता है, भले ही आपने शून्य लाइन कोड बदला हो।
- सुरक्षा बनाम गति: बिल्डर अक्सर स्वीकार करते हैं कि वे रोबोटों से डरते हैं लेकिन काम जल्दी करने के लिए उन्हें चलने देते हैं। पेपर सुझाव देता है कि यह खतरनाक है। एक टीम ने एक रोबोट को खुला छोड़ दिया, और उसने गलती से उपयोगकर्ता के होम डायरेक्टरी को डिलीट कर दिया क्योंकि वह अपने निर्देशों को भूल गया था।
- "अलिखित नियमों" का अंतर: रोबोट केवल वही पढ़ सकते हैं जो लिखा गया है। लेकिन वास्तविक जीवन में, बहुत सारा ज्ञान केवल "लोगों के दिमाग में" होता है (जैसे कि एक विशिष्ट दीवार टेढ़ी क्यों बनाई गई थी)। शोधकर्ताओं ने पाया कि रोबोट इस "अनकहे" ज्ञान तक नहीं पहुँच सकते, जिससे भ्रम पैदा होता है।
- कॉम्प्रिहेन्शन डेट (समझ का कर्ज): यह सबसे बड़ा आश्चर्य है। रोबोट कोड को इंसानों की समझ से कहीं अधिक तेज़ी से लिख रहे हैं। यह ऐसा है जैसे रोबोट एक दिन में गगनचुंबी इमारत बना रहा है, लेकिन आप अभी भी ब्लूप्रिंट समझने की कोशिश कर रहे हैं। बिल्डर उस कोड का "कर्ज" जमा कर रहे हैं जिसे वे समझ नहीं पा रहे हैं। इसे ठीक करने के लिए, कुछ टीमें कोड को बचाने के बजाय, कोड को फिर से बनाने के निर्देशों को सहेजने लगी हैं।
- नकली उत्पादकता: यदि आप केवल उन कोड की लाइनों को गिनते हैं जो रोबोट लिखता है, तो यह दिखता है कि हर कोई बहुत उत्पादक है। लेकिन शोधकर्ता सुझाव देते हैं कि यह एक जाल है। 10,000 लाइनें लिखना जिन्हें कोई समझ नहीं सकता या जिसकी आवश्यकता नहीं है, "उत्पादक" नहीं है। यह केवल "शोर" है।
हम कितने निश्चित हैं?
शोधकर्ता इस निष्कर्ष के बारे में काफी आश्वस्त हैं क्योंकि उन्होंने केवल अनुमान नहीं लगाया; उन्होंने इसे मापा है।
- उन्होंने 20 विशेषज्ञों का साक्षात्कार लिया और फिर 80 अन्य का सर्वेक्षण किया।
- जब उन्होंने सर्वेक्षण समूह से पूछा कि क्या वे निष्कर्षों से सहमत हैं, तो 91% नए वर्कफ़्लो से सहमत थे, और 71% से 95% के बीच विशिष्ट चुनौतियों से सहमत थे।
- वे मूल साक्षात्कार लेने वालों के पास वापस गए यह जांचने के लिए कि क्या वे सारांश से सहमत हैं (एक प्रक्रिया जिसे "मेंबर चेकिंग" कहा जाता है), और विशेषज्ञों ने कहा, "हाँ, हम बिल्कुल यही करते हैं।"
निचोड़ (The Bottom Line)
पेपर सुझाव देता है कि AI एजेंट्स बनाना सॉफ्टवेयर इंजीनियरिंग को आसान नहीं बना रहा है; इसने इसे केवल अलग बना दिया है। "कठिन हिस्सा" कोड लिखने से हटकर रोबोट को प्रबंधित करने, उसके काम की जांच करने और यह सुनिश्चित करने की ओर चला गया है कि वह गलती से इंटरनेट को डिलीट न कर दे।
शोधकर्ता निष्कर्ष निकालते हैं कि जैसे-जैसे कार्यान्वयन (implementation) सस्ता होता जा रहा है, बॉटलनेक गायब नहीं होते—वे बस स्थानांतरित हो जाते हैं। सॉफ्टवेयर बनाने का भविष्य तेज़ी से टाइप करने के बारे में नहीं है; यह उन रोबोटों के लिए एक बेहतर प्रबंधक, एक सख्त न्यायाधीश और एक स्मार्ट आर्किटेक्ट होने के बारे में है जो भारी काम करते हैं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।