जूनियर डेवलपर का पलटवार
(sourcegraph.com)Part 1: AI coding की छह लहरें
- Vibe coding एक मज़ेदार उपनाम है उस conversational coding शैली के लिए, जिसमें LLM से कोड लिखवाया जाता है और परिणाम पर feedback देते हुए प्रक्रिया दोहराई जाती है
- यह पारंपरिक coding या autocomplete-केंद्रित coding से बहुत अलग अवधारणा है; शुरुआत में इसका कोई स्पष्ट definition नहीं था, लेकिन Andrej Karpathy ने इसे "vibe coding" नाम दिया और यह तेज़ी से फैल गया
- फ़िलहाल vibe coding एक साथ निम्नलिखित तीन स्थितियों में मौजूद है:
- उद्योग के 80% लोगों को Vibe coding के अस्तित्व तक का पता नहीं है, और बहुतों ने "coding agent" शब्द भी पहली बार सुना है
- media और SNS के केंद्र में इसका विस्फोटक प्रसार जारी है, और बहस व पक्ष-विपक्ष के बीच भी कई डेवलपर इसे भविष्य की तकनीक मान रहे हैं
- मौजूदा Chat-based coding को पहले ही पुराने दौर की तकनीक माना जा रहा है, और तेज़तर नए तरीकों को लेकर उत्साहित कुछ डेवलपर अब chat में रुचि नहीं रखते
- इस लेख में AI-आधारित coding के विकास को कुल छह लहरों में समझाया गया है:
- पारंपरिक coding (2022)
- autocomplete-आधारित coding (2023)
- conversational coding (2024)
- coding agent (2025 की पहली छमाही)
- agent cluster (2025 की दूसरी छमाही)
- agent fleet (2026)
- इनमें पारंपरिक coding और autocomplete-आधारित coding धीरे-धीरे घट रही हैं, जबकि बाद में आने वाले तरीके हर बार और तेज़ गति से फैलते हैं
- vibe coding इन लहरों से अलग dotted line की तरह दिखाई देता है
- vibe coding ऊपर बताए गए सभी तरीकों के साथ सह-अस्तित्व में रहता है, और किसी एक specific तरीके के बजाय उस पूरे परिदृश्य को समेटने वाली अवधारणा है, जहाँ AI अधिकांश कोड लिखता है
- जल्द आने वाला "agent cluster" कई agents को parallel में manage करने की अवधारणा है, और "agent fleet" उससे आगे बढ़कर ऐसी संरचना है जिसमें AI manager निचले agents की निगरानी करता है
- FY26 org chart इसी को दिखाता है: एक डेवलपर कई agent groups चलाता है, और हर group bug fix, नई feature development, architecture refactoring जैसी अलग-अलग भूमिकाएँ निभाता है
- अभी agents रुक जाएँ या गलत दिशा में चले जाएँ तो इंसानों को सीधे हस्तक्षेप करना पड़ता है, लेकिन जल्द ही supervisor agents यह भूमिका निभाएँगे
- अंततः दर्जनों या उससे अधिक agents को एक साथ संभालना संभव होगा, और यह विशाल legacy code को प्रोसेस करने वाली automation system बन जाएगी
- ऐसे agent fleet 2026 की शुरुआत तक निश्चित रूप से सामने आ जाएँगे; parallel work को प्रभावी ढंग से संगठित करने की तकनीक पहले से तैयार है
Part 2: आप अभी कहाँ हैं?
- यदि आप अभी भी AI को सिर्फ code autocomplete tool की तरह इस्तेमाल कर रहे हैं या Completion Acceptance Rate(CAR) को महत्व दे रहे हैं, तो Figure 1 में आप पारंपरिक programming curve पर आते हैं
- अनुमान है कि यह curve 2027 तक पूरी तरह गायब हो जाएगा
- autocomplete सिर्फ एक साल पहले तक लोकप्रिय था, लेकिन अब यह core technology नहीं रह गया है
- यदि आप कुछ अधिक प्रगतिशील स्थिति में हैं, तो संभव है कि आप Copilot, Cursor, Sourcegraph, Windsurf जैसे IDE के भीतर chat-based coding tools का उपयोग कर रहे हों
- यह स्थिति ठीक है, और आप code autocomplete की तुलना में कहीं अधिक productive तरीका अपना चुके हैं
- chat-based coding के अभी भी बहुत उपयोगकर्ता हैं, लेकिन यह अब latest technology का मानक नहीं है
- हाल में आए coding agents (Aider.chat, Claude Code आदि) इन सभी तरीकों को पीछे छोड़ देने की क्षमता दिखा रहे हैं
- ये स्वाभाविक रूप से IDE में integrate होंगे, और मौजूदा conversational तरीकों की तुलना में कहीं अधिक तेज़ और efficient हैं
- एक बार agent इस्तेमाल कर लेने के बाद पहले वाले तरीके पर लौटना मुश्किल हो जाता है
- agent-आधारित coding भी vibe coding का ही एक रूप है
- vibe coding का मतलब है "वे सभी तरीके जिनमें AI कोड लिखता है", यह कोई specific modality नहीं है
- फ़र्क बस इतना है कि agent बार-बार बातचीत किए बिना भी अपने आप काम आगे बढ़ा लेते हैं
- हर coding शैली में बदलाव एक तरह के productivity multiplier pattern को दिखाता है:
- Chat-based coding manual काम की तुलना में लगभग 5 गुना अधिक productive है
- agent-आधारित तरीका chat की तुलना में फिर 5 गुना अधिक productive हो सकता है
- समय के साथ हर लहर 10x productivity तक पहुँच सकती है, लेकिन नई तकनीकें और तेज़ी से आने के कारण curve जल्दी flatten हो जाता है
- अभी हम AI के एक विशाल समुद्र के बीच में हैं, और लगातार शक्तिशाली होती लहरों यानी नई तकनीकों पर सवार होकर आगे बढ़ना होगा
- हर कंपनी Figure 1 की adoption curves में से कम-से-कम एक पर मौजूद है
- ज़रूरी है कि आप खुद से पूछें कि आप किस curve पर हैं
- vibe coding कोई specific तकनीकी modality नहीं, बल्कि development की नई philosophy और नई reality है
- इसका मूल यह है कि अब कोड आपको खुद नहीं लिखना है
- code writing AI को सौंपकर, इंसान review और coordination की भूमिका में जा रहा है
- अगले भाग में देखा जाएगा कि इस तकनीकी बदलाव का financial impact क्या है
- coding agents जादू नहीं हैं; वे ऐसी संरचना हैं जो लागत जलाने पर और समझदार बनती है
- यदि आपने अभी तक इन्हें आज़माया नहीं है, तो अभी इस्तेमाल करके या इस्तेमाल करने वालों को देखकर समझना ज़रूरी है
Part 3: नए ऊँट का user manual
- नवीनतम coding agents सिर्फ कुछ हफ़्ते पहले आए बेहद नए tools हैं, और इनमें से अधिकांश terminal-based हैं
- उपमा दें तो जैसे आप पूरी ज़िंदगी पैदल चलते रहे हों और अचानक आपको ऊँट मिल जाए; सुविधाजनक है, लेकिन संभालना मुश्किल है और बहुत खर्चीला भी
- सिर्फ "एक" ऊँट भी पैदल चलने से कहीं तेज़ है, लेकिन वह थूक भी सकता है, काट भी सकता है और भाग भी सकता है
- बहुत से डेवलपर अभी भी AI coding को लेकर सशंकित हैं, और अब भी खुद कोड लिखना चाहते हैं
- कुछ लोग साफ़ कहते हैं, "मैं कोड लिखने वाला इंसान हूँ!"
- लेकिन अब ऐसी सोच वास्तविकता से पीछे छूट रही है
- जो लोग सबसे अधिक संशय में हैं, उन्हें तुरंत नवीनतम coding agents (1 मार्च के बाद जारी हुए) डाउनलोड करके आज़माने की सलाह है
- लेखक ने भी कुछ हफ़्ते पहले खुद इनके चौंकाने वाले विकास को देखा
- agents का सिद्धांत vibe coding जैसा ही है, लेकिन इंसान को बार-बार prompt देने-लेने की ज़रूरत नहीं होती
- वे जटिल काम अपने आप करते हैं, और काम पूरा होने पर या समस्या आने पर फिर उपयोगकर्ता से संपर्क करते हैं
- वे पूरे काम का 90~99% अपने आप कर लेते हैं, इसलिए इंसान bottleneck से बाहर निकल जाता है
- chat-based तरीके से फ़र्क:
- agent एक बार में बड़े task units संभाल सकते हैं
- इस दौरान डेवलपर स्वतंत्र रूप से दूसरे काम कर सकता है (जैसे snack खाना, Hacker News देखना)
- उदाहरण: अगर आप सिर्फ इतना कहें, "इस JIRA ticket को resolve कर दो," तो
- वह JIRA CLI ढूँढेगा, और ज़रूरत पड़े तो install करने का अनुरोध करेगा
- ticket fields पढ़ने के लिए अस्थायी program लिखेगा
- code analysis → bug ढूँढना → fix सुझाना → tests लिखना और चलाना → loop दोहराना
- नतीजतन agent ऐसे मानव डेवलपर जैसा है जो चकाचौंध गति से काम करता है, बस उसकी दिशा-बोध थोड़ी कमज़ोर है
- कमियाँ:
- अभी यह सिर्फ छोटे दायरे के tasks को ही स्थिरता से संभाल सकता है
- ज़रूरत से ज़्यादा उम्मीद विफलता लाती है, और task decomposition की क्षमता अनिवार्य है
- बहुत बड़े tasks में यह भटक जाता है और रास्ता खो देता है
- इसलिए अभी समस्या का सावधानी से चुनाव और निगरानी ज़रूरी है, और agent को ज़िद्दी जानवर की तरह संभालना पड़ता है
- लेकिन यह स्थिति भी जल्द बदलेगी:
- agents जल्द ही IDE में स्वाभाविक रूप से integrate होंगे और ज़्यादा आसान व परिचित tools में विकसित होंगे
- ऊँट से काठी वाले घोड़े तक, और फिर जल्द ही रथ(chariot) तक विकास होगा
- निष्कर्ष: अभी agents के साथ काम करना सीखने का सबसे सही समय है
- और जल्द ही इसके साथ और features, बेहतर interfaces और productivity में बड़ी बढ़त आएगी
Part 4: कहा था गणित नहीं होगा
- यह section CIO और finance teams के लिए है
- FY26 budget अभी-अभी final हुआ है, तो प्रति डेवलपर LLM usage cost के लिए आपने कितना रखा है?
- रोज़ $25 सुनने में काफ़ी साहसी लगता है, लेकिन वास्तव में यह काफ़ी उचित स्तर के करीब है
- वास्तविकता इससे भी कठोर है:
- coding agents बहुत महंगे हैं — वे लगभग $10~12 प्रति घंटा के हिसाब से tokens खर्च करते हैं
- यदि मौजूदा coding assistant license लगभग $30 प्रति माह है, तो यह दर्जनों गुना लागत अंतर है
- लेकिन गणना के हिसाब से, coding agents अगर 8~10 घंटे प्रतिदिन उपयोग हों, तो उनकी productivity लगभग एक junior developer को hire करने के बराबर होती है
- $10 प्रति घंटा के हिसाब से यह काफ़ी सस्ता है, और एक डेवलपर दो agents एक साथ चला सकता है
- यदि रोज़ लगभग $100 LLM पर खर्च किए जाएँ, तो डेवलपर productivity 2x से अधिक बढ़ सकती है
- लेकिन असली बदलाव जल्द आने वाले agent clusters (2025 Q3 के लिए अनुमानित) से आएगा
- एक डेवलपर कई agents को parallel में चला सकेगा
- हर agent bug fix, नई feature development, documentation writing जैसे अलग-अलग काम स्वतंत्र रूप से करेगा
- नतीजतन एक डेवलपर मानो कई डेवलपरों की भूमिका निभा सकेगा
- बेशक, जितना अधिक कुशल व्यक्ति होगा, प्रभाव भी उतना ही बड़ा होगा
- agent clusters का आगमन software development environment को cloud में shift करने का कारण बनेगा
- दर्जनों या सैकड़ों agents को local desktop पर चलाना संभव नहीं होगा
- cloud-based development environment व्यावहारिक रूप से standard बन जाएगा
- इसलिए, cloud budget भी अतिरिक्त रूप से सुरक्षित करना होगा
- उदाहरण के लिए, अगर एक डेवलपर 5 agents चलाता है:
- $50 प्रति घंटा → सालाना लगभग $100,000 का खर्च (cloud cost छोड़कर)
- यह अब ‘सस्ता निवेश’ नहीं, बल्कि एक बड़ा खर्च बन जाता है
- लेकिन productivity 5x से अधिक बढ़ सकती है, इसलिए लंबी अवधि में ROI ऊँचा हो सकता है
- समस्या यह है कि अधिकांश कंपनियों ने शायद 2026 operating budget में इस तरह की LLM लागत शामिल ही नहीं की होगी
- इससे कंपनियों के बीच अंतर बढ़ेगा: जिनके पास budget होगा वे तकनीकी बढ़त पाएँगी, और जिनके पास नहीं होगा वे पीछे छूटने के जोखिम में होंगी
- निष्कर्ष:
- software development अब pay-to-play high-speed train बन चुका है
- अगर आपके पास ticket यानी budget नहीं है, तो समूह से बाहर छूट जाने का बड़ा ख़तरा है
Part 5: agent fleet आ रहा है
- यहाँ से बात थोड़ी असहज सच्चाइयों की है
- अगर आप मानसिक रूप से तैयार नहीं हैं, तो थोड़ा विराम लेकर फिर पढ़ना बेहतर होगा
- agent cluster का अगला चरण है “agent fleet”, यानी ऐसा माहौल जहाँ डेवलपर 100 से अधिक agents एक साथ operate करता है
- इस चरण में ऊपर से नियंत्रण करने वाला supervisor agent आता है, जो नीचे के agent groups को manage करता है, और सिर्फ समस्या आने पर इंसान हस्तक्षेप करता है
- भविष्य के डेवलपर की भूमिका अब code writer की नहीं रहेगी
- वह agents और AI managers को दिखाने वाले dashboard को operate और supervise करेगा
- कुछ लोग इसे व्यंग्य में "AI babysitting" कह सकते हैं, लेकिन यही जल्द नए software development का रूप होगा
- CIO के नज़रिए से, agent fleet के युग में प्रति डेवलपर प्रति दिन हज़ारों डॉलर की LLM लागत आ सकती है
- चाहे inference cost घट भी जाए, Jevons paradox के अनुसार usage में वृद्धि, लागत में कमी के लाभ को समाप्त कर देती है
- उदाहरण के लिए: अपने कभी ख़त्म न होने वाले bug backlog को याद कीजिए
- लेकिन यह बर्बादी नहीं, बल्कि बेहद ऊँचे मूल्य वाला निवेश है
- अंततः engineering organizations उस रफ़्तार से चल पाएँगे, जिसकी management को अपेक्षा रहती है
- हम ऐसे दौर में प्रवेश करेंगे जहाँ startup की तरह फुर्तीले होकर customers को चकित और प्रसन्न किया जा सकेगा
- कमी सिर्फ एक है: इसमें बहुत बड़ा budget चाहिए
- कुछ बड़े enterprises ने LLM experiments के लिए पहले ही slush fund जैसा budget सुरक्षित कर लिया है
- लेकिन बहुत सी कंपनियों ने संभवतः इस budget cycle में इसे बिलकुल ध्यान में नहीं रखा होगा
- कुछ बड़े enterprises ने LLM experiments के लिए पहले ही slush fund जैसा budget सुरक्षित कर लिया है
- यदि साल के अंत तक आप प्रति डेवलपर $50,000 का अतिरिक्त budget सुरक्षित नहीं कर पाते, तो restructuring के अलावा विकल्प कम रह सकते हैं
- यह बदलाव उल्टे agile startups के पक्ष में जा सकता है
- अब तकनीकी gap से अधिक budget की उपलब्धता कंपनी की competitiveness तय करेगी
- और अगर budget जुटाया नहीं जा सकता, तो कटौती के लिए बचने वाला एकमात्र विभाग कौन-सा है, यह स्पष्ट है
- उसका उत्तर पाठक पर छोड़ा गया है
- अच्छी बात यह है कि यह prediction थोड़ी अतिरंजित भी हो सकती है
- Claude(LLM) से चर्चा करने पर लगा कि अगर अनुमान को लगभग 6 महीने पीछे खिसका दिया जाए तो यह अधिक यथार्थवादी हो सकता है
- अच्छी ख़बर यह है कि शुरुआत अब होती है
- बुरी ख़बर ख़त्म हो चुकी है, और अब सिर्फ एक चीज़ बची है: मीठा प्रतिशोध
Part 6: जूनियर डेवलपर का बदला
- भविष्य अंधकारमय नहीं है। बल्कि software industry में अब भी बहुत-सी नौकरियाँ हैं
- बस हाथ से कोड लिखने वाले पारंपरिक developer की भूमिका खत्म होगी
- पिछले एक साल में देखा गया एक पैटर्न यह है कि junior developers, senior developers की तुलना में AI अपनाने में कहीं अधिक सक्रिय हैं
- कुछ लोग चिंतित हैं कि AI उनकी नौकरी छीन लेगा, लेकिन अधिकांश तेज़ी से बदलाव के अनुरूप ढल रहे हैं
- वे O’Reilly की AI Engineering किताब पढ़ रहे हैं, और chat coding व coding agents का कुशल उपयोग कर रहे हैं
- दूसरी ओर, senior developers में बहुतों ने LLM को लगभग छुआ तक नहीं है, या सिर्फ अप्रत्यक्ष रूप से अनुभव किया है
- AI तकनीक के प्रति खुला प्रतिरोध दिखाने के उदाहरण भी मौजूद हैं
- उदाहरण: एक प्रसिद्ध कंपनी के डेवलपर ने “AI को छोड़कर पारंपरिक coding पर लौट चलें” वाला slide PDF जमा किया
- ऐसी प्रतिक्रियाएँ नई तकनीक को लेकर चिंता और मौजूदा ज्ञान में किए गए निवेश के डूब जाने के डर से आती हैं
- नई language या tool सीखना मूलतः ‘फिर से शून्य से शुरू करना पड़ेगा’ जैसी आशंका लेकर आता है
- लेकिन वास्तविकता स्पष्ट है:
- जो लोग AI से दूर रहे, वे खेल में पहले ही पीछे छूट चुके हैं
- junior developers सस्ते हैं, अधिक अनुकूलनीय हैं, और तेज़ी से सीखते हैं
- जब कंपनियों को developer workforce में बदलाव करना होगा, तो किसे चुनेंगी यह स्पष्ट है
"AI को यह साबित करने की ज़रूरत नहीं कि वह आपसे बेहतर है। ज़रूरी यह है कि आप AI को बेहतर ढंग से इस्तेमाल करना जानते हों।"
- यानी, junior developer अब पहाड़ी पर चमकती तलवार लेकर खड़ा है
- और senior developers से बदलाव के अनुरूप ढलने को कह रहा है
- इस पूरी स्थिति से मिलने वाला सबक:
- आप कोई भी हों, चाहे कंपनी हों या व्यक्ति — junior की तरह व्यवहार कीजिए
- अभी AI तकनीक को अपनाने और उसके अनुरूप ढलने का समय है
- Sourcegraph इस तकनीकी विकासधारा का रोज़ विश्लेषण कर रहा है
- और coding agents को enterprise code assets से जोड़ना अगली पीढ़ी की core strategy है
- समग्र रूप से देखें तो, AI adoption बढ़ने के साथ software से जुड़ी नौकरियाँ उल्टे बढ़ भी सकती हैं
- hiring में मौजूदा ठहराव सिर्फ इस वजह से है कि कंपनियाँ अभी नहीं जानतीं कि प्रतिक्रिया कैसे दें, इसलिए सावधानी बरत रही हैं
- इतिहास में हर तकनीकी संक्रमण के दौरान productivity बढ़ी है और GDP भी ऊपर गया है
- इसलिए अभी करने योग्य काम:
- coding agents के बारे में सीखना और उनमें दक्ष होना
- PM या दूसरी technical roles भी अपवाद नहीं हैं
- LLM-आधारित development सिर्फ prompts लिखना नहीं है। validation, testing, coordination जैसी चीज़ें वास्तविक development practice को बदल देंगी
- चेतावनी:
- coding agents शक्तिशाली हैं, लेकिन tunnel boring machine जैसे tools हैं
- महंगे हैं, रुक सकते हैं, दिशा खो सकते हैं
- लगातार मार्गदर्शन और यथार्थवादी अपेक्षाएँ तय करना ज़रूरी है
- vibe coding अपने नाम की तरह मज़े से काम करने का तरीका है
- सीधे कोड न लिखना पड़े, यह आश्चर्यजनक रूप से बहुत मुक्तिदायक है
- “6 महीने बाद यह और बेहतर होगा, तो अभी इंतज़ार करते हैं” जैसी सोच ख़तरनाक है
- आख़िर में आप देर से शुरू करेंगे और सबसे देर से पहुँचेंगे
- agents आ रहे हैं। सिर्फ coding agents नहीं
- बल्कि पूरी कंपनी के कामकाज में सैकड़ों task agents पहले ही लाए जा रहे हैं
- निष्कर्ष के रूप में action items:
- chat पर शिफ्ट करें
- autocomplete छोड़ें
- direct coding कम करें
- validation/review/execution को AI-आधारित environment के अनुरूप सीखें
- latest technology trends के अनुसार लगातार प्रयोग करें और लागू करें
- coding agents अभी कठिन और अपूर्ण लग सकते हैं, लेकिन जल्द ही वे आम हो जाएँगे
- वे इंसानों की तुलना में कहीं सस्ती productivity machines हैं, इसलिए कंपनियों का चुनाव स्पष्ट है
- 2025 के अंत तक “software engineer” की नौकरी में लगभग कोई direct coding नहीं बचेगी
- उसकी जगह agent operations, coordination और validation management मुख्य कार्य बन जाएँगे
- अंत में: अगर आपको समझ न आए कि अभी क्या करना चाहिए, तो किसी junior developer से मदद माँगिए
दो साल पहले लिखे गए ‘Cheating is all you need’ को अब दो साल हो चुके हैं, और इस बीच सब कुछ बदल चुका है
हम अभी इसी बदलाव के बीचोंबीच हैं, और यही वह समय है जब इस लहर पर सवार होना चाहिए
23 टिप्पणियां
यह वाकई काफ़ी निराशाजनक है
मौजूदा तरीका: सोच => code (धीमा) => debugging
AI: सोच => बारीक prompt लिखना => code (फौरन) => debugging
लेकिन आमतौर पर, अपनी सोच को prompt में लिखने से ज़्यादा उसे code में लिखना तेज़ होता है, है ना? पहले से बहुत अच्छी तरह ज्ञात चीज़ें करने के मामलों को छोड़कर... जिन हिस्सों में reliability महत्वपूर्ण है, वहाँ तो आखिरकार लिखने के बाद आँखों से logic समझना ही पड़ता है, इसलिए उसे सौंप भी नहीं सकते, और जैसे ही सौंपते हैं, पेशेवर जिम्मेदारी भी खत्म हो जाती है।
मैं अब ऐसा मैनेजर हूँ जो खुद डेवलपमेंट नहीं करता, लेकिन आजकल फिर से जूनियर बनने जैसा महसूस करते हुए तरह-तरह की चीज़ें खुद करके देख रहा हूँ। जो काम मैं टीम के सदस्यों से करवाता था, अब जब खुद कर रहा हूँ तो रफ़्तार इतनी तेज़ हो गई है कि थोड़ा हैरान हूँ। अब यह भी लग रहा है कि छोटी टीम में भी और ज़्यादा चीज़ें की जा सकती हैं। अच्छे tools और बढ़िया विवरण के लिए धन्यवाद!
मैं अभी शौकिया तौर पर vibe coding से एक web game का client, server और admin डेवलप कर रहा हूँ (खुद सीधे edit भी नहीं करता। जिन हिस्सों में बदलाव चाहिए, उन्हें कॉपी करके बदलाव के लिए कहता हूँ और जो code निकलता है उसे वैसे का वैसा लागू कर देता हूँ)। अभी लगभग 20,000 lines हो चुकी हैं। कभी-कभी बहुत चिढ़ होती है, लेकिन गुस्से में सवाल पूछूँ तब भी अभी तक यह ठीक-ठाक code निकालकर दे रहा है।
मैं इस लेख से 90 प्रतिशत से ज़्यादा सहमत हूँ.
अब यह लगभग तय लगता है कि डेवलपमेंट की क्षमताएँ और paradigm बदलने वाले पल आ रहे हैं.
अब मुझे लगता है कि supervisory capability के नज़रिए से ज़्यादा design patterns, general-purpose application बनाने के तरीके, और problem solving के लिए methodologies पर ध्यान देना चाहिए.
एल्गोरिदम डेवलपमेंट तो काफ़ी पहले ही इंसानी सीमाओं से आगे निकल चुका है, और जैसे AI ऐसे algorithm optimization कर रहा है जिन्हें इंसान समझ भी नहीं सकता, वैसे ही आगे के डेवलपर्स के लिए अब समय है कि वे और व्यापक तथा ज़्यादा trends पर ध्यान दें.
AI सीखना महत्वपूर्ण है, लेकिन मेरा मानना है कि हर बार कोई नई तकनीक आने पर उस पर जरूरत से ज़्यादा प्रतिक्रिया देने की आवश्यकता नहीं है। जो मूलभूत अवधारणाएँ नहीं बदलतीं, उनमें अधिक समय निवेश करना अधिक प्रभावी है, और AI अपेक्षाकृत सीखने में आसान है, इसलिए इसे धीरे-धीरे सीखना भी ठीक है। हर बार उसके पीछे भागने के बजाय अपनी बुनियादी क्षमताओं को विकसित करना अधिक महत्वपूर्ण है।
अभी भी मैं ज़्यादातर लोगों से बेहतर करता हूँ। Open source गुरुओं का code सीखते-सीखते, अगर सवाल अच्छे से पूछो तो quality भी अच्छी निकलती है haha
यह पता नहीं है कि मूलभूत AI तकनीक किस स्तर तक विकसित होगी।
अभी के स्तर पर तो इसकी कोई संभावना ही नहीं है
सीखने से हासिल होने वाले ज्ञान या अनुभव की वैल्यू कम होने के पहलू से देखें तो, सीनियर और जूनियर के बीच की सीमा ही धुंधली होती दिखेगी।
और मुझे लगता है कि यह कुछ लोगों के दबदबे वाला बाज़ार बन जाएगा। आगे चलकर डेवलपर हायरिंग शायद लगाए गए प्रयास या करियर की अवधि से ज़्यादा, जन्मजात सोचने की क्षमता और तर्क क्षमता में उत्कृष्ट AI पायलट चुनने की दिशा में जाएगी।
सुपरवाइज़र एजेंट, हाँ..
अगर डेवलपमेंट के लगभग 4 चरण हों (डेवलपमेंट, डिबगिंग, QA और डिबगिंग, रिफैक्टरिंग), तो क्या 4 लेयर में होने वाले सभी hallucinations को पकड़ा जा सकेगा..
अभी भी prompt में डिबगिंग और टेस्ट की requirements बहुत बारीकी से लिख दी जाएँ, तब भी कभी-कभी "समस्या क्या है, समझ नहीं आ रहा" जैसी बेतुकी बात निकल आती है (Sonnet 3.7).
जब तक Transformer architecture खुद ही न बदल जाए, कहना मुश्किल है.
मुझे
vibe codingसे सहमत होना मुश्किल इसलिए लगता है क्योंकि जिस स्थिति में हमें अब भी code-आधारित तरीके से काम करना पड़ता है, उसे AI agent हल नहीं कर पा रहा है। अगर agent सचमुच स्वायत्त रूप से काम करने वाले माहौल में चल रहा हो, तो फिर ऐसे code की ज़रूरत ही क्यों होगी जिसे मशीन के लिए समझना असुविधाजनक है?मेरे हिसाब से AI agent जिस क्षण सच में software development का स्वरूप बदलेंगे, वह वही क्षण होगा जब उसे निर्देश देने वाले उपयोगकर्ता के लिए
codeनाम की परत पूरी तरह abstract हो जाएगी। अभी तो यह बस code के टुकड़े तेज़ी से generate करने के स्तर पर है (हालाँकि यह भी काफ़ी प्रभावशाली है)।जब तक वह क्षण नहीं आता कि AI agent हमें code से मुक्त कर दें, तब तक बदलाव भले ही चौंकाने वाला लगे, लेकिन यह दावा मानना मुश्किल है कि इससे software industry के काम करने के तरीके में नाटकीय बदलाव आ जाएगा।
मेरा मानना है कि यह Hyundai Motor की मेगा फैक्टरी शुरू करने जैसा ही है.
पारंपरिक कामगार शायद setup और maintenance की ओर शिफ्ट हो जाएंगे. (यह हिस्सा मुझे कुछ ज़्यादा समझ में आता है.)
लेकिन क्या अमूर्तन के क्षेत्र से जुड़े हिस्से भी ऐसे ही हो जाएंगे?
व्यक्तिगत रूप से, मुझे लगता है कि यह संभव है.
अब भी थोड़े जटिल pattern groups की जोड़ियों को alphabet के क्रम में लिखते समय कभी-कभी कन्फ्यूजन हो जाता है.. (प्लीज़ !!) कीबोर्ड टाइप करने का मन नहीं है
आखिरी वाले junior हिस्से को छोड़ दें तो मैं कुल मिलाकर कुछ हद तक सहमत हूँ।
मुझे लगता है, इसे यूँ कहना ज्यादा सही होगा कि जो senior या मौजूदा कंपनियाँ AI को अपनाने में असफल रहती हैं, उनकी जगह पीढ़ीगत बदलाव होगा।
कंपनी के महत्वपूर्ण development deliverables लगभग 100% इंटरनेट पर public नहीं होते। मौजूदा AI स्तर से उस दर्जे की quality बनाई नहीं जा सकती। बकवास।
अगर ज्ञान और कौशल मिलते-जुलते हों, तो सही माहौल में नतीजे भी लगभग वैसे ही आएंगे।
डेवलपमेंट सिर्फ़ उन web applications तक सीमित नहीं है जिनके बारे में काफ़ी सामग्री public में उपलब्ध है; इसमें graphics engine से लेकर embedded और low-level chip design तक बेहद विविध क्षेत्र आते हैं। ऐसे बहुत से क्षेत्र हैं जहाँ शुरुआत शून्य या लगभग शून्य से करनी पड़ती है। मेरे अपने क्षेत्र में भी GitHub, documentation या इंटरनेट पर ठीक से संदर्भ लेने लायक सामग्री नहीं है। स्वाभाविक है कि Grok हो या Claude, वे भी ठीक-ठाक नतीजे नहीं देते। पूरे code को model को देना या fine-tuning करना अलग बात है।
शायद आप ऐसे development में काम नहीं करते जहाँ इस तरह की विशेषज्ञता चाहिए, या फिर आपके पास ऐसे assets नहीं हैं जिन्हें कंपनी के अंदर से बाहर दिखाने की मनाही हो। इसलिए यह मान लेने से बचना बेहतर होगा कि आप अपनी स्थिति को पूरी तरह सही समझ रहे हैं।
क्या यह तर्क थोड़ा अजीब नहीं है कि अगर कोई चीज़ इंटरनेट पर नहीं है, तो AI उसमें दखल नहीं दे सकता? जैसे-जैसे learning methods पर रिसर्च आगे बढ़ती जाएगी, मुझे लगा था कि in-house AI, in-house डेवलपर्स की जगह ले लेगा।
मतलब समस्या इंटरनेट नहीं है, बल्कि AI मॉडल बनाने के लिए ट्रेन किया जा सकने वाला डेटा ही नहीं है.. फिर ट्रेनिंग मेथड पर रिसर्च की बात क्यों आ रही है? मैं अभी ठोस वास्तविकता की बात कर रहा हूँ। 2025 के अंत तक सभी डेवलपर्स को बदल देने वाला AI बिल्कुल नहीं बनाया जा सकता। मूल समस्या परफॉर्मेंस की ही नहीं है।
लगता है आपने मेरी बात को गलत समझा है; मेरा आशय उस स्थिति से था जहाँ कंपनी अपने ही कोड से AI को train करती है और फिर उसे कंपनी के अंदर code generation के लिए इस्तेमाल करती है।
सुपरवाइज़र को भी कुछ तो पता होना चाहिए… कोई खेल रहा है, काम कर रहा है, बेकार की चीज़ें कर रहा है या अच्छा कर रहा है… लगता था सुपरवाइज़र तो बस बिजली बंद करके फिर चालू करने वाला इंसान है…
अगर बिजली बंद करके फिर चालू करना ही सुपरवाइज़र का काम है… तो वही सुपरवाइज़र AI से बदले जाने के लिए सबसे मुफ़ीद इंसान है।
व्यक्तिगत रूप से मैं इससे ज़्यादा सहमत नहीं हूँ। मेरा मानना है कि जो senior, AI का सहारा लेकर काम करने वाले junior से पीछे रह जाए, वह शुरुआत से ही senior नहीं था।
अफसोस है कि दावे के समर्थन में पर्याप्त आधार नहीं दिखते।
क्या Neo का नाम बदल गया है?
नाम नहीं बदला गया है, बस GN+ और neo का संकेत दोहराया हुआ लग रहा था इसलिए उसे एक में समेट दिया गया है। क्लिक करने पर आप neo पर जाएंगे।