To Copilot and Beyond: 22 AI Systems Developers Want Built
860 माइक्रोसॉफ्ट डेवलपर्स के एक सर्वेक्षण के माध्यम से, यह शोध पत्र 22 वांछित एआई प्रणालियों की पहचान करता है जो "सीमित प्रतिनिधिमंडल" (बाउंडेड डेलिगेशन) को प्राथमिकता देते हैं—जो पेशेवर शिल्प को संरक्षित करते हुए असेंबली कार्यों को आत्मसात करते हैं—साथ ही एआई-सहायता प्राप्त विकास में बढ़ते 'राइट-शिफ्ट' बोझ को संबोधित करने के लिए गुणवत्ता संकेतों, अधिकार स्कोपिंग और अनिश्चितता प्रबंधन की महत्वपूर्ण आवश्यकताओं को भी रेखांकित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक व्यस्त, उच्च-स्तरीय रेस्टोरेंट के हेड शेफ हैं। वर्षों से, आपका काम सब्जियां काटना, स्टेक सीयर करना और व्यंजन सजाना रहा है। लेकिन हाल ही में, आपने एक सुपर-फास्ट रोबोटिक हाथ काम पर रखा है जो आपसे दस गुना तेजी से सब्जियां काट सकता है और स्टेक सीयर कर सकता है।
शुरुआत में, यह एक चमत्कार जैसा लगता है। आप कम समय में अधिक भोजन बना रहे हैं! लेकिन फिर, एक समस्या उभरती है। रोबट इतना तेज़ है कि रसोई अचानक पूरी तरह से पके हुए स्टेक और कटी हुई प्याज से भर जाती है, लेकिन किसी को नहीं पता कि वे कैसे बने।
- क्या रोबोट ने सही मसालों का उपयोग किया?
- क्या मांस वास्तव में खाने के लिए सुरक्षित है?
- सामग्री कहाँ से आई?
- यदि किसी ग्राहक की तबीयत बिगड़ती है तो जिम्मेदार कौन है?
अब, खाना बनाने के बजाय, आप हर उस स्टेक का निरीक्षण करने, रेसिपी बुक्स को फिर से पढ़ने और स्वास्थ्य निरीक्षकों के सवालों के जवाब देने में जूझ रहे हैं जिसे रोबोट ने बनाया है। आप पहले से भी अधिक मेहनत कर रहे हैं, भले ही रोबोट "खाना" बना रहा हो।
यह लेख बिल्कुल इसी बारे में है।
बड़ी समस्या: "रोबोट शेफ" विरोधाभास (The "Robot Chef" Paradox)
शोधकर्ताओं (ओरेगन स्टेट यूनिवर्सिटी और माइक्रोसॉफ्ट से) ने 860 सॉफ्टवेयर डेवलपर्स से पूछा: "आप जानते हैं न वे AI कोडिंग टूल्स (जैसे GitHub Copilot) जो आपके लिए कोड लिखते हैं? आपको उनसे और क्या करने की आवश्यकता है?"
उन्होंने एक दिलचस्प विसंगति पाई। अधिकांश AI टूल्स कोड लिखने (काटने और सीयर करने) पर ध्यान केंद्रित करते हैं। लेकिन डेवलपर्स अपना दिन केवल लगभग 10% समय वास्तव में कोड लिखने में बिताते हैं। बाकी 90% समय वे उस "मेसी" मानवीय काम में बिताते हैं:
- चीजें क्यों टूट गईं, इसे डीबग करना (Debugging)।
- डॉक्यूमेंटेशन लिखना ताकि दूसरे कोड को समझ सकें।
- यह जांचना कि कोड सुरक्षित है या नहीं।
- गैर-तकनीकी बॉसों को तकनीकी निर्णय समझाना।
- नई टीम के सदस्यों को ऑनबोर्ड करना।
AI उस 10% हिस्से को तेज कर रहा है, लेकिन वह बाकी 90% (उस "मेसी" काम) को अछूता छोड़ दे रहा है। यह एक बाधा (bottleneck) पैदा कर रहा है। कोड इतनी तेजी से उत्पन्न हो रहा है कि इंसान उसे सत्यापित (verify), समझ या भरोसा नहीं कर पा रहे हैं।
समाधान: 22 नए "किचन असिस्टेंट्स"
डेवलपर्स केवल एक तेज़ रोबोट शेफ नहीं चाहते थे। वे बाकी काम संभालने के लिए 22 विशिष्ट प्रकार के AI सहायकों चाहते थे। उन्होंने इन्हें पांच श्रेणियों में बांटा:
1. "टेक डेट जेनिटर" (विकास/Development)
- समस्या: पुराने कोडबेस पुराने घरों की तरह होते हैं जिनमें फर्श चरमराता है और वायरिंग पुरानी है। हर कोई जानता है कि इसे ठीक करने की जरूरत है, लेकिन कोई इसे करना नहीं चाहता क्योंकि यह उबाऊ और जोखिम भरा है।
- AI की इच्छा: एक रोबमान जो पुराने कोड को सुरक्षित रूप से साफ कर सके, डिपेंडेंसी को ठीक कर सके और लाइब्रेरी को अपडेट कर सके, लेकिन केवल तभी जब वह पहले अनुमति मांगे और गलती से दीवार न गिरा दे।
- शर्त: अगर वह भ्रमित हो जाए, तो उसे रुक जाना चाहिए। वह जटिल समस्या को हल करने के लिए केवल "अंदाजा" नहीं लगा सकता।
2. "आर्किटेक्ट का सहायक" (डिजाइन और योजना/Design & Planning)
- समस्या: एक नया सिस्टम डिजाइन करना एक गगनचुंबी इमारत की योजना बनाने जैसा है। आपको ट्रैफिक फ्लो, सुरक्षा और भविष्य के विस्तार के बारे बारे में सोचना पड़ता है।
- AI की इच्छा: एक टूल जो विभिन्न बिल्डिंग डिजाइनों पर विचार मंथन (brainstorm) कर सके, संभावित कमजोरियों की ओर इशारा कर सके और टू-डू लिस्ट को व्यवस्थित कर सके।
- शर्त: AI सुझाव दे सकता है, लेकिन वह अंतिम निर्णय नहीं ले सकता। मानव आर्किटेक्ट को ही बॉस बने रहना चाहिए। AI को केवल पुराने डिजाइनों को कॉपी-पेस्ट नहीं करना चाहिए; उसे इस विशिष्ट इमारत के संदर्भ (context) को समझना होगा।
3. "सुरक्षा निरीक्षक" (गुणवत्ता और जोखिम/Quality & Risk)
- समस्या: जब आप कोड शिप करते हैं, तो आपको सुनिश्चित करना होता है कि उसमें बग या सुरक्षा खामियां न हों। वर्तमान में, यह कोड लिखे जाने के बाद होता है, जो कि बहुत देर हो चुकी होती है।
- AI की इच्छा: एक निरीक्षक जो कोड लिखते समय ही उसकी जांच करे। उसे कहना चाहिए, "हे, आप इस हिस्से के लिए एक टेस्ट भूल गए हैं," या "यह सुरक्षा जोखिम लग रहा है।"
- शर्त: AI समस्याओं को चिह्नित कर सकता है, लेकिन वह रिलीज के लिए कोड को अनुमोदित (approve) नहीं कर सकता। एक इंसान को हमेशा हस्ताक्षर करने होंगे।
4. "इन्फ्रास्ट्रक्चर बटलर" (संचालन/Operations)
- समस्या: सर्वर चलाना एक जटिल इलेक्ट्रिकल ग्रिड को प्रबंधित करने जैसा है। जब रात के 3 बजे अलार्म बजता है, तो आपको तुरंत पता होना चाहिए कि क्यों।
- AI की इच्छा: एक टूल जो सभी लॉग्स, ट्रेसेस और इतिहास को इकट्ठा करे और आपको बताए, "सर्वर इसलिए क्रैश हुआ क्योंकि यह विशिष्ट बदलाव हुआ था," ताकि आप इसे जल्दी ठीक कर सकें।
- शर्त: AI डेटा देख सकता है, लेकिन वह चीजों को ठीक करने के लिए लाइव सर्वर को छू नहीं सकता। वह बिना इंसान द्वारा बटन दबाए इंजन को रीस्टार्ट नहीं कर सकता।
5. "ज्ञान संरक्षक" (मेटा-वर्क/Knowledge Keeper)
- समस्या: डॉक्यूमेंटेशन हमेशा पुराना रहता है। नए कर्मचारी यह समझने में हफ्तों बिता देते हैं कि चीजें कैसे काम करती हैं क्योंकि मैनुअल गलत होते हैं।
- AI की इच्छा: एक टूल जो कोड बदलने पर मैनुअल को स्वचालित रूप से अपडेट करे, नए कर्मचारियों के लिए व्यक्तिगत प्रशिक्षण योजनाएं बनाए, और बॉस को पेशेवर लेकिन रोबोटिक नहीं लगने वाले ईमेल लिखने में मदद करे।
- शर्त: AI ईमेल या मैनुअल का ड्राफ्ट तैयार कर सकता है, लेकिन भेजने से पहले एक इंसान को उसे पढ़ना और अनुमोदित करना होगा। वह अपने आप ग्राहकों से बात नहीं कर सकता।
स्वर्णिम नियम: "बाउंडेड डेलिगेशन" (Bounded Delegation)
इस पेपर का सबसे महत्वपूर्ण निष्कर्ष एक अवधारणा है जिसे लेखकों ने "बाउंडेड डेलिगेशन" कहा है।
इसे एक बहुत ही बुद्धिमान इंटर्न को काम पर रखने की तरह समझें।
- आप चाहते हैं कि इंटर्न करे: फाइलिंग, डेटा एंट्री, रिसर्च, फॉर्मेटिंग, ड्राफ्टिंग। (असेंबली वर्क)।
- आप कभी नहीं चाहते कि इंटर्न करे: अंतिम निर्णय, चेक पर हस्ताक्षर करना, नैतिक निर्णय, या रचनात्मक स्पार्क। (क्राफ्ट/कौशल का काम)।
डेवलपर्स कह रहे हैं: "हम चाहते हैं कि AI भारी काम संभाले, लेकिन हम स्टीयरिंग व्हील अपने हाथ में रखना चाहते हैं।"
वे नहीं चाहते कि AI उनके इंजीनियर होने की पहचान को बदल दे। वे चाहते हैं कि AI उबाऊ, दोहराव वाले हिस्सों को संभाल ले ताकि वे उच्च-स्तरीय समस्या समाधान पर ध्यान केंद्रित कर सकें।
चार "गार्डरेल्स" (Four Guardrails)
इन 22 AI सिस्टमों में से किसी के लिए भी स्वीकार्य होने के लिए, डेवलपर्स ने कहा कि उन्हें चार सख्त नियमों का पालन करना चाहिए:
- अपनी सीमाएं जानें: यदि AI को उत्तर नहीं पता है, तो उसे कुछ भी मनगढ़ंत बनाने के बजाय "मुझे नहीं पता" कहना चाहिए।
- अपना काम दिखाएं: AI को दिखाना चाहिए कि उसने अपनी जानकारी कहाँ से प्राप्त की (provenance)। कोई जादुई उत्तर नहीं।
- पहले पूछें: वह बस चीजें बदल नहीं सकता। कोई भी कदम उठाने से पहले उसे अनुमति मांगनी होगी।
- न्यूनतम विशेषाधिकार (Least Privilege): उसके पास केवल उसी विशिष्ट डेटा तक पहुंच होनी चाहिए जिसकी उसे आवश्यकता है, उससे अधिक नहीं। पेन लेने के लिए तिजोरी नहीं खोलनी चाहिए।
निचोड़ (The Bottom Line)
यह पेपर एक चेतावनी है। हम AI को कोड तेजी से लिखने के लिए बनाने के प्रति जुनूनी रहे हैं। लेकिन सॉफ्टवेयर इंजीनियरिंग में AI का वास्तविक मूल्य इस बात में नहीं है कि वह कितना कोड उत्पन्न कर सकता है। यह इस बारे में है कि वह कहाँ रुकता है।
सबसे अच्छे AI टूल्स वे नहीं होंगे जो डेवलपर्स की जगह लेंगे। वे वे होंगे जो डेवलपर्स को बर्नआउट से बचाएंगे, उन्हें उनके काम को सत्यापित करने में मदद करेंगे, और उन्हें उन हिस्सों पर ध्यान केंद्रित करने देंगे जो उन्हें एक कुशल पेशेवर महसूस कराते हैं।
संक्षेप में: हमें ऐसे रोबोट की जरूरत नहीं है जो हमारे लिए भोजन पकाए। हमें ऐसे रोबोट की जरूरत है जो बर्तन धो सके, ताकि हम भोजन का आनंद ले सकें।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।