AI coding के दावों का भ्रम: 'shovelware' की बाढ़ आखिर क्यों नहीं दिख रही

• हाल में AI coding tools द्वारा productivity बढ़ाने के दावों को डेटा से परखने पर पता चला कि वास्तव में न तो गति और न ही output में कोई स्पष्ट बढ़ोतरी दिखती है
• METR research के अनुसार, developers को लगा कि AI coding tools से productivity 20% बढ़ी, लेकिन वास्तव में 19% घट गई
• अनगिनत प्रचार संदेशों, कंपनियों और developers के बढ़ा-चढ़ाकर किए गए 10x productivity दावे बाज़ार की वास्तविकता या नए software releases में दिखाई नहीं देते
• Shovelware (बड़े पैमाने पर बने apps, low-quality software) में उछाल जैसी कोई घटना नहीं दिखी, यानी कोई ठोस बदलाव नज़र नहीं आता
• GitHub, Copilot, Cursor, Google, OpenAI जैसी कंपनियों और कुछ developers द्वारा किए गए productivity के अतिरंजित दावे का investment, restructuring, salary setting में दुरुपयोग हो रहा है
• मुख्य निष्कर्ष: “जब तक वास्तव में ज़्यादा software नहीं बन रहा, तब तक यह दावा कि AI coding developers को 10x बना देता है, एक मिथक है”; इसलिए developers को दबाव में आए बिना डेटा के आधार पर जवाब देना चाहिए

---

परिचय: software developers, AI coding से नाराज़

• लंबे समय तक software developer के रूप में काम करते हुए programming पर गर्व और पहचान बनी रही
• AI-based coding tools के शुरुआती दौर में उम्मीद थी, लेकिन हालिया research (METR) के बाद संदेह बढ़ा
  • लेखक को खुद लगता था कि AI coding उन्हें लगभग 25% तेज़ बनाती है, लेकिन METR research में नतीजा उल्टा 19% धीमा निकला
• इस research ने दिखाया कि AI tools की प्रभावशीलता को लेकर developers की निजी धारणा और वास्तविक मापे गए डेटा एक-दूसरे के बिल्कुल उलट हैं
• खुद प्रयोग करने पर भी महसूस हुआ कि AI का इस्तेमाल वास्तविक programming समय पर सकारात्मक असर नहीं डालता

प्रत्यक्ष सत्यापन: AI बनाम random comparison experiment

• काम की हर unit पर AI इस्तेमाल करने और न करने के बीच समय का अंतर (Delta) मापने वाला experiment अपनाया गया
• 6 हफ्तों के experiment से मिले डेटा में statistically significant difference नहीं मिला
• छोटे sample के बावजूद यह रुझान दिखा कि AI का इस्तेमाल वास्तव में 21% तक धीमा कर सकता है (METR research के समान)
• अगर सच में 2x या 10x सुधार होता, तो वह डेटा में साफ़ दिखता
• फिलहाल AI coding का सपना हक़ीक़त नहीं बना है और ज़मीन पर बदलाव नहीं दिखता

उम्मीद बनाम हक़ीक़त: Shovelware की बाढ़ क्यों नहीं

• अगर AI coding की productivity revolution सच होती, तो तरह-तरह के apps, services, games की बाढ़ आ जानी चाहिए थी
• AI coding tools की marketing messaging ("Built to make you extraordinarily productive" आदि) हर तरफ़ दिखाई देती है
• Google, OpenAI, GitHub Copilot आदि भी developers के लिए 25% speed increase या 10x productivity का दावा करते हैं
• लेकिन वास्तविक नए software release डेटा (GH Archive, BigQuery आदि) में तेज़ growth या विस्फोट जैसी स्थिति नहीं दिखती
• 2022 के बाद AI coding के बड़े पैमाने पर फैलने के बावजूद, दुनिया भर में नए releases और projects के आँकड़ों में कोई बड़ा बदलाव नहीं है

बाज़ार पर असर और developers की वास्तविकता

• AI-First strategy, FOMO, mass layoffs और developers की salary cuts जैसे सामाजिक प्रभाव भी industry में दिख रहे हैं
• लेकिन वास्तविक development environment में AI tools productivity revolution देने में विफल हैं
• learning curve या tool proficiency भी इस पूर्ण productivity gap को समझाने के लिए पर्याप्त नहीं हैं

निष्कर्ष: ठंडे दिमाग से data-driven judgment की ज़रूरत

• अभी तक नए software shipment/output में कोई बदलाव नहीं है, यह डेटा से पुष्टि करना सबसे अहम है
• AI से 10x coder बनने के दावे के समर्थन में कोई सबूत नहीं है
• developers को दबाव के आगे झुकना नहीं चाहिए, बल्कि खुद देखे गए डेटा के आधार पर tool चुनना चाहिए

आम आपत्तियों के जवाब

1. "अगर prompt engineering सही से सीख ली जाए, तो 10x developer बन सकते हैं"

   • अगर वास्तव में 10x productivity हासिल करने वाले लोग होते, तो दुनिया भर में नए software production की मात्रा दोगुने से भी ज़्यादा हो चुकी होती
   • दावों से ज़्यादा महत्वपूर्ण सबूत वास्तविक output (apps, projects आदि) है

2. "यह अभी शुरुआती चरण में है, समय लगेगा"

   • इस क्षेत्र में अरबों डॉलर invest हो चुके हैं और यह पहले से real-world work में लागू है
   • आज लिए गए फैसले लोगों की ज़िंदगी पर सीधे असर डाल रहे हैं

3. "अभी adopt नहीं किया तो पीछे रह जाएंगे"

   • GitHub Copilot के डेटा में भी skill बढ़ने के साथ वास्तविक productivity growth बहुत मामूली है (29% → 34% acceptance rate)

4. "quality बेहतर हुई है, बस quantity वही है"

   • industry-wide quality उल्टे गिरी है और testing भी कम हुई है
   • अगर यह सचमुच 10x coder tool होता, तो Shovelware की भरमार वास्तविकता बन चुकी होती

5. "सब कुछ अब websites के इर्द-गिर्द है, और आजकल domain names की किसी को परवाह नहीं; Vercel जैसी सेवाओं के subdomains ही सब कुछ हैं"

   • फिर भी बहुत से users अब भी अलग domain को पसंद करते हैं

6. ".ai domains में तेज़ बढ़ोतरी (इस साल 47%) = वास्तविक वृद्धि"

   • नए domains की बढ़ोतरी सिर्फ AI startups के pivot की वजह से है, कुल नए domains में कोई विस्फोटक बढ़ोतरी नहीं है
   • domains की कुल संख्या इस दावे का समर्थन नहीं करती

7. "development का मूल काम code के बाहर होता है"

   • बड़ी कंपनियों के बजाय individual/small developer environment में वास्तव में code ही केंद्र में होता है
   • फिर भी छोटे-छोटे coding urges को पूरा करने वाले नए projects की संख्या इतनी नहीं बढ़ी कि वह साफ़ दिखाई दे

समापन

• developers वास्तव में पहले से ज़्यादा release नहीं कर रहे हैं
• AI coding के 10x productivity दावे को डेटा से खारिज किया जा सकता है
• industry के FOMO और marketing narrative से प्रभावित हुए बिना वास्तविक output के आधार पर मूल्यांकन करना चाहिए
• लेखक का संदेश: “अगर आप पर दबाव बनाया जा रहा है, तो डेटा और charts दिखाइए। 10x productivity के दावों पर सबूत मांगिए।”

[ahwjdekf]

10x डेवलपर के लिए AI की मदद से शायद लगभग 12x तक छलांग लगाना संभव हो।

[overthetop]

AI एक भ्रम है। इस पर भरोसा नहीं किया जा सकता और इसकी गुणवत्ता भी निम्न है। AI से development किया जा सकता है, यह बढ़ा-चढ़ाकर बोला गया झूठ है। यह संभव नहीं है। और AI का उपयोग करना, developer की नैतिकता को छोड़ देने वाला गैर-जिम्मेदाराना व्यवहार है।

[nemorize]

अगर साधारण दोहराए जाने वाले काम पूरी तरह AI को सौंपे जा सकें, और हम अधिक महत्वपूर्ण कामों में पूरी तरह डूब सकें, तभी शायद यह कहा जा सकेगा कि AI कोड लिखने की productivity बढ़ाने में वास्तव में बहुत मददगार है.

एक बार command देने के बाद, कई दसियों सेकंड इंतज़ार करने पर output आता है, लेकिन उन दसियों सेकंड का कोई उपयोग भी नहीं कर सकते, और यह भी नहीं कि हर बार उन कुछ सेकंडों के बाद हमेशा बिल्कुल perfect output ही मिलेगा.

आखिरकार, जब तक वह साधारण काम पूरी तरह सही ढंग से खत्म नहीं हो जाता, मुझे लगातार उसी पर ध्यान देना पड़ता है, और किसी दूसरे काम पर switch भी नहीं कर पाता... इसलिए meaningful सुधार की उम्मीद करना मुश्किल लगा.

[nemorize]

मुझे तो लगा कि इससे बेहतर यह था कि Karrot पर 10,000 won प्रति घंटा देकर कुछ घंटों के लिए सिर्फ साधारण काम करने वाला कोई पार्ट-टाइम मददगार रख लिया जाए; उत्पादकता बढ़ाने में वह ज़्यादा मददगार था।
हफ्ते में लगभग 100,000 won के खर्च पर भी, व्यक्तिगत रूप से मैं काफ़ी संतुष्ट था।

खासकर कुछ ऐसी आंटियों के साथ भी काम किया जो पहले accounting का काम करती थीं, फिर नौकरी छोड़कर full-time homemaker बन गई थीं; जिन्हें coding बिल्कुल नहीं आती थी, वे भी कुछ बार feedback देने के बाद बहुत साफ-सुथरा काम करके दे देती थीं, हाहा
boilerplate code तो वे Excel का इस्तेमाल करके autofill, formulas वगैरह से पलक झपकते बना देती थीं...

[zxcv123]

उम् .. सच कहूँ तो मुझे लगता है कि AI भी आखिर एक टूल ही है, इसलिए उसका सही इस्तेमाल करना आना चाहिए..
किसी भी टूल में, उसे अच्छी तरह इस्तेमाल करने वालों की तुलना में बस जैसे-तैसे या ठीक से इस्तेमाल न कर पाने वाले लोग ज़्यादा होते हैं.
अगर AI को इस तरह सेट किया जाए कि वह high-quality परिणाम दे, तो वह पर्याप्त रूप से दबदबे वाला performance दिखाता है.
जो लोग AI से high-quality परिणाम निकलवाना नहीं जानते, वही बस बेवकूफ़ी भरे prompts ठूंसते रहते हैं और फिर कहते हैं कि productivity कम हो गई. AI की productivity को नकारना मुझे बिल्कुल समझ नहीं आता.

[kirrie]

लेकिन आपका ऐसा कहना मुझे कुछ वैसा ही लगता है जैसे यह कहना कि “जो लोग वास्तव में CS को गहराई से समझते हैं और पर्याप्त अनुभव रखते हैं, वे किसी भी AI से अधिक उत्पादक होते हैं।” — यानी इससे मानो कुछ भी साबित नहीं होता।

[ndrgrd]

मैंने कुछ समय पहले उस METR रिसर्च को देखा था, और उसने उन बातों को बहुत अच्छी तरह समझाया जिनको लेकर मैं महसूस कर रहा था और सवाल भी थे.

Hacker News की टिप्पणियों में जिस "दोहराए जाने वाले काम" की बात होती है, उसे भी करवाने पर वास्तव में ज़्यादातर मामलों में मैन्युअल जाँच और सुधार की ज़रूरत पड़ती है.
AI द्वारा लिखे गए 'सरल' नतीजों की बेतरतीब लॉजिक देखकर मुझे यह सोच एक-दो बार नहीं, कई बार आई है कि यह काम तो मैं खुद ही कर लेता.

वाकई बहुत ही सरल copy-paste स्तर के काम यह अच्छी तरह कर लेगा.
लेकिन ऐसे कामों में तो बस copy-paste और snippets ही ज़्यादा efficient हैं. न इंटरनेट से कनेक्ट होकर अपना डेटा किसी और के server पर अपलोड करना पड़ता है, न ही दर्जनों सेकंड तक इंतज़ार करना पड़ता है.

[GN⁺]

Hacker News की राय

• मेरे लिए AI एक घंटी-आकार के कर्व जैसा है, और मुझे लगता है बहुत से लोगों के लिए भी ऐसा ही होगा। मुझे लगता है कि आउटपुट को परखने का मानदंड महत्वपूर्ण है। वह “कोड लाइनों की संख्या” नहीं, बल्कि “अच्छी गुणवत्ता वाली, maintainable, scalable, और आसानी से upgrade की जा सकने वाली कोड लाइनों की संख्या” होना चाहिए। इस मानदंड से देखें तो “पूरा repo बना दो” जैसी requests के नतीजे अर्थहीन कचरा होते हैं, लेकिन AI अगर getUser(... जैसे code को auto-complete कर दे, तो वह productivity बढ़ाता है। यह 0.1% बढ़ोतरी है, 1% है या 10%, यह मैं निश्चित रूप से नहीं कह सकता

• मेरी नज़र में सबसे गंभीर समस्या यह है कि जिन समस्याओं पर मैं अभी कंपनी में काम करता हूँ, वे बहुत सावधानी से planning और execution मांगती हैं, और वहाँ AI बिल्कुल मदद नहीं करता। लेकिन हमारे manager ने कहा कि “हम AI-first company हैं”, इसलिए project delivery time को पहले के estimate के 20% तक घटा दिया गया है। SVP और PM के बीच इस तरह की सामूहिक सनक बहुत तेज़ी से फैल रही है, और ऐसा मैंने पहले कभी नहीं देखा

  • Manager ने कहा कि project deadline को मूल estimate के 20% तक घटा दिया गया है, और मुझे यह सच में बेहूदा लगता है। कोई बस ऐसे ही अवास्तविक संख्या तय कर देता है और उसे हक़ीक़त बना देता है। आखिर में जब यह नहीं होगा, तो उसका दोष मुझ पर डाला जाएगा, और ऊपर वाले उस manager से जवाब मांगेंगे। अगर AI से सच में productivity बढ़ती है, तो अनावश्यक developers को बाद में हटाया जा सकता है, लेकिन वह तब होना चाहिए जब LLM development process में सफलतापूर्वक जगह बना ले। अब तो यह भी सोचने लगा हूँ कि AI bubble के लिए तैयारी करते हुए S&P 500 से investment निकाल लूँ या नहीं
  • अगर incident response तक LLM को सौंपा जा सकता है, तो CEO जैसा चाहता है वैसा करने दिया जाए, और उससे होने वाला reputational नुकसान भी सह लिया जाए। अगर वह fail हो जाए, तो बस git को उस point पर reset कर दिया जाए जहाँ LLM द्वारा लिखा code आने से पहले था। आधा मज़ाक, आधा गंभीर हूँ
  • AI का मौजूदा स्तर developers को replace करने लायक नहीं है, लेकिन मेरा मानना है कि यह इतना अच्छा ज़रूर हो गया है कि पहले जिन office tasks या manager roles को automate करना मुश्किल था, उनमें से कई को automate कर सकता है। Google ने वास्तव में AI की वजह से middle management को काफ़ी घटाया है, और developers को उतना नहीं घटाया लगता
  • AI उन managers के लिए बहाना बन रहा है जिनके पास technical leadership की कमी है, ताकि वे developers पर दबाव डाल सकें

• कई बातें एक साथ सच हो सकती हैं। LLM किसी random चुने गए सामान्य काम पर developer productivity को 10 गुना नहीं बढ़ाता। दूसरी ओर, कुछ खास तरह के कामों में LLM productivity को नाटकीय रूप से बढ़ा देता है। इसे busywork automate करने में भी इस्तेमाल किया जा सकता है; भले ही वास्तविक समय में यह इंसान से ज़्यादा देर ले, लेकिन क्योंकि यह background में चलता रहता है, इसलिए समस्या नहीं बनता। नई API या library सीखने में LLM रफ़्तार बहुत बढ़ा देता है, और किसी अनजान भाषा में छोटा-सा glue code लिखना हो तो समय बचाता है और बेकार की learning से भी बचा लेता है, इसलिए बहुत मददगार है। बड़े existing codebase के maintenance work में मुझे कोई खास productivity फ़र्क महसूस नहीं होता। नई website scaffolding setup करने में LLM हैरान कर देने जितना अच्छा है। mock classes लिखना भी, और mock library का usage समझकर वह जटिल काम करना भी, जिसे मैं एक-दो बार करके भूल जाता हूँ, यह पल भर में कर देता है। नया codebase structure समझने में भी लगभग 70% तक संतोषजनक मदद करता है। जटिल तरह से डिज़ाइन किए गए project में HTTP routes कहाँ हैं या dependency injection functions कहाँ हैं, जैसे सवालों पर “ए Claude, auth से जुड़े functions कहाँ हैं?” पूछ लेना सुविधाजनक होता है। मेरा मानना है कि सही tool को सही काम में इस्तेमाल करना चाहिए

  • मैं इस बात से सहमत हूँ कि नई API या library सीखना LLM की वजह से बहुत तेज़ हुआ है, लेकिन चिंता यह है कि जब उसके जवाबों को गौर से देखते हैं और documentation ख़ुद पढ़ते हैं, तो पता चलता है कि वह conventions follow नहीं करता, सिर्फ़ साधारण examples निचोड़कर देता है, और कभी गलत features इस्तेमाल कर देता है जिससे काम करने का तरीका अजीब या अनावश्यक रूप से जटिल हो जाता है। पहले यह जादू जैसा लगता है, लेकिन अगर उस पर ज़्यादा भरोसा करें तो आसानी से यह भ्रम हो सकता है कि आपने वास्तव में चीज़ समझ ली है, जबकि ऐसा नहीं होता
  • “LLM background में busy repetitive tasks automate कर देता है” — इसका ठोस मतलब क्या है, यह जानने की उत्सुकता है। AI समर्थकों को साफ़-साफ़ और ठोस examples देने चाहिए कि असल में कौन-से कामों में यह सफल हो रहा है। इस तरह की धुंधली बातों से अब थकान होने लगी है
  • “LLM नई API और libraries जल्दी सीखने में मदद करता है” वाली बात ज़्यादा सटीक तब होगी जब इसे बदलकर “पहली बार किसी पहले से पुरानी library या API से सामना होने पर” कहा जाए। सचमुच नई libraries या tools में LLM कई बार ज़्यादा मददगार नहीं होता

• वीडियो में स्क्रीन पर code बरसता हुआ दिखता है, और “junior developers का खेल खत्म” जैसी बातों से आगे अक्सर कोई ठोस चीज़ नहीं होती। मुझे लगता है इसकी वजह अस्थिर economy और वह माहौल है जिसमें अतिशयोक्ति और बेचैनी भरी हुई है कि AI कोई उद्धारक बन जाएगा। सच है कि कभी-कभी AI से प्रभावशाली results मिलते हैं, लेकिन बुनियादी तौर पर अगर किसी के पास कुछ skill नहीं है, तो इसका कोई मतलब नहीं। शुरुआती से मध्यम स्तर के लोग social media पर बढ़ा-चढ़ाकर सफलता की कहानियाँ उड़ेलते रहते हैं। एक ऐसा माहौल बन रहा है जिसमें हर कोई अपने “AI superpower” को बचाए रखने के लिए मनोवैज्ञानिक और व्यावहारिक दोनों तरह से जूझ रहा है। आखिर में हमें बस उस पल का इंतज़ार है जब hype cycle किसी संतुलन बिंदु पर पहुँचेगी और फिर से अरबों डॉलर जलेंगे

  • मेरे अनुभव में, AI tools पूरी तरह खाली project, यानी blank canvas, पर सचमुच अच्छा प्रदर्शन करते हैं। जैसे नया React project बनाना हो, तो tool मुझसे तेज़ setup कर देता है। लेकिन असली work repository में यह लगभग बेकार है। यही कारण है कि AI tools demos और marketing में बहुत प्रभावशाली लगते हैं, लेकिन हक़ीक़त में सिर्फ़ निराशा छोड़ते हैं
  • जिज्ञासा है कि क्या इसे अच्छी तरह इस्तेमाल करने के लिए “इतना अनुभव होना चाहिए कि आप वही काम ख़ुद हाथ से कर सकें”, या AI tools और उनकी limitations की समझ होनी चाहिए, या फिर दोनों चीज़ें चाहिए
  • AI को लेकर बढ़ा-चढ़ाकर की गई बातें अक्सर ऐसी लगती हैं जैसे popular science media के वे लेख जो सतही research paper abstracts पढ़कर दावा करते हैं कि यह सब बस अब होने ही वाला है

• मेरे अनुभव में, AI कुछ छोटे-मोटे कामों में उपयोगी रहा है, जैसे छोटे refactoring या type definitions को automate करना, लेकिन उससे अधिक जटिल कामों में यह कई चीज़ें छोड़ देता था और दोबारा काम करना पड़ता था। भविष्य में शायद मैं अपनी बात बदलूँ, लेकिन हाल में ज़्यादा कम-अनुभवी engineers को बड़े features implement करने के लिए AI द्वारा दिए गए output को बिना आलोचनात्मक नज़र से “अच्छा code” मानते हुए ज़्यादा देख रहा हूँ। लेकिन ये code हमारे style guide और patterns follow नहीं करते, या पहले से उपलब्ध library इस्तेमाल करने के बजाय logic को शुरू से implement कर देते हैं, जिससे अंत में हमारे ऊपर maintain करने के लिए और code बढ़ जाता है। बाद में ऐसा भी होता है कि सब कुछ एक साथ करने वाला बहुत बड़ा PR आ जाता है

  • अगर बात पूरी तरह नए लिखे गए code की हो, तो कई बार सिर्फ़ 50 lines code के लिए बड़ी library खींच लाने से बेहतर है कि चीज़ खुद लिखी जाए। यह पहलू सकारात्मक है
  • इन code और libraries के अस्तित्व को समझ पाने वाली “discovery” अभी भी homework बनी हुई है, और टीम के लोग internal code को स्वतंत्र रूप से इस्तेमाल कर सकें इसके लिए documentation या search को LLM पर टिकाने के तरीके पर भी काम चल रहा है। internal library knowledge के एक जगह सिमट जाने की समस्या चिंता का विषय है
  • entry-stage development में स्थिति अलग हो जाती है। project के शुरुआती चरण में coding style या standards तय नहीं होते, इसलिए LLM का output टीम के लोगों की राय से बहुत अलग नहीं होता। सिर्फ़ demo stage तक code बना देना भी काफ़ी मूल्यवान होता है। कई projects को तेज़ी से demo stage तक ले जाना बड़ा boost है

• मैं यहाँ की बात से सहमत हूँ। AI इस्तेमाल करने पर भी productivity में कोई क्रांतिकारी उछाल नहीं देखा। मुझे लगता है कि अगर software engineer लगातार problem solving, judgement, और code लिखने का अभ्यास न करे, तो उसकी neural knowledge कमज़ोर पड़ सकती है। AI भविष्य में 2x या 10x productivity देने वाली technology है — यह वादा मुझे खोखला लगता है, और भले ही personal codebase में थोड़ी productivity बढ़ी हो, market में वास्तव में बेहतर products की release नहीं बढ़ी है। consulting करते हुए मैं अक्सर founders और CTOs को AI को ज़ोर से धकेलते हुए देखता हूँ, और नतीजा यह होता है कि वे code को ठीक से manage नहीं कर पाते और ज़्यादा chaos पैदा कर देते हैं। आजकल मैं engineering best practices स्थापित कराने के लिए advisor की भूमिका भी काफ़ी निभाता हूँ

  • ज़्यादातर technologies की तरह, अगर hands-on practice और repetition टूट जाए, तो आपकी sense blunt हो जाती है। जैसे बहुत समय बाद cycle चलाएँ तो शरीर का एहसास जंग खा जाता है, वैसे ही coding ability भी वास्तव में कमज़ोर होती है। मेरा मानना है कि IT engineering पर भी यही लागू होता है। यह सच में चेतावनी वाला संकेत है

• CEOs कहते हैं कि AI से मौजूदा developers की productivity 10 गुना बढ़ जाएगी, लेकिन अगर सच में ऐसा है, तो क्या फिर developers को बहुत ज़्यादा hire नहीं करना चाहिए? अगर उसी investment से productivity 10 गुना बढ़ रही है, तो स्वाभाविक रूप से उस “engine” में और पैसा झोंकना तर्कसंगत होगा। लेकिन ground पर तो ऐसा लगता है कि productivity वैसी ही है, बस labor cost कम करने की कोशिश हो रही है

  • जब profit margins गिरते हैं, तो आख़िरकार labor cost से ही value निचोड़ने की कोशिश होती है। AI की 99% appeal labor cost reduction है, और hiring उसका उल्टा रास्ता है। मैं भी AI productivity boost वाले दावों से सहमत नहीं हूँ, लेकिन यह बताना चाहता हूँ कि इस तरह की प्रेरणा मौजूद है
  • बहुत से C-level लोग शायद उम्मीद कर रहे हैं कि बची हुई workforce भी AI से replace हो जाएगी। वे “जल्द ही AGI आ जाएगा” वाले narrative को follow करते दिखते हैं। मैं ऐसा नहीं मानता, लेकिन अगर किसी का रुख वैसा है, तो developers को और hire न करने का logic समझ में आता है
  • लगता है आज “law of diminishing returns” के बारे में सीखने को मिलेगा। किसी organization में लगाए जा सकने वाले इंसानों और resources की एक सीमा होती है। ज़रूरत से ज़्यादा डालना निरर्थक होता है। layoffs बढ़ने की वजह यह है कि AI efficiency बढ़ा रहा है; जब एक इंसान का काम AI cover करने लगे, तो उसी अनुपात में hiring कम होती है। यह एक इंसान = एक AI वाला मामला नहीं है, बल्कि workload AI को ट्रांसफ़र होने से इंसानों की संख्या घटती है। लोगों की replacement पूरी तरह खत्म नहीं हुई है, लेकिन कितने इंसान चाहिए होंगे, यह नया demand-supply baseline बनेगा। creative talent की ज़रूरत हमेशा ज़्यादा रहेगी, लेकिन ऐसे लोग कम हैं। 100k~200k डॉलर salary चाहने वाले software engineers में कई ऐसे होते हैं जिन्हें यह भी नहीं पता कि वे कंपनी के कितने पैसे बचा सकते हैं। कभी-कभी लगता है कि school education ने creativity को मार दिया है। समस्या skill की कमी नहीं, बल्कि ख़ुद दिशा नियंत्रित करने या ideas पैदा करने की क्षमता की कमी है

• नए products की launch volume को देखने वाला यह विश्लेषण ताज़ा नज़रिए वाला लगा। तेज़ growth के बजाय मुझे भी लगा कि उम्मीद से बड़ा बदलाव नहीं हुआ। एक वैकल्पिक व्याख्या यह हो सकती है कि असल bottleneck code लिखना था ही नहीं; असली समय और मेहनत यह खोजने में लगती है कि क्या बनाना है और उसे वास्तविक platform पर चढ़ाना कैसे है। दूसरी तरफ़, मैं इस बात से भी सहमत हूँ कि AI tools का गलत इस्तेमाल करना बहुत आसान है। कभी लगता है “आख़िर समझ गया!”, और अगले दिन पता चलता है “अरे, मैं तो इसे एक और तरीके से गलत इस्तेमाल कर रहा था।” software development इतना मुश्किल क्यों है और productivity acceleration इतना कठिन क्यों है, यह 20 साल से ज़्यादा development करने के बाद भी मेरे लिए साफ़ नहीं हुआ

  • “code लिखना bottleneck नहीं था” वाली insight सच में दिल को छूती है। software में असली value “कठिन समस्याएँ” सुलझाने से आती है, और आसान समस्याएँ तो पहले से template की तरह हर जगह मौजूद हैं। LLM आसान समस्याएँ जल्दी निपटा देता है, लेकिन असली bottleneck अब भी “hard” समस्याओं में है। technology, business, और customers जैसी वजहों से वे कठिन समस्याएँ LLM से ठीक से सुलझती भी नहीं, और असली फ़ायदा भी वहीं है। दूसरी ओर, template बन सकने वाली आसान समस्याओं में LLM सचमुच productivity बढ़ाता है
  • software delivery में coding ख़ुद कभी bottleneck नहीं रही। AI का इस्तेमाल बस company downsizing का औचित्य बनाने या funding जुटाने के बहाने के रूप में हो रहा है
  • product development में repetitive user feedback, edge cases ठीक करना, जैसी समय लेने वाली प्रक्रियाएँ AI होने पर भी आसानी से छोटी नहीं की जा सकतीं। यह बात joelonsoftware.com के लेख से भी जुड़ती है कि अच्छा software बनने में 10 साल लगते हैं

• हम वही भविष्य अभी बना रहे हैं। सच कहूँ तो मेरी रफ़्तार 4~5 मई से बढ़नी शुरू हुई, जब agentic AI काफ़ी अच्छा हो गया। सिर्फ़ आज ही मैंने iMessage archive को website में export करने वाला एक CLI tool बनाया, और पहले जो काम कई हफ़्ते लेता, वह अब शायद एक-दो दिन में homebrew formula तक के साथ बन सकता है। iOS app पर भी प्रगति हाथ से coding करने की तुलना में बहुत तेज़ है, लेकिन मैं जानबूझकर धीरे चल रहा हूँ। वैसे, उस post का data 3~4 अप्रैल तक ही जाता है, और मेरे हिसाब से इसी बिंदु से generative AI ने coding में वास्तविक मदद करनी शुरू की। (मैं Copilot नवंबर 2022 से इस्तेमाल कर रहा हूँ)

  • हर बार जब यह बहस आती है, तो “तुमने अभी तक latest AI इस्तेमाल नहीं किया, इस बार सच में बहुत अच्छा हो गया है” वाली प्रतिक्रिया दोहराई जाती है — यह चौंकाने वाला है
  • मेरा अनुभव भी लगभग ऐसा ही है। मैं AI hype पर देर से चढ़ा, लेकिन हाल में आए नए models और tools के combination को इस्तेमाल करके मेरी राय बदल गई। मेरे आसपास बड़ी कंपनियाँ अब जाकर ऐसे tools के इस्तेमाल की अनुमति दे रही हैं, इसलिए मुझे लगता है कि वास्तविक productivity data में काफ़ी lag होगा और उसका असर बाद में दिखाई देगा। METR research को लेकर अफ़सोस भी है, और मैं चाहता हूँ कि productivity पर ऐसे meta-studies और आएँ
  • सहमत हूँ। agentic AI “traditional” AI से पूरी तरह अलग tool है। एक साल बाद लेखक का data और experiment कैसा दिखेगा, यह देखने की उत्सुकता है
  • जिस पल आप कहते हैं “AI अब जाकर तेज़ हुआ है”, वह भी सिर्फ़ 5 महीने पहले की बात निकलती है। AI की रफ़्तार में 5 महीने 6 साल जैसे बदलाव लगते हैं

• मैं कभी full-time developer था, फिर manager और CTO के रूप में काम करते-करते धीरे-धीरे hands-on development से दूर हो गया। जब दोबारा coding करने की कोशिश की, तो frameworks, APIs, languages, और बारीक tricks फिर से सीखना पहले रोमांचक लगता था, लेकिन अब चिढ़ पैदा करता है। लेकिन Claude Code जैसे tools और software design का अनुभव होने की वजह से, मेरे लिए पहले जैसे बड़े systems दोबारा develop करना संभव हो गया। मेरी productivity 20% नहीं बढ़ी, न ही 10 गुना हुई। बल्कि इसने मुझे वह काम फिर से करने लायक बनाया, जिसे मैं शुरू में करने ही नहीं वाला था, इसलिए मैं इसे productivity में अनंत बढ़ोतरी कहना चाहूँगा। अगर मैं development से प्रेम करने वाला high-skill developer होता, तो शायद ये tools मुझे सिर्फ़ परेशान करते, लेकिन जो लोग आम तौर पर develop नहीं करते, उनके लिए यह ठीक उल्टा है

  • वाह, बड़े systems को एक बार नहीं बल्कि कई बार फिर से develop किया — काश आप इसके detailed examples साझा करते
  • AI coding tools पर मेरा बड़ा सिद्धांत यह है कि ये वास्तव में समय को बहुत कम नहीं करते, बल्कि झुंझलाहट को बहुत घटा देते हैं। syntax, compiler, और repetitive कामों से जुड़ी बेकार की चिढ़ बच जाती है, जिससे दिमाग़ सच में महत्वपूर्ण चीज़ों पर लगाया जा सकता है। इसी वजह से जो काम पहले बहुत झुंझलाहट के कारण नहीं करता, अब वह भी कर लेता हूँ, और दफ़्तर से निकलने से पहले टहलने जाने के बजाय कुछ घंटे और desk पर बैठ सकता हूँ