AI-सहायता प्राप्त कोडिंग software engineering को कैसे बदलेगी: असहज सच्चाई

xguru · 2025-01-13T10:44:02+09:00

GenAI(LLM) कोड अपने-आप जनरेट करने और सहायता देने की क्षमता के जरिए डेवलपर्स की उत्पादकता बढ़ा रहा है पहले भी “कोडिंग की ज़रूरत नहीं” वाले टूल्स मौजूद थे, लेकिन वास्तविक software engineering प्रक्रिया में अब भी अपनी अलग जटिलता बनी रहती है ChatGPT के लॉन्च के बाद AI टूल्स की तेज़ प्रगति साफ़ दिखती है, लेकिन यह हर प्रक्रिया को क्रांतिकारी रूप से बदलने के बजाय दिए गए समस्या-क्षेत्र में कुछ चरणों को बहुत छोटा करने का काम कर रहा है डेवलपर्स के वास्तविक उपयोग के तरीके दो धाराओं में बंट रहे हैं bootstrappers Bolt, v0, Screenshot-to-code जैसे टूल्स से नए प्रोजेक्ट या MVP को तेज़ी से लागू करते हैं design (Figma आदि) या rough concept से AI पूरा शुरुआती codebase जनरेट कर देता है कुछ दिनों की बजाय कुछ घंटों में काम करने वाला prototype बना लेते हैं production स्तर पर यह अधूरा हो सकता है, लेकिन idea validation में इसकी ताकत है तेज़ validation और iteration को महत्व देते हैं iterators Cursor, Cline, Copilot, WindSurf आदि को रोज़मर्रा के development workflow में इस्तेमाल करते हैं code autocomplete, जटिल refactoring, test और documentation generation जैसे कामों में AI का उपयोग करते हैं जटिल testing, documentation, refactoring आदि AI को सौंपते हैं, लेकिन परिणामों की लगातार जाँच करते रहते हैं इसे एक ‘pair programmer’ की तरह problem solving में साथ देने वाले टूल के रूप में इस्तेमाल करते हैं डेवलपर AI के सुझाव चुनते, संशोधित करते और बेहतर बनाते हुए optimal code तक पहुँचते हैं 70% समस्या: “आख़िरी 30%” की कठिनाई - AI की learning curve paradox AI लगभग 70% तक कोड तेज़ी से बना देता है, लेकिन आख़िरी 30% बड़ा अवरोध बन जाता है एक छोटा bug ठीक करने पर किसी दूसरे हिस्से के टूट जाने जैसा दुष्चक्र बन जाता है खासकर non-CS background वाले या junior लोग AI के सुझाए गए पूरे code को स्वीकार कर लेते हैं और इससे chained problems पैदा होने का खतरा बढ़ जाता है उनके लिए यह समझना मुश्किल होता है कि AI द्वारा सुझाए गए बदलाव समस्या क्यों पैदा कर रहे हैं अनुभवी senior डेवलपर bug के कारण का तेज़ी से अनुमान लगाते हैं, code को restructure करते हैं, और security व performance जैसे पहलुओं को जोड़कर AI की छूटी चीज़ें पूरी करते हैं वे AI का सक्रिय रूप से इस्तेमाल करते हुए भी लगातार review और refactor करके उसे “maintainable code” में बदलते हैं अगर junior या non-developer लोग AI द्वारा जनरेट किया गया code बिना सोचे-समझे अपना लें, तो वास्तविक production environment में आसानी से बिखर जाने वाला “house-of-cards code” बनने का जोखिम है ज्ञान का paradox senior लोग जिन समस्याओं को पहले से जानते हैं, उन्हें AI के साथ तेज़ी से लागू कर सकते हैं junior लोगों को AI के जरिए सीखना चाहिए, लेकिन बुनियादी ज्ञान कम होने पर debugging और verification में बड़ी मुश्किलें आती हैं प्रभावी उपयोग के पैटर्न AI draft के बाद refinement AI शुरुआती implementation कर दे, फिर इंसान खुद उसे review, refactor और test करे error handling और exception cases हाथ से जोड़े जाएँ, और automated testing व review process को मज़बूत कर भरोसेमंदी बढ़ाई जाए modularity, error handling, type definition, architecture design को बेहतर बनाकर code को maintainable बनाया जाए काम की इकाइयों के हिसाब से बातचीत बनाए रखें एक बार में बड़ा context देने के बजाय, छोटे-छोटे मुद्दों के लिए अलग prompts इस्तेमाल कर अधिक केंद्रित जवाब लें changes को बार-बार review और commit करें, और feedback को छोटे cycle में शामिल करें “trust but verify” वाला approach AI draft तैयार करे, लेकिन महत्वपूर्ण logic, error handling और security issues इंसान सीधे संभाले हमेशा test cases लिखें, और performance, security, structural validity आदि की सावधानी से जाँच करें डेवलपर्स के लिए संकेत छोटे से शुरू करें अच्छी तरह परिभाषित छोटे कामों और स्पष्ट दायरे वाली समस्याओं में पहले AI का उपयोग करें, और जनरेट किए गए code की बारीकी से जाँच करें बड़े feature पर जाने से पहले testing और documentation को अच्छी तरह पूरा करें, फिर धीरे-धीरे दायरा बढ़ाएँ modularity बनाए रखें codebase को ठीक से अलग रखें ताकि AI द्वारा बनाया गया code संरचनात्मक रूप से उलझकर न मिल जाए files और features को छोटे units में बाँटें और interfaces व dependency flow को स्पष्ट रूप से परिभाषित करें अनुभव पर भरोसा AI को सहायक की तरह इस्तेमाल करें, लेकिन अंतिम निर्णय अपने अनुभव के आधार पर लें संदिग्ध code या design पर सवाल उठाएँ, और engineering standards का पालन करना बेहतर है agentic software engineering का उभार अब तक AI टूल्स निर्देश के जवाब में code जनरेट करने के स्तर पर थे, लेकिन आगे यह agentic अवधारणा की ओर विकसित होंगे agentic AI खुद लक्ष्य की योजना बनाता है, उसे execute और verify करता है, और अधिक स्वायत्त रूप से काम करता है Claude(Anthropic), Cline आदि अब साधारण autocomplete से आगे बढ़कर browser अपने-आप खोलने और tests चलाने तक पहुँच चुके हैं debugging process भी बदलेगी agent खुद संभावित issues ढूँढ सकता है, test set चला सकता है, UI state तक जाँच सकता है और fix suggestions दे सकता है भविष्य के टूल्स सिर्फ code तक सीमित नहीं रहेंगे वे UI screenshots, diagrams, voice conversation जैसे कई input channels को समझ और एकीकृत कर सकेंगे इस प्रवाह में डेवलपर की भूमिका AI को रचनात्मक ढंग से काम करने देना, लेकिन उसे मानवीय guidance और sound architecture के भीतर काम करते रहने देना मानव और AI के बीच मज़बूत feedback loop बनाना यह उम्मीद की जा रही है कि इंसान बड़े ढाँचे और लक्ष्यों को तय करेगा, और agent बारीक काम संभालेगा “सबसे महत्वपूर्ण programming language English है” वाली बात की तरह, स्पष्ट और सटीक natural language में requirements व्यक्त करने की क्षमता और महत्वपूर्ण होगी क्या software craftsmanship वापस आएगा? AI की वजह से prototypes और demos बहुत तेज़ी से बनाए जा सकते हैं लेकिन जब वास्तविक users अलग-अलग environments और edge cases में software इस्तेमाल करना शुरू करते हैं, तब समस्याएँ सामने आती हैं users के लिए समझ से बाहर error messages crashes पैदा करने वाले special environments (edge cases) accessibility को बिल्कुल ध्यान में न रखकर किया गया design धीमे devices पर आने वाले performance issues UI/UX जैसी details ही quality तय करती हैं उपभोक्ता के नज़रिए से अच्छी तरह “polished” product बनने के लिए बारीकी और मानवीय संवेदनशीलता ज़रूरी है अगर AI दोहराए जाने वाले काम घटा दे, तो डेवलपर्स ऐसी सूक्ष्म quality पर ज़्यादा ध्यान दे सकते हैं user experience, edge cases, meaningful error handling जैसे मानवीय और पेशेवर क्षेत्रों में वे अधिक समय लगा सकते हैं अतिरिक्त विचार software engineering प्रक्रिया में planning, design, implementation, verification, monitoring, maintenance जैसे कई क्षेत्र शामिल होते हैं, और फिलहाल AI मुख्य रूप से “code लिखने” वाले हिस्से को बहुत अधिक efficient बना रहा है पहले भी COBOL, Visual Basic, No-code platforms आदि के जरिए “non-developers भी आसानी से software बना सकें” जैसी कोशिशें होती रही हैं, लेकिन जटिलता बढ़ने पर आखिरकार skilled developers की ज़रूरत पड़ी जितना LLM टूल्स code की मात्रा को विस्फोटक रूप से बढ़ाएँगे, उतनी ही complex projects में और अधिक senior engineers की ज़रूरत पड़ने की संभावना है AI का प्रभावी उपयोग जानने वाले skilled developers अपनी value और बढ़ा सकते हैं निष्कर्षतः AI tools डेवलपर्स को पूरी तरह replace करने के बजाय, insight और experience वाले डेवलपर्स को और अधिक ताकतवर बनाने की दिशा में विकसित होते दिखते हैं अतिरिक्त विचार (Gergely की टिप्पणियों सहित) software engineering में coding का हिस्सा पहले से ही इतना बड़ा नहीं था पहले Fred Brooks ने software work time को लगभग इस तरह बाँटा था ⅓ planning ⅙ coding ¼ component और system testing ¼ system testing (सभी components को हाथ से) मौजूदा नज़रिए से coding (testing सहित) का समय बढ़ा है, लेकिन planning, code review, monitoring, rollout आदि अब भी महत्वपूर्ण हिस्से हैं 20% planning 40% coding (code + tests) 20% code review (दूसरों के code का) 20% production readiness + rollout + इस दौरान छोटे fixes + monitoring + alerts software को अच्छी तरह बनाने की प्रक्रिया 1. What: क्या बनाना है, तय करना इसमें brainstorming, design, user testing, product managers और business stakeholders के साथ collaboration शामिल है startups में यह चरण बहुत छोटा हो सकता है (“बनाकर देखते हैं, फिर प्रतिक्रिया देखते हैं”) लेकिन अगर कंपनी पहले से स्थापित हो, तो मौजूदा customers को भ्रमित न करने के लिए क्या बनाना है यह तय करने में ज़्यादा समय लग सकता है 2. How: कैसे बनाना है, इसकी योजना product/feature/service को कैसे लागू करना है, इसकी ठोस design बनाई जाती है architecture impact, dependencies, testing strategy आदि पर विचार किया जाता है startups इस प्रक्रिया को छोड़कर सीधे execution में जा सकते हैं, लेकिन बड़े संगठनों में upfront design को नज़रअंदाज़ करने से बाद में बड़ी समस्याएँ हो सकती हैं अधिकतर teams Design doc, RFC, ADR आदि का उपयोग कर किसी-न-किसी स्तर की planning करती हैं 3. Build: वास्तविक implementation इच्छित feature या product को code में लिखकर उसके सही काम करने की पुष्टि की जाती है 4. Verify: सत्यापन production में deploy करने से पहले यह बारीकी से जाँचा जाता है कि चीज़ें अपेक्षा के अनुसार काम कर रही हैं या नहीं खासकर financial services जैसे क्षेत्रों में, जहाँ malfunction गंभीर नतीजे दे सकता है, QA प्रक्रिया बहुत सख़्ती से की जाती है 5. Ship it: release changes को merge करके customers तक release किया जाता है production deployment के तरीके अलग-अलग हो सकते हैं 6. Monitoring and oncall: monitoring और oncall product में कोई समस्या आए तो उसे तुरंत detect कर resolve किया जाता है वही incident दोबारा न हो, इसके लिए post-incident actions भी किए जाते हैं 7. Maintain: maintenance user complaints और feedback इकट्ठा कर यह तय किया जाता है कि कौन-से bugs ठीक करने हैं और किन feature improvements को priority देनी है इसमें ऐसे feedback को छाँटना भी शामिल है जिसे नज़रअंदाज़ किया जा सकता है 8. Migrate: migration जब product खुद काफ़ी बदल जाए या tech stack बदलना पड़े, तब बड़े migration की ज़रूरत हो सकती है AI tools फिलहाल “Build” चरण में बड़ी मदद देते हैं, लेकिन ऊपर बताए गए बाकी 7 हिस्सों में वे कितने उपयोगी होंगे, इस पर भी विचार करना होगा 1960 के दशक से “non-developers बिना developers के software बना सकें” वाला सपना चलता आया है COBOL, Visual Basic, No-code आदि इसके उदाहरण हैं साधारण websites तो बिना coding के भी बनाई जा सकती हैं, लेकिन complex products में engineering work अब भी ज़रूरी है अभिव्यक्ति की क्षमता जितनी बढ़ती है, उतना ही AI को विस्तार से यह बताना पड़ता है कि “यह कैसे काम करे”, और इसी के साथ complexity भी बढ़ती है AI जितना ज़्यादा code बनाएगा, उसे maintain करने और architecture संभालने वाले specialist engineers की ज़रूरत उतनी ही बढ़ सकती है आज LLM के साथ काम करना सीख चुके senior developers अधिक productive हो रहे हैं और कंपनियों में अधिक value पैदा कर सकते हैं AI agents: बड़ा वादा, लेकिन 2025 में अब भी ‘अनजान क्षेत्र’ LLM के लॉन्च के दो साल बाद, कई डेवलपर्स ने coding और software engineering में LLM का इस्तेमाल करना सीख लिया है prototyping, अनजान languages में switch करना, output की correctness verify करना और गलत जवाबों (hallucinations) को पकड़ना जैसे कामों में LLM ने बड़ी मदद की है लेकिन AI agents अभी शुरुआती चरण में हैं अभी आम तौर पर उपलब्ध agent लगभग Devin ही है, जिसकी कीमत 500 डॉलर प्रति माह है, और उस पर राय भी मिली-जुली है venture funding आने से और अधिक AI coding agent tools सामने आने की संभावना है कीमतें भी धीरे-धीरे कम हो सकती हैं GitHub Copilot 2025 में agent-based Copilot Workspace को आम उपयोगकर्ताओं के लिए उपलब्ध करा सकता है Stripe के पूर्व CTO द्वारा स्थापित /dev/agents जैसे टूल्स भी लॉन्च होने वाले हैं AI agents धीमे response time (“सोचने” की प्रक्रिया) और अधिक लागत स्वीकार कर बेहतर accuracy हासिल करने की कोशिश करते हैं व्यवहार में यह approach accuracy को कितना बढ़ाएगी, और किन engineering use cases में productivity में बड़ा सुधार लाएगी, यह अभी स्पष्ट नहीं है skilled software engineers की मांग बढ़ने की संभावना skilled (senior और उससे ऊपर) software engineers की ज़रूरत अभी से ज़्यादा हो सकती है वे AI tools को अधिक प्रभावी ढंग से चला सकते हैं, और जानते हैं कि “बेहतरीन output” कैसा दिखता है, इसलिए वे अधिक सटीक “निर्देश” दे सकते हैं जब गलत code generation दिखे, तो वे तय कर सकते हैं कि generation process रोककर किस बिंदु पर सीधे source code खुद ठीक करना चाहिए AI tools की मदद से बहुत अधिक code लिखा जाएगा, और अधिक लोग व कंपनियाँ अपने solutions बनाएँगी लेकिन जैसे-जैसे complexity बढ़ेगी, उसे नियंत्रण में रखने वाले skilled engineers की ज़रूरत भी बढ़ेगी मौजूदा tech कंपनियों को भी AI के कारण बढ़ती complexity संभालने के लिए अतिरिक्त लोगों की ज़रूरत पड़ सकती है अगर software engineers AI के साथ काम करने की क्षमता विकसित करें, तो वे अधिक productive और अधिक valuable engineer बन सकते हैं tools को पूरी तरह “काबू” में लेना सीखने में समय लगता है, इसलिए तेज़ी से बदलते tool environment में सक्रिय रूप से experiment और learning करना महत्वपूर्ण है

(newsletter.pragmaticengineer.com)

76 पॉइंट द्वारा xguru 2025-01-13 | 11 टिप्पणियां | WhatsApp पर शेयर करें

GenAI(LLM) कोड अपने-आप जनरेट करने और सहायता देने की क्षमता के जरिए डेवलपर्स की उत्पादकता बढ़ा रहा है
पहले भी “कोडिंग की ज़रूरत नहीं” वाले टूल्स मौजूद थे, लेकिन वास्तविक software engineering प्रक्रिया में अब भी अपनी अलग जटिलता बनी रहती है
ChatGPT के लॉन्च के बाद AI टूल्स की तेज़ प्रगति साफ़ दिखती है, लेकिन यह हर प्रक्रिया को क्रांतिकारी रूप से बदलने के बजाय दिए गए समस्या-क्षेत्र में कुछ चरणों को बहुत छोटा करने का काम कर रहा है

डेवलपर्स के वास्तविक उपयोग के तरीके दो धाराओं में बंट रहे हैं

bootstrappers
- Bolt, v0, Screenshot-to-code जैसे टूल्स से नए प्रोजेक्ट या MVP को तेज़ी से लागू करते हैं
- design (Figma आदि) या rough concept से AI पूरा शुरुआती codebase जनरेट कर देता है
- कुछ दिनों की बजाय कुछ घंटों में काम करने वाला prototype बना लेते हैं
- production स्तर पर यह अधूरा हो सकता है, लेकिन idea validation में इसकी ताकत है
- तेज़ validation और iteration को महत्व देते हैं
iterators
- Cursor, Cline, Copilot, WindSurf आदि को रोज़मर्रा के development workflow में इस्तेमाल करते हैं
- code autocomplete, जटिल refactoring, test और documentation generation जैसे कामों में AI का उपयोग करते हैं
- जटिल testing, documentation, refactoring आदि AI को सौंपते हैं, लेकिन परिणामों की लगातार जाँच करते रहते हैं
- इसे एक ‘pair programmer’ की तरह problem solving में साथ देने वाले टूल के रूप में इस्तेमाल करते हैं
- डेवलपर AI के सुझाव चुनते, संशोधित करते और बेहतर बनाते हुए optimal code तक पहुँचते हैं

70% समस्या: “आख़िरी 30%” की कठिनाई - AI की learning curve paradox

AI लगभग 70% तक कोड तेज़ी से बना देता है, लेकिन आख़िरी 30% बड़ा अवरोध बन जाता है
एक छोटा bug ठीक करने पर किसी दूसरे हिस्से के टूट जाने जैसा दुष्चक्र बन जाता है
खासकर non-CS background वाले या junior लोग AI के सुझाए गए पूरे code को स्वीकार कर लेते हैं और इससे chained problems पैदा होने का खतरा बढ़ जाता है
- उनके लिए यह समझना मुश्किल होता है कि AI द्वारा सुझाए गए बदलाव समस्या क्यों पैदा कर रहे हैं
अनुभवी senior डेवलपर bug के कारण का तेज़ी से अनुमान लगाते हैं, code को restructure करते हैं, और security व performance जैसे पहलुओं को जोड़कर AI की छूटी चीज़ें पूरी करते हैं
- वे AI का सक्रिय रूप से इस्तेमाल करते हुए भी लगातार review और refactor करके उसे “maintainable code” में बदलते हैं
अगर junior या non-developer लोग AI द्वारा जनरेट किया गया code बिना सोचे-समझे अपना लें, तो वास्तविक production environment में आसानी से बिखर जाने वाला “house-of-cards code” बनने का जोखिम है
ज्ञान का paradox
- senior लोग जिन समस्याओं को पहले से जानते हैं, उन्हें AI के साथ तेज़ी से लागू कर सकते हैं
- junior लोगों को AI के जरिए सीखना चाहिए, लेकिन बुनियादी ज्ञान कम होने पर debugging और verification में बड़ी मुश्किलें आती हैं

प्रभावी उपयोग के पैटर्न

AI draft के बाद refinement
- AI शुरुआती implementation कर दे, फिर इंसान खुद उसे review, refactor और test करे
- error handling और exception cases हाथ से जोड़े जाएँ, और automated testing व review process को मज़बूत कर भरोसेमंदी बढ़ाई जाए
- modularity, error handling, type definition, architecture design को बेहतर बनाकर code को maintainable बनाया जाए
काम की इकाइयों के हिसाब से बातचीत बनाए रखें
- एक बार में बड़ा context देने के बजाय, छोटे-छोटे मुद्दों के लिए अलग prompts इस्तेमाल कर अधिक केंद्रित जवाब लें
- changes को बार-बार review और commit करें, और feedback को छोटे cycle में शामिल करें
“trust but verify” वाला approach
- AI draft तैयार करे, लेकिन महत्वपूर्ण logic, error handling और security issues इंसान सीधे संभाले
- हमेशा test cases लिखें, और performance, security, structural validity आदि की सावधानी से जाँच करें

डेवलपर्स के लिए संकेत

छोटे से शुरू करें
- अच्छी तरह परिभाषित छोटे कामों और स्पष्ट दायरे वाली समस्याओं में पहले AI का उपयोग करें, और जनरेट किए गए code की बारीकी से जाँच करें
- बड़े feature पर जाने से पहले testing और documentation को अच्छी तरह पूरा करें, फिर धीरे-धीरे दायरा बढ़ाएँ
modularity बनाए रखें
- codebase को ठीक से अलग रखें ताकि AI द्वारा बनाया गया code संरचनात्मक रूप से उलझकर न मिल जाए
- files और features को छोटे units में बाँटें और interfaces व dependency flow को स्पष्ट रूप से परिभाषित करें
अनुभव पर भरोसा
- AI को सहायक की तरह इस्तेमाल करें, लेकिन अंतिम निर्णय अपने अनुभव के आधार पर लें
- संदिग्ध code या design पर सवाल उठाएँ, और engineering standards का पालन करना बेहतर है

agentic software engineering का उभार

अब तक AI टूल्स निर्देश के जवाब में code जनरेट करने के स्तर पर थे, लेकिन आगे यह agentic अवधारणा की ओर विकसित होंगे
- agentic AI खुद लक्ष्य की योजना बनाता है, उसे execute और verify करता है, और अधिक स्वायत्त रूप से काम करता है
Claude(Anthropic), Cline आदि अब साधारण autocomplete से आगे बढ़कर browser अपने-आप खोलने और tests चलाने तक पहुँच चुके हैं
debugging process भी बदलेगी
- agent खुद संभावित issues ढूँढ सकता है, test set चला सकता है, UI state तक जाँच सकता है और fix suggestions दे सकता है
भविष्य के टूल्स सिर्फ code तक सीमित नहीं रहेंगे
- वे UI screenshots, diagrams, voice conversation जैसे कई input channels को समझ और एकीकृत कर सकेंगे
इस प्रवाह में डेवलपर की भूमिका
- AI को रचनात्मक ढंग से काम करने देना, लेकिन उसे मानवीय guidance और sound architecture के भीतर काम करते रहने देना
- मानव और AI के बीच मज़बूत feedback loop बनाना
यह उम्मीद की जा रही है कि इंसान बड़े ढाँचे और लक्ष्यों को तय करेगा, और agent बारीक काम संभालेगा
“सबसे महत्वपूर्ण programming language English है” वाली बात की तरह, स्पष्ट और सटीक natural language में requirements व्यक्त करने की क्षमता और महत्वपूर्ण होगी

क्या software craftsmanship वापस आएगा?

AI की वजह से prototypes और demos बहुत तेज़ी से बनाए जा सकते हैं
लेकिन जब वास्तविक users अलग-अलग environments और edge cases में software इस्तेमाल करना शुरू करते हैं, तब समस्याएँ सामने आती हैं
- users के लिए समझ से बाहर error messages
- crashes पैदा करने वाले special environments (edge cases)
- accessibility को बिल्कुल ध्यान में न रखकर किया गया design
- धीमे devices पर आने वाले performance issues
- UI/UX जैसी details ही quality तय करती हैं
उपभोक्ता के नज़रिए से अच्छी तरह “polished” product बनने के लिए बारीकी और मानवीय संवेदनशीलता ज़रूरी है
अगर AI दोहराए जाने वाले काम घटा दे, तो डेवलपर्स ऐसी सूक्ष्म quality पर ज़्यादा ध्यान दे सकते हैं
- user experience, edge cases, meaningful error handling जैसे मानवीय और पेशेवर क्षेत्रों में वे अधिक समय लगा सकते हैं

अतिरिक्त विचार

software engineering प्रक्रिया में planning, design, implementation, verification, monitoring, maintenance जैसे कई क्षेत्र शामिल होते हैं, और फिलहाल AI मुख्य रूप से “code लिखने” वाले हिस्से को बहुत अधिक efficient बना रहा है
पहले भी COBOL, Visual Basic, No-code platforms आदि के जरिए “non-developers भी आसानी से software बना सकें” जैसी कोशिशें होती रही हैं, लेकिन जटिलता बढ़ने पर आखिरकार skilled developers की ज़रूरत पड़ी
जितना LLM टूल्स code की मात्रा को विस्फोटक रूप से बढ़ाएँगे, उतनी ही complex projects में और अधिक senior engineers की ज़रूरत पड़ने की संभावना है
AI का प्रभावी उपयोग जानने वाले skilled developers अपनी value और बढ़ा सकते हैं
निष्कर्षतः AI tools डेवलपर्स को पूरी तरह replace करने के बजाय, insight और experience वाले डेवलपर्स को और अधिक ताकतवर बनाने की दिशा में विकसित होते दिखते हैं

अतिरिक्त विचार (Gergely की टिप्पणियों सहित)

software engineering में coding का हिस्सा पहले से ही इतना बड़ा नहीं था
पहले Fred Brooks ने software work time को लगभग इस तरह बाँटा था
- ⅓ planning
- ⅙ coding
- ¼ component और system testing
- ¼ system testing (सभी components को हाथ से)
मौजूदा नज़रिए से coding (testing सहित) का समय बढ़ा है, लेकिन planning, code review, monitoring, rollout आदि अब भी महत्वपूर्ण हिस्से हैं
- 20% planning
- 40% coding (code + tests)
- 20% code review (दूसरों के code का)
- 20% production readiness + rollout + इस दौरान छोटे fixes + monitoring + alerts
software को अच्छी तरह बनाने की प्रक्रिया
- 1. What: क्या बनाना है, तय करना
  - इसमें brainstorming, design, user testing, product managers और business stakeholders के साथ collaboration शामिल है
  - startups में यह चरण बहुत छोटा हो सकता है (“बनाकर देखते हैं, फिर प्रतिक्रिया देखते हैं”)
  - लेकिन अगर कंपनी पहले से स्थापित हो, तो मौजूदा customers को भ्रमित न करने के लिए क्या बनाना है यह तय करने में ज़्यादा समय लग सकता है
- 2. How: कैसे बनाना है, इसकी योजना
  - product/feature/service को कैसे लागू करना है, इसकी ठोस design बनाई जाती है
  - architecture impact, dependencies, testing strategy आदि पर विचार किया जाता है
  - startups इस प्रक्रिया को छोड़कर सीधे execution में जा सकते हैं, लेकिन बड़े संगठनों में upfront design को नज़रअंदाज़ करने से बाद में बड़ी समस्याएँ हो सकती हैं
  - अधिकतर teams Design doc, RFC, ADR आदि का उपयोग कर किसी-न-किसी स्तर की planning करती हैं
- 3. Build: वास्तविक implementation
  - इच्छित feature या product को code में लिखकर उसके सही काम करने की पुष्टि की जाती है
- 4. Verify: सत्यापन
  - production में deploy करने से पहले यह बारीकी से जाँचा जाता है कि चीज़ें अपेक्षा के अनुसार काम कर रही हैं या नहीं
  - खासकर financial services जैसे क्षेत्रों में, जहाँ malfunction गंभीर नतीजे दे सकता है, QA प्रक्रिया बहुत सख़्ती से की जाती है
- 5. Ship it: release
  - changes को merge करके customers तक release किया जाता है
  - production deployment के तरीके अलग-अलग हो सकते हैं
- 6. Monitoring and oncall: monitoring और oncall
  - product में कोई समस्या आए तो उसे तुरंत detect कर resolve किया जाता है
  - वही incident दोबारा न हो, इसके लिए post-incident actions भी किए जाते हैं
- 7. Maintain: maintenance
  - user complaints और feedback इकट्ठा कर यह तय किया जाता है कि कौन-से bugs ठीक करने हैं और किन feature improvements को priority देनी है
  - इसमें ऐसे feedback को छाँटना भी शामिल है जिसे नज़रअंदाज़ किया जा सकता है
- 8. Migrate: migration
  - जब product खुद काफ़ी बदल जाए या tech stack बदलना पड़े, तब बड़े migration की ज़रूरत हो सकती है
- AI tools फिलहाल “Build” चरण में बड़ी मदद देते हैं, लेकिन ऊपर बताए गए बाकी 7 हिस्सों में वे कितने उपयोगी होंगे, इस पर भी विचार करना होगा
1960 के दशक से “non-developers बिना developers के software बना सकें” वाला सपना चलता आया है
- COBOL, Visual Basic, No-code आदि इसके उदाहरण हैं
- साधारण websites तो बिना coding के भी बनाई जा सकती हैं, लेकिन complex products में engineering work अब भी ज़रूरी है
अभिव्यक्ति की क्षमता जितनी बढ़ती है, उतना ही AI को विस्तार से यह बताना पड़ता है कि “यह कैसे काम करे”, और इसी के साथ complexity भी बढ़ती है
AI जितना ज़्यादा code बनाएगा, उसे maintain करने और architecture संभालने वाले specialist engineers की ज़रूरत उतनी ही बढ़ सकती है
आज LLM के साथ काम करना सीख चुके senior developers अधिक productive हो रहे हैं और कंपनियों में अधिक value पैदा कर सकते हैं

AI agents: बड़ा वादा, लेकिन 2025 में अब भी ‘अनजान क्षेत्र’

LLM के लॉन्च के दो साल बाद, कई डेवलपर्स ने coding और software engineering में LLM का इस्तेमाल करना सीख लिया है
prototyping, अनजान languages में switch करना, output की correctness verify करना और गलत जवाबों (hallucinations) को पकड़ना जैसे कामों में LLM ने बड़ी मदद की है
लेकिन AI agents अभी शुरुआती चरण में हैं
- अभी आम तौर पर उपलब्ध agent लगभग Devin ही है, जिसकी कीमत 500 डॉलर प्रति माह है, और उस पर राय भी मिली-जुली है
venture funding आने से और अधिक AI coding agent tools सामने आने की संभावना है
- कीमतें भी धीरे-धीरे कम हो सकती हैं
- GitHub Copilot 2025 में agent-based Copilot Workspace को आम उपयोगकर्ताओं के लिए उपलब्ध करा सकता है
- Stripe के पूर्व CTO द्वारा स्थापित /dev/agents जैसे टूल्स भी लॉन्च होने वाले हैं
AI agents धीमे response time (“सोचने” की प्रक्रिया) और अधिक लागत स्वीकार कर बेहतर accuracy हासिल करने की कोशिश करते हैं
- व्यवहार में यह approach accuracy को कितना बढ़ाएगी, और किन engineering use cases में productivity में बड़ा सुधार लाएगी, यह अभी स्पष्ट नहीं है

skilled software engineers की मांग बढ़ने की संभावना

skilled (senior और उससे ऊपर) software engineers की ज़रूरत अभी से ज़्यादा हो सकती है
- वे AI tools को अधिक प्रभावी ढंग से चला सकते हैं, और जानते हैं कि “बेहतरीन output” कैसा दिखता है, इसलिए वे अधिक सटीक “निर्देश” दे सकते हैं
- जब गलत code generation दिखे, तो वे तय कर सकते हैं कि generation process रोककर किस बिंदु पर सीधे source code खुद ठीक करना चाहिए
AI tools की मदद से बहुत अधिक code लिखा जाएगा, और अधिक लोग व कंपनियाँ अपने solutions बनाएँगी
- लेकिन जैसे-जैसे complexity बढ़ेगी, उसे नियंत्रण में रखने वाले skilled engineers की ज़रूरत भी बढ़ेगी
- मौजूदा tech कंपनियों को भी AI के कारण बढ़ती complexity संभालने के लिए अतिरिक्त लोगों की ज़रूरत पड़ सकती है
अगर software engineers AI के साथ काम करने की क्षमता विकसित करें, तो वे अधिक productive और अधिक valuable engineer बन सकते हैं
- tools को पूरी तरह “काबू” में लेना सीखने में समय लगता है, इसलिए तेज़ी से बदलते tool environment में सक्रिय रूप से experiment और learning करना महत्वपूर्ण है

11 टिप्पणियां

logone72 2025-01-20

वाकई बहुत अच्छा लेख है।

youngmuk 2025-01-20

आखिरी पैराग्राफ, "कुशल सॉफ्टवेयर इंजीनियरों की मांग बढ़ने की संभावना," से मैं बहुत सहमत हूँ। मतलब शायद यही है कि जितना जानते हैं, उतना ही अच्छा लिखते हैं? ^^

wkang586 2025-01-20

Expo 52 की तरह, जिन क्षेत्रों में हाल में बड़े बदलाव हुए हैं, वहाँ स्मार्ट Claude भी मददगार नहीं लगा।
वह बार-बार पुराने और अब गायब हो चुके कोड सुझाता रहा, इसलिए उल्टा बाधा ही बना।
लगता है, AI को सही तरह से इस्तेमाल करने के लिए आखिरकार ऐसी "परखने वाली नज़र" भी प्रशिक्षित होनी चाहिए।

scari 2025-01-13

छोटी-सी बात है, लेकिन मेरी जानकारी के अनुसार /dev/agents कोई coding agent नहीं है। अभी यह लॉन्च से पहले है, लेकिन यह खुद को "AI agent के लिए OS" कह रहा है।

ethanhur 2025-01-13

मैं व्यक्तिगत रूप से मानता हूँ और इस पर दांव लगा रहा हूँ कि भविष्य में (या नज़रिए के अनुसार मध्यम अवधि में) सभी इंजीनियरों की भूमिकाओं में coder की भूमिका घटेगी और TPM की भूमिका बढ़ेगी.

कोड तो Cursor बेहतर लिखता है, इसलिए उसे यह काम सौंप दिया जाएगा और इंसान शायद उसके ऊपर की अधिक abstracted layer में ज़्यादातर काम करेंगे.

spilist2 2025-01-13

शेयर करने के लिए धन्यवाद। मैंने भी हाल ही में इस विषय से जुड़ा एक लेख लिखा था, और इसमें कुछ मिलती-जुलती बातें हैं। https://www.stdy.blog/can-junior-beat-coding-agent/

bemong1 2025-01-13

सार: AI की वजह से डेवलपर्स का भविष्य (उम्मीद वाला पक्ष)

cwforum0340 2025-01-14

?? : अब डेवलपरों की ज़रूरत नहीं रही (घटिया कंपनी संस्करण)

tsboard 2025-01-17

दुनिया में, हाहाहाहा

kaykim 2025-01-14

1+ haha

roxie 2025-01-13

lol 100 अंक