सॉफ़्टवेयर डेवलपमेंट के भविष्य पर विचार

• बड़े language models (LLMs) इमेज, टेक्स्ट और कोड जनरेट करने में सक्षम हो गए हैं, जिससे रचनात्मक क्षेत्रों में बड़ा असर पड़ा है
• शुरुआत में इंसानों के हाथ गलत बने हुए चित्र, गलत तथ्यों वाले जवाब जैसी कई मज़ेदार आउटपुट मिलती थीं, लेकिन ये धीरे-धीरे बेहतर हो रहे हैं
• इन मॉडलों के आने से पहले, मशीनें रचनात्मक ढंग से सोच नहीं सकतीं — यह automation के खिलाफ मुख्य तर्कों में से एक था, लेकिन अब यह दावा धीरे-धीरे कमजोर पड़ रहा है
• अब हमें किस दिशा में जाना चाहिए?

Framework: सॉफ़्टवेयर डेवलपमेंट क्षमता के स्तर

• सॉफ़्टवेयर डेवलपमेंट सिर्फ कोड लिखना नहीं है
• प्रोग्रामर की छवि अक्सर एक अंधेरे कमरे में कंप्यूटर स्क्रीन को देखते हुए तेजी से कोड टाइप करने वाले व्यक्ति की होती है, लेकिन वास्तव में कोड लिखने की तुलना में दूसरे कामों पर अधिक समय जाता है
  • बिज़नेस यूज़र्स से requirements इकट्ठा करना
  • requirements को इस तरह refine करना कि उन्हें कोड में model किया जा सके
  • designers, product managers जैसे टीम सदस्यों के साथ solution की कल्पना और planning करना
  • दूसरे developers के साथ technical design और refinement करना
  • infrastructure setup, configuration, boilerplate आदि
  • वास्तविक कोड लिखना
  • debugging, दूसरों के कोड को समझना, documentation लिखना आदि
  • production deployment
  • production issues को संभालना
  • और भी कई काम
• "AI डेवलपर्स की जगह ले लेगा" का मतलब है कि AI को ऊपर दिए गए सभी कामों में दक्ष होना होगा
• लेकिन ऊपर की सूची देखें तो इनमें से कुछ काम भविष्य में automate हो सकते हैं, पर कुछ अभी भी ऐसे लगते हैं जिन्हें automate करना आसान नहीं है

self-driving cars में automation levels का वर्गीकरण

• self-driving cars के क्षेत्र ने automation levels को वर्गीकृत करने का एक तरीका विकसित किया
• यह वर्गीकरण साफ़ तौर पर बताता है कि मौजूदा तकनीक क्या कर सकती है, और काला-सफेद जैसी सोच से बचाता है
• अगर इस वर्गीकरण को AI-आधारित सॉफ़्टवेयर डेवलपमेंट पर लागू करें
  • सबसे निचला स्तर वह है जो पहले हमारे पास था, यानी वह चरण जहाँ काम में AI शामिल नहीं है. बेशक compiler, build process जैसी दूसरी तरह की automation मौजूद थी, लेकिन वह AI नहीं बल्कि इंसानों द्वारा लिखी गई deterministic automation थी
  • उसके बाद वाला स्तर वही है जो अभी हमारे पास है
    • developers, ChatGPT या GitHub Copilot का इस्तेमाल सहायता के लिए करते हैं
    • developers इसका उपयोग tests लिखने, boilerplate code, refactoring, और code/errors को समझने के लिए करते हैं
    • chat के ज़रिए यह किसी सहकर्मी developer की तरह सवालों के जवाब दे सकता है और मदद कर सकता है, लेकिन क्योंकि इसके पास कंप्यूटर access नहीं है, यह files नहीं बना सकता, build commands नहीं चला सकता, या production में deploy नहीं कर सकता
  • सबसे ऊँचा स्तर वह है जहाँ किसी project का कुछ हिस्सा या पूरा हिस्सा एक "AI coder" को सौंप दिया जाए
    • AI coder requirements लेकर कोड लिखे, errors ठीक करे, और अंतिम product को production में deploy करे
    • पहले लगता था कि ऐसा होने में अभी कुछ महीने और लगेंगे, लेकिन Devin demo ने दिखाया कि भले ही अभी यह सिर्फ सरल development tasks कर सकता है, आगे इसमें सुधार की संभावना है Devin, पहला AI software engineer
• AI model की क्षमता के अलावा, यह भी सोचना होगा कि solution कितना सटीक है
  • ये models hallucination के प्रति संवेदनशील होते हैं या मनचाहा परिणाम पाने के लिए इन्हें खास तरह से prompt करना पड़ता है
  • इससे adoption में friction पैदा होती है और अधिकतर लोग इसी चरण में AI assistants को छोड़ देते हैं
  • लेकिन इसमें भी सुधार हो रहा है, और नए models में इस स्तर की prompt engineering की ज़रूरत नहीं पड़ती
• साथ ही, models को सिर्फ training data पर निर्भर रहने के बजाय वेब ब्राउज़ करके 'सीख' पाने में सक्षम होना चाहिए
  • यह इसलिए महत्वपूर्ण है क्योंकि libraries और programming languages के नए versions लगातार आते रहते हैं

Framework: outsourced सॉफ़्टवेयर डेवलपमेंट

• अब जब capability का ढांचा तैयार हो गया है, तो इसका team या organization structure पर क्या असर पड़ेगा? कंपनियाँ अलग-अलग तरीकों से सॉफ़्टवेयर डेवलपमेंट करती हैं:
  • पूरी तरह in-house
  • कुछ vendors के साथ ज़्यादातर in-house
  • कई vendors के साथ थोड़ा in-house
  • पूरी तरह vendor-आधारित
• AI coder को outsourced software vendor/consultant की तरह सोचा जा सकता है
• यह ज़रूरी है कि कंपनी की internal team vendor के काम की निगरानी करे
  • contracts के ज़रिए इस समस्या को हल किया जा सकता है, लेकिन contracts आमतौर पर किसी खास supplier या project पर ही लागू होते हैं, और इस तरीके से लंबे समय के goals को लागू नहीं कराया जा सकता
  • vendor को दिशा दे सकने वाली एक छोटी internal team भी होना बेहतर है
  • उसी तरह, अगर EC2 instance की तरह AI coders को किराए पर लिया जा सके, तब भी software developers की internal team द्वारा काम की निगरानी करना फायदेमंद होगा

Framework: सॉफ़्टवेयर डेवलपमेंट जटिलता का modeling है

• जब हम business problems को हल करने की बात करते हैं, तो Excel एक अच्छा उदाहरण है
• Excel की entry barrier बहुत कम है, इसलिए इससे data organize किया जा सकता है, data analysis किया जा सकता है, या कुछ processes automate की जा सकती हैं
• लेकिन granular access control, unsupported systems के साथ integration, testability, reusability, vendor lock-in जैसी बातों के कारण यह जटिल business workflows के लिए उपयुक्त नहीं है
• Power Automate जैसी "low-code" solutions के साथ भी यही बात लागू होती है
• "क्या business users software developers की मदद के बिना AI coder का उपयोग करके ऐसे जटिल workflows बना सकेंगे?"
• अगर सोचें, तो Excel और low-code tools दशकों से मौजूद हैं, फिर भी software development एक पेशे के रूप में अब तक क्यों मौजूद है?
• इसकी वजह यह है कि हम software development को सिर्फ कोड लिखना मान लेते हैं
• जटिल समस्याओं के लिए ऐसे लोगों की ज़रूरत होती है जो इस जटिलता को प्रभावी ढंग से manage कर सकें और business problems को वास्तविक domain से digital model में बदल सकें
• दूसरे शब्दों में, सिर्फ इसलिए कि आप civil engineer की मदद के बिना YouTube tutorials देखकर एक लकड़ी का शेड बना सकते हैं, इसका मतलब यह नहीं कि आप 10-मंज़िला इमारत भी उसी तरह बना सकते हैं, या बनानी चाहिए
  • अगर आप यह काम सही तरीके से करना सीखते हैं, तो धीरे-धीरे आप खुद civil engineer बन सकते हैं
  • सवाल सिर्फ इतना है कि क्या आप सही ढंग से सीखने में समय लगाएंगे, या एक skilled engineer को hire करेंगे
• इसलिए चाहे आप Excel इस्तेमाल करें या नवीनतम AI coder, अगर आप complex logic को model कर रहे हैं, तो आप अब भी software developer ही हैं
• फर्क सिर्फ इतना है कि business requirements को व्यक्त करने के लिए tools अलग हैं — spreadsheet formulas, code, prompts आदि

Framework: pie का आकार

• इस विषय को लेकर ज़्यादातर चिंता इस धारणा पर आधारित है कि software development market का आकार स्थिर रहेगा, यानी AI coders धीरे-धीरे इंसानों से 'market share' छीन लेंगे
• लेकिन "business problem solving" market का आकार software development से कहीं बड़ा है, इसलिए software development इतनी जल्दी खत्म नहीं होने वाला

Framework: formal business logic definition

• business logic को हमेशा एक स्पष्ट formal रूप में परिभाषित किया जाना चाहिए
• इसी वजह से programming languages, 'if', 'switch' जैसे अंग्रेज़ी शब्दों का उपयोग करने के बावजूद, उनके अर्थ को बहुत सख्ती से परिभाषित करती हैं, और अगर गलत शब्द इस्तेमाल हो जाएँ तो वे काम नहीं करतीं. सोचें तो Excel formulas और low-code flows पर भी यही बात लागू होती है
• भविष्य में, भले ही AI coder conversational English में दिए गए instructions के आधार पर software products बना सके, फिर भी backend में बनने वाले business logic की एक बुनियादी formal definition मौजूद रहेगी
• यह आज की languages या frameworks से बहुत अलग दिख सकती है, लेकिन business logic की formal definition सुनने में अब भी 'code' जैसी ही लगती है
• जब तक AI coder इस business logic को deterministic तरीके से conversational English से generate नहीं कर सकता, तब तक backend में generated code को समझने और ज़रूरत पड़ने पर बदलने वाले लोगों की ज़रूरत रहेगी — यही software developers हैं

निष्कर्ष

• काम की प्रकृति बदल जाएगी और जिन tools का हम उपयोग करते हैं वे आज से बहुत अलग होंगे, लेकिन निकट भविष्य में software developers के लिए market फिर भी मौजूद रहेगा

[xguru]

Devin, पहला AI software engineer
OpenDevin - AI software engineer Devin का open source implementation

[dhlee0305]

जब तक OpenAI मशहूर नहीं हुआ था, तब तक कला जैसे क्षेत्र को भी AI अपनाने में सबसे देर से आने वाला या शायद असंभव माना जाता था; लेकिन अब AI को अपने दायरे का विस्तार करते हुए देखकर अचानक यह विचार आया कि जिन चीज़ों को आज हम केवल 'इंसान' ही कर सकता है मानते हैं, वे शायद 'सुरक्षित' नहीं हैं।

[edunga1]

मुख्य लेख और https://hi.news.hada.io/topic?id=13557 वाली पोस्ट की तरह,
क्या अब डेवलपरों का हिस्सा निश्चित रूप से घटेगा, और यह और तेज़ी से होगा?

[ahwjdekf]

जैसे-जैसे AI prompt की अहमियत दिन-ब-दिन अधिक उभर रही है, वैसे-वैसे अधिक से अधिक users यह समझेंगे कि अधिक स्पष्ट spec definition और requirements की व्यवस्थित रूपरेखा बनाना अनिवार्य है, और अंततः यह भविष्य में developers के काम करने के लिए अनुकूल दिशा में काम कर सकता है।

[colus001]

कोड इंसानों के लिए होता है, और अगर मशीन कोड लिखती है तो इसका मतलब है कि इंसान की ज़रूरत फिर भी बनी रहती है, इसलिए मुझे नहीं लगता कि यह बहुत दूर भविष्य की विकास-दिशा है। मुझे लगता है कि शुरुआत में प्रयोग किए गए backend-GPT (https://github.com/RootbeerComputer/backend-GPT) की तरह, हम जिस तरह के किसी ब्लैक बॉक्स में अपना मनचाहा प्रश्न डालें, वह DB तक पहुँचकर डेटा प्रोसेस करे, और उसके आगे-पीछे के अनुभव में इंसान आंशिक रूप से हस्तक्षेप करे—इसी रूप में विकास होगा।

[kaistj]

लगता है कि chat GPT और Copilot के बारे में बहुत चर्चा होने वाले पहलुओं में prompt engineering का भी ज़िक्र आता है। मेरा मानना है कि जो प्रक्रियाएँ हम आम तौर पर programming के लिए मीटिंग करके, बातों के ज़रिए तेज़ी से संचार कर, उन्हें व्यवस्थित करके और पुष्टि करके पूरी करते हैं, उन्हें AI coder तक कुशलता से कैसे पहुँचाया जाए और उसके साथ प्रभावी ढंग से कैसे संवाद किया जाए, यह भी एक महत्वपूर्ण तत्व है ^^.

[vbmania]

> "AI डेवलपर्स की जगह ले लेगा" इस बात का मतलब है कि AI को ऊपर बताए गए सभी कामों में दक्ष होना चाहिए

-> हो सकता है कि ये प्रक्रियाएँ सिर्फ इसलिए ज़रूरी हों क्योंकि इंसान काम कर रहा है, और आखिरकार जब इन सभी प्रक्रियाओं से गुज़रते हैं, तो मुझे लगता है कि नतीजे में मिलने वाले कोड में एक खास पैटर्न हो सकता है। जैसे Go में भी opening moves या standard patterns जैसी चीज़ों को ज़रूरी माना जाता था, लेकिन बाद में यह सामने आया कि वह सिर्फ इंसानी संज्ञान की सीमा के भीतर जानकारी को प्रोसेस करने का एक अपरिहार्य तरीका था।