LLM मेरे software engineering करियर को कमजोर कर रहे हैं, और मुझे समझ नहीं आ रहा कि क्या करूँ

 (human-in-the-loop.bearblog.dev)
9 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM-आधारित development tools design docs लिखने, implementation planning, code writing, और debugging तक में शामिल हो गए हैं, जिससे 10 साल में बनाई गई payments और financial backend विशेषज्ञता की अलग पहचान कमजोर पड़ रही है
  • financial/payments क्षेत्र का domain knowledge PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, और bank transfer idempotency जैसी अनुभव-आधारित विशेषज्ञता पर टिका था, लेकिन models ने system structure के जोड़-तोड़ को पकड़ना शुरू कर दिया और यहीं पहला झटका लगा
  • Claude Code, Codex, MCP, DataDog MCP आदि के साथ debugging automation बढ़ती गई; सिर्फ stack trace और Sentry context के आधार पर कुछ bugs हल होने लगे, और बाद में distributed systems bugs के 90% तक one-shot में सुलझने लगे
  • बची हुई धुरी code quality और architecture भी अब सिर्फ “taste” तक सीमित की जा रही है, और दुनिया ऐसे C·D grade codebases को स्वीकार करने की तरफ बढ़ रही है जिन्हें LLM संभाल सके, बजाय उन A·B grade codebases के जो इंसानों के पढ़ने के लिए बेहतर हों
  • लंबे समय की employability बचाने के लिए विशेषज्ञता को उन क्षेत्रों में ले जाना होगा जहाँ LLM आसानी से अच्छा प्रदर्शन नहीं कर पाते, लेकिन research roles में जाना रह रहे देश, आवेदन प्रतिस्पर्धा, पारिवारिक परिस्थितियों, और RSI की संभावना जैसी वजहों से सीमित है

करियर पृष्ठभूमि

  • 10 साल के पेशेवर अनुभव वाला software engineer, जिसने web frontend से शुरुआत की क्योंकि वहाँ debugging आसान थी, लेकिन बाद में backend में शिफ्ट किया
  • संयोग से finance, bookkeeping, और payment processing domain में software development role मिला, जहाँ Product Manager और stakeholders के साथ करीबी और ईमानदार रिश्तों में काफी autonomy मिली
  • PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, bank transfer idempotency जैसी domain knowledge जमा की
  • domain expert बनने की career strategy एक साफ विकल्प थी, खासकर ऐसे क्षेत्र में जहाँ domain experts की demand बढ़ने के संकेत थे

पहला स्तंभ जो टूटना शुरू हुआ: domain-specific knowledge

  • पिछले साल finance क्षेत्र की एक कंपनी में नौकरी बदली; पिछली कंपनियों में payments और finance के तत्व मजबूत थे, लेकिन वे पूरी तरह finance-केंद्रित कंपनियाँ नहीं थीं
  • नई कंपनी ने AI को पूरी तरह अपनाया, और पहले ही दिन ChatGPT और Claude Enterprise accounts दिए, साथ ही research, exploration, और coding में AI इस्तेमाल करने के लिए प्रोत्साहित किया
    • लेकिन शर्त यह थी कि production में जाने वाली हर code line को खुद review करना और उसकी जिम्मेदारी लेना होगी
  • पहला project एक बिखरे हुए legacy online payment system को फिर से बनाना था, और यह काम पहले के build experience की वजह से मिला
  • coding से पहले लिखे जाने वाले Design Docs ऐसे होने चाहिए थे जिन्हें engineers और Product Managers दोनों पढ़ सकें; वे deep technical analysis से ज्यादा architecture-focused documents थे
  • शुरुआती Design Docs बहुत कम AI मदद से लिखे गए; उस समय LLM को “stochastic parrots” कहा जाता था, हालांकि अब यह नज़रिया नहीं रहा
  • manager का feedback था कि code तो अच्छी speed से आ रहा है, लेकिन Design Docs लिखने में बहुत समय लग रहा है, इसलिए AI का ज्यादा इस्तेमाल करना चाहिए
  • उस समय models आज जितने अच्छे नहीं थे, लेकिन writing और decision-making speed बढ़ाने के लिए वे काफी उपयोगी थे
  • कई सालों में बनी implementation trade-offs, acquiring कैसे काम करता है, और double charging रोकने के लिए idempotency को कैसे structure करना है—इस ज्ञान की value वहीं से गिरती महसूस हुई
    • models को अभी भी tuning चाहिए थी, लेकिन वे system को structure करने के connections पकड़ पा रहे थे, और यही वह सबसे कठिन हिस्सा था जो आम तौर पर कई साल के practical experience के बाद दिमाग में बनता है
  • web पर मौजूद explainer articles, technical docs, और domain में technical tools लागू करने वाले blog posts की बड़ी मात्रा को देखते हुए लगा कि models इन्हें training data के रूप में absorb कर सकते हैं
  • उम्मीद बची थी कि इंसान debugging में आगे रहेंगे, और production race conditions तथा distributed systems debugging का अनुभव लंबे समय की employability की नींव रहेगा
विज्ञापन

दूसरा स्तंभ जो टूटना शुरू हुआ: debugging और distributed systems

  • LLM पहले documentation और implementation planning में अच्छे हुए, फिर code लिखने में भी मजबूत हो गए; 2025 की दूसरी छमाही में Claude Code hype और Codex आने के साथ यह रुझान और बढ़ा
  • उससे पहले भी रोज़मर्रा के unit tests लिखने के लिए LLM इस्तेमाल होते थे, लेकिन पूरे implementation का जिम्मा उन्हें देने जितना भरोसा नहीं था
  • code writing में ज्यादा AI लाना अगला स्वाभाविक कदम लगा, और क्योंकि coding जितना ही production shipping और user satisfaction पसंद था, यह स्वीकार्य अदला-बदली लगी
  • LLM code लिखने में सक्षम हो गए थे, लेकिन model या इंसान द्वारा छोड़ी गई गड़बड़ियों को debug नहीं कर पाते थे, इसलिए robots को orchestrate करने से भी बड़ी भूमिका बची हुई थी
  • MCP, agentic workflows, और Claude 4.5 आने के बाद debugging वाला आधार भी हिलने लगा
  • Claude 4.5 सिर्फ stack traces और थोड़े context से लगभग 60% bugs ठीक कर देता था, और ज़्यादातर मामलों में Sentry MCP enabled Sentry link ही काफी होती थी
    • कभी-कभी यह भरोसेमंद दिखने वाला लेकिन पूरी तरह गलत solution भी बना देता था
  • इस बिंदु पर मशीन पर शक करना बंद हुआ, और ऐसे bugs भी Claude Code ने एक बार में ठीक कर दिए जिन्हें पहले पूरा दिन लगाकर debug करना पड़ता
  • फिर 4.6, 4.7, GPT 5.5, Opus 4.8, और DataDog MCP आने के बाद CLI distributed systems bugs को one-shot में हल करने लगी
    • इसमें वे bugs भी शामिल थे जो पहले कभी हल नहीं हुए थे, वे bugs जिनके लिए दो दिन का full-time debugging चाहिए होता, और वे distributed systems bugs भी जिनमें distributed observability कमजोर थी
    • अजीब race conditions, अनपेक्षित corner cases, third-party integration issues, undocumented API edge cases—ऐसे bugs के 90% तक one-shot में हल होने लगे
  • अभी भी code review करने और robots को orchestrate करने वाले इंसानों की जरूरत है, इसलिए नौकरी बनी हुई है, लेकिन भूमिका एक commodity engineer जैसी हो गई है
  • finance/payments domain expertise, debugging intuition, और distributed systems knowledge अब ऐसे promptable knowledge में बदल गए हैं जिन्हें कोई और senior engineer LLM को orchestrate करके हासिल कर सकता है
  • जहाँ पहले सिखाया जाता था कि generalists और specialists दोनों की भूमिका होती है, अब market सबको generalist बनाने की दिशा में जा रहा है
    • अगर सब generalist बन जाएँ और demand उसका साथ न दे, तो generalists की कीमत गिरती है—और demand भी घट रही है

तीसरा स्तंभ जो अभी नहीं टूटा: code quality और architecture

  • अभी बचा हुआ स्तंभ code quality और software architecture है, जिसे आजकल “taste” कहकर छोटा किया जा रहा है
  • पूरे करियर में refactoring पसंद रही, अच्छे code को महत्व दिया, और sprint के भीतर इसके लिए समय negotiate किया
  • DDD, Hexagonal, Clean Architecture जैसे विषयों पर trade-offs और codebase structure पर चर्चा करना पसंद रहा
  • agents codebase को व्यवस्थित हालत में रखने के लिए बहुत कमजोर tools हैं
    • यदि उन्हें orchestrate न किया जाए तो circular dependency की समस्या जल्दी पैदा होती है
    • duplicate code जोड़ना, अनावश्यक comments डालना, pure functions और side effects को मिला देना, SOLID principles को नज़रअंदाज़ करना
    विज्ञापन
  • यह क्षमता इंसानों की employability बचाने वाला क्षेत्र हो सकती थी, लेकिन industry इसे “taste” शब्द में सीमित कर रही है और ऐसे संसार की ओर बढ़ रही है जहाँ code organization की अहमियत कम है
  • इंसानों की अब भी भूमिका है कि वे circular dependency graph वाले spaghetti codebases को रोकने के लिए agents को orchestrate करें
  • ऐसा F grade codebase नहीं चाहिए जहाँ कुछ ठीक करने जाओ तो सब टूट जाए, लेकिन C या D grade अब स्वीकार्य माने जा रहे हैं
  • A या B grade codebases की ज़रूरत कम इसलिए रह गई है क्योंकि codebases अब इंसानों से ज़्यादा LLM द्वारा संभाले जाने के लिए बनाए जा रहे हैं
  • अगर source code अब इंसानों नहीं बल्कि machines के पढ़ने के लिए लिखा जा रहा है, तो machines को ही primary audience मानना भी संभव हो जाता है
  • code quality और architecture knowledge की value भी गिर रही है, और books पढ़ने, hands-on practice करने, engineers से चर्चा करने, और ADR लिखने में लगाया गया समय बेकार होता महसूस हो रहा है

अब क्या किया जाए

  • फिलहाल तो लगता है कि नौकरी बची रहेगी, कम से कम मौजूदा कंपनी में, लेकिन लंबे समय का outlook अनिश्चित है
  • लंबे समय में, 10 साल—और non-professional experience जोड़ें तो उससे भी अधिक—लगाकर सीखी गई चीज़ों की value लगातार घटती दिख रही है
  • विशेषज्ञता का आखिरी स्तंभ भी अब “taste” तक सीमित हो गया है
  • लगभग 8 महीने पहले मौजूदा कंपनी में (कंपनी के अनुसार AI से असंबंधित) layoff हुआ था, और निकाले गए कई शानदार पूर्व सहकर्मी अब भी नौकरी खोज रहे हैं
    • उनमें से कई उसी समस्या से जूझ रहे हैं: सिर्फ domain expertise अब अलग पहचान नहीं देती
  • कंपनी अब फिर से कुछ roles के लिए hiring कर रही है, लेकिन domain familiarity अब मजबूत differentiator नहीं रही
    • पहले job postings “Software Engineer - Area” के रूप में होती थीं, लेकिन अब सिर्फ “Software Engineer” लिखा जाता है और team assignment offer accept होने के बाद होता है
  • उन बेहतरीन engineers के लिए, जिन्हें कभी deep domain experience बनाने का मौका नहीं मिला, यह बदलाव बेहतर job opportunities लेकर आया है
  • लेकिन वे बेहतरीन engineers जिन्होंने पूरी ज़िंदगी domain knowledge इकट्ठा की, अब उसी लेन में प्रतिस्पर्धा कर रहे हैं
  • लंबे समय की employability बचाने का एकमात्र विकल्प है domain expertise को उन क्षेत्रों में ले जाना जहाँ LLM आसानी से अच्छा प्रदर्शन नहीं कर पाते
  • university वापस जाकर mathematics, statistics, और advanced Machine Learning पढ़ने और frontier lab research roles के लिए apply करने का विकल्प भी विचार में है
    • जिस देश में रह रहे हैं वहाँ frontier labs नहीं हैं, और जो थोड़े बहुत research institutes हैं उनमें applicants की भीड़ है
    • पारिवारिक परिस्थितियों के कारण दूसरे देश जाना आसान नहीं है
    • और जब तक relocation संभव हो, तब तक RSI (recursive self-improvement) researchers को ही अनावश्यक बना दे—यह संभावना भी मौजूद है
  • स्थिति इतनी अनिश्चित लगती है कि woodworking के hobby को profession बनाने तक पर विचार हो रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • क्या? मैं पूरे दिन LLM को निर्देश देता हूँ, लेकिन वित्तीय उत्पादों की ज़िम्मेदारी लेने के लिए कभी सहमत नहीं होऊँगा
    पहला स्तंभ अब भी कायम है। हो सकता है लेखक अपनी खुद की क्षमता को न समझता हो, लेकिन वापस लौटाई गई PRs के सबूत देखते हुए मुझे पता है कि जब मैं उस क्षेत्र से बाहर जाता हूँ जिसे मैं गहराई से जानता हूँ, तो मैं अब यह भी नहीं पहचान पाता कि एजेंट बकवास कर रहा है या नहीं। यहाँ तक कि हमारे सबसे अच्छे एजेंट, जिन्हें लेखक के बताए distributed systems तक पहुँच भी है, अक्सर गलत होते हैं, उनका दृष्टिकोण संकीर्ण होता है, और वे बार-बार मूर्खतापूर्ण काम करते हैं। आखिर में टीम के इंजीनियरों की विशेषज्ञता ही चीज़ों को फिर पटरी पर लाती है

    • पहचान उजागर होने से बचने के लिए मैं थ्रोअवे अकाउंट से लिख रहा हूँ। मैं एक FinTech में काम करता हूँ जो regulated products बनाती है और मुझे Mythos की पहुँच है
      Mythos ने पूरे भरोसे के साथ कहा कि हमारे codebase का एक हिस्सा किसी खास regulation का उल्लंघन करता है, और यह भी कि अगर इसे मौजूदा तरीके से चलाया गया तो गंभीर जोखिम होगा। लेकिन यह सच नहीं था; उसने regulatory requirements ही hallucinate कर ली थीं। यह हमें इसलिए पता था क्योंकि उस code की पहले ही मानव legal counsel द्वारा समीक्षा हो चुकी थी। और कहा जाता है कि यही इस समय उपलब्ध state-of-the-art model है। कोड लिखने में मदद के लिए मैं generative AI का खूब उपयोग करता हूँ, लेकिन मध्यम अवधि में भी ऐसे tools पर निर्भर होकर compliance वाले financial products वास्तव में नहीं बनाए जा सकते। वह पूरी तरह पागलपन होगा। यह सही है कि बहुत-सी FinTech कंपनियाँ speed बढ़ाने के लिए agents का इस्तेमाल कर रही हैं, लेकिन अगर इंसान ने वास्तव में गहराई से जाँचा ही नहीं और उसके बावजूद product launch कर दिया, तो वे बहुत बड़ा जोखिम उठा रही हैं
    • आप कहते हैं कि “टीम इंजीनियरों की विशेषज्ञता चीज़ों को फिर पटरी पर लाती है”, लेकिन मैं कैसे निश्चित हो सकता हूँ कि मेरे सहकर्मी मुझसे बड़े विशेषज्ञ नहीं हैं?
      LLM से पहले ज़्यादातर कंपनियों में बेहतरीन इंजीनियर और औसत इंजीनियर साथ काम कर सकते थे। LLM के बाद शायद केवल “टॉप” इंजीनियर ही टिक पाएँगे। क्योंकि अब औसत इंजीनियरों की ज़रूरत नहीं रहेगी। HN की प्रकृति ऐसी है कि यह पढ़ने वाले ज़्यादातर इंजीनियर खुद को अपनी कंपनी/शहर/देश के हिसाब से top 10~5% में मानेंगे, इसलिए वे सोचेंगे कि वे उन “औसत” इंजीनियरों में नहीं हैं जिन पर LLM अपनाने का असर पड़ेगा। सांख्यिकीय रूप से देखें तो संभव है कि वे गलत हों। आखिरकार यह अहंकार का मामला है। बहुत संभव है कि आप कोई rockstar नहीं हैं, और अंततः LLM आपकी नौकरी ले सकता है। हमेशा की तरह जीतने वाले सिर्फ कंपनियाँ और executives होंगे, और हममें से ज़्यादातर लोग chain के सबसे नीचे हैं, इसलिए नुकसान हमें ही उठाना पड़ेगा
    • जटिल requirements वाले PRs में मैंने देखा है कि शुरुआती PR तक पहुँचने का समय बहुत कम हो गया है, लेकिन उसके बाद reviewer और developer के बीच पिंग-पोंग शुरू हो जाता है
      मेरे मामले में developer ने कुछ हिस्से vibe coding से लिखे थे, और requirements या अपने ही code की गहरी समझ न होने के कारण उसे ठीक करने के लिए कई बार दोहराव करना पड़ा। इसे आप मानव समस्या कह सकते हैं, लेकिन मुझे जो net effect दिखता है वह यह है: जटिल मामलों में पहले का “काफी लंबा PR लिखने का समय + काफी लंबा review समय” अब “बहुत छोटा PR लिखने का समय + और लंबा review समय” बन गया है। मुझे नहीं पता कि ऐसे मामलों में वास्तविक फायदा है भी या नहीं। कभी-कभी code कार्यात्मक रूप से सही होता है, लेकिन उसमें बीच के functions बहुत ज़्यादा होते हैं, जिससे वह अनावश्यक रूप से verbose हो जाता है, और लगता है कि इसका असर आगे की reviews पर पड़ेगा
    • दुर्भाग्य से software से जुड़ा पूरा उद्योग LLM/code generation को अपना रहा है। बैंक, FinTech, insurance—सब
      मुझे भी यही चिंता है, लेकिन अक्सर इसे इस तरह टाल दिया जाता है या गोलमोल कर दिया जाता है कि “delivery speed और ROI इसकी कीमत वसूल कर देते हैं, इसलिए चिंता मत करो”
    • मुझे नहीं पता कि “मैं पूरे दिन LLM को निर्देश देता हूँ, लेकिन वित्तीय उत्पादों की ज़िम्मेदारी लेने के लिए कभी सहमत नहीं होऊँगा” जैसी बात किसी खास employer में और कितने समय तक टिकेगी
      जिन भी FinTech कंपनियों से मेरा व्यक्तिगत तौर पर सामना हुआ है, उन सबके पास पिछले साल से developers के लिए किसी न किसी तरह का AI account था। Jane Street जैसी जगहों पर भी कर्मचारियों ने ब्लॉग पोस्ट लिखकर कहा है कि वे ज़्यादातर agents को निर्देशित करते हैं। आपको क्या लगता है, आपकी कंपनी और कितने समय तक टिक पाएगी?

  • मैं अक्सर ऐसे कमेंट देखता/देखती हूँ कि “AI, X को 80~100% सटीकता से नहीं कर सकता, इसलिए हमारी नौकरियाँ सुरक्षित हैं”
    मैं ज़रूरत से ज़्यादा निराशावादी नहीं लगना चाहता/चाहती, लेकिन मॉडल बहुत तेज़ी से बेहतर हो रहे हैं। अगर लगभग 3 साल पहले कोई आज की स्थिति समझाते हुए कहता कि “एक मॉडल एक ही prompt से लगभग 30 मिनट में पूरा MVP app बना देता है,” तो यह science fiction जैसा लगता। अभी मॉडल जिन बाधाओं से जूझ रहे हैं—जैसे hallucination rate कम करना, compliance की गारंटी देना, साफ़-सुथरा codebase बनाए रखना—वे भी ऐसे नहीं लगते कि उनका समाधान बहुत दूर हो। खास जानकारी लाना भी कई MCP server/RAG के ज़रिए पहले से आंशिक रूप से संभव है। मुझे software engineer के भविष्य की चिंता है। जब ये खामियाँ हल हो जाएँगी, तब यह पेशा कहाँ टिकेगा? AI model को काम delegate करने वाली भूमिका? दुर्भाग्य से, यह कई साल की विशेषज्ञता नहीं माँगता, इसलिए यह दोधारी तलवार है। AI output की review? बस उससे हर वह लाइन समझाने को कह दीजिए जो समझ में न आए। जैसे human computers को digital computers ने replace कर दिया, वैसे ही मुझे लगता है कि हम layoff की बड़ी लहर और देखेंगे। दिमाग़ से जटिल गणित करना एक मज़ेदार चुनौती हो सकता है, लेकिन वह computer से कहीं धीमा और ज़्यादा त्रुटिपूर्ण है। उसी तरह हाथ से code लिखना भी एक मज़ेदार “चुनौती” बन जाएगा, और AI आधुनिक calculator जैसा लगेगा

    • मैं ज़ोर देकर कहूँगा/कहूँगी कि यह छोटा clip ज़रूर देखें
      https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
    • यह बात पूरी तरह सही है कि मॉडल तेज़ी से बेहतर हो रहे हैं, और 3 साल पहले आज की स्थिति science fiction जैसी लगती
      बहुत-सी चीज़ें आगे भी काफ़ी सुधरेंगी। लेकिन तकनीक से पैदा हुई तेज़ उथल-पुथल के आधुनिक इतिहास को देखें तो एक दोहराता हुआ पैटर्न दिखता है। हिमस्खलन या अचानक आई बाढ़ की तरह, ऐसे तेज़ बदलाव अक्सर किसी खास तकनीक में एक या अधिक अहम breakthrough से शुरू होते हैं। शुरुआती बदलाव की रफ़्तार तेज़ और उग्र होती है, लेकिन जैसे-जैसे आसानी से मिलने वाले अवसर खत्म होते हैं और नए क्षेत्र में नई रुकावटें व friction सामने आते हैं, यह धीरे-धीरे मंद पड़ती है। ऐसे दौर की शुरुआत में, हाल की असामान्य बदलाव-दर को सीधे भविष्य तक extrapolate करना आम तौर पर कम भरोसेमंद होता है। अचानक हुए चरम विस्फोट अक्सर लंबी अवधि की trend line पर वापस लौटते हैं। मौजूदा LLM उथल-पुथल को इस रूप में देखा जा सकता है कि 2010 के बाद का शोध 2017 के Transformer paper पर आकर जमा हुआ, और उसने आसपास के शोध को तेज़ी से आगे बढ़ाया। अगर ऐसा है, तो हम अभी LLM के तेज़ विस्फोट चरण के मध्य या अंतिम हिस्से में हो सकते हैं। सभी LLM applications को ऊपर उठाने वाले बुनियादी और व्यापक breakthrough की रफ़्तार साफ़ तौर पर धीमी हुई है, और हाल की कई high-impact खोजें किसी खास क्षेत्र की scaling, optimization, tuning, और productization की ओर रही हैं। इसका मतलब यह नहीं कि कल कोई Transformer-स्तर का breakthrough फिर नहीं आ सकता, लेकिन ऐतिहासिक रूप से black swan झुंड बनाकर नहीं चलते
    • आपको क्यों लगता है कि बात developer layoffs पर रुक जाएगी? अगर software कंपनियाँ अपना business चलाने के लिए LLM providers पर निर्भर हो जाती हैं, तो मुझे लगता है कि on-premises products से लेकर SaaS तक, दुनिया भर में इन कंपनियों का बड़े पैमाने पर पतन देखने को मिल सकता है
      ग्राहक आज की तरह software tools खरीदने के बजाय, अपनी ज़रूरत का सारा software खुद अंदर ही बना सकते हैं, या prompt engineering consultants से बनवा सकते हैं। यह बहुत अलग दुनिया हो सकती है
    • AI के 100% तक पहुँचने के समय को लेकर आपकी थ्योरी क्या है? क्या PM और business analysts ही सारा software बनाएँगे?
      या फिर पूरी दुनिया में बस करीब 700 one-person founder कंपनियाँ होंगी और बाकी सब काम नहीं कर पाएँगे? Matrix है क्या?
    • अगर आपको लगता है कि मॉडल उस स्तर तक बेहतर हो रहे हैं, तो यह कुछ हद तक भ्रम जैसा है
      Claude 3.5 आने के बाद से productivity इतनी ज़्यादा नहीं बढ़ी है। मेरे पास सभी LLMs की unlimited access है, लेकिन ज़्यादातर बेकार हैं, और वे जितना बचाते हैं उससे ज़्यादा काम पैदा करते हैं। इस tool से फ़ायदा सिर्फ़ वही लोग उठा रहे हैं जो low-quality output तेज़ी से उगलना चाहते हैं। अगर आप सहमत नहीं हैं, तो आप भी ऐसे ही व्यक्ति हैं

  • मेरा करियर पथ लेखक से हैरान करने वाली हद तक मिलता-जुलता है। अजीब बात यह है कि लेखक जिस हिस्से को ढहे हुए पहले स्तंभ के रूप में देखता है, वही अभी सबसे ज़्यादा ठीक-ठाक दिखता है
    LLM हमारे बिज़नेस की विशिष्टताओं में बार-बार विफल होता है। जैसे स्थानीय tax law, accounting procedures की बारीकियां, और हमारे ledger implementation की खासियतें। Refactoring, भाषाओं के बीच conversion, और मौजूदा code में bug tracking के लिए यह शानदार है, लेकिन हमारे domain को दोहराने और विस्तार देने में इसमें हमेशा बहुत-सी सूक्ष्म गलतियां रह जाती हैं। हो सकता है ऐसा इसलिए हो क्योंकि जिन कंपनियों में मैंने काम किया, वे moat बनाने के लिए जानबूझकर जटिल क्षेत्रों से निपटती थीं। ऐसी कंपनियां जिनका बिज़नेस इसलिए चलता है क्योंकि दुनिया में ऐसी कोई किताब नहीं है जिससे उसकी copy बनाई जा सके, और know-how अंदर ही अंदर बना रहता है। और अगर कोई FinTech manager design docs जल्दी बनाने के लिए AI इस्तेमाल करने की सलाह देता है, तो पैसे संभालने वाला बिज़नेस चलाने के लिए वह बहुत लापरवाह लगता है। खासकर जब छोटे-छोटे लेनदेन बड़ी मात्रा में होते हों, तब लाखों की रकम का गलत allocation होना बहुत आसान है। ऐसे bugs से निपटना सचमुच बहुत मुश्किल होता है। Logic fix करना सिर्फ पहला कदम है; उसके बाद immutable database में गलत तरीके से calculate हुए data को ठीक करना होता है, regulatory procedures और customer communication संभालने होते हैं। Fixes खुद नए features और observability के लिए ध्यान रखने वाले pitfalls बन जाते हैं। जैसे, “याद रखो कि 2 फ़रवरी के data में जो spike दिख रहा है, वह X incident की वजह से है”

    • जब सचमुच कुछ ऐसा बनाया जा रहा हो जो पहले कभी बना ही न हो, तब LLM को architecture decisions नहीं सौंपे जा सकते
      मैं कई physics simulation-आधारित products बना रहा हूँ, और वे पूरी तरह first principles पर आधारित हैं। लेकिन अगर इसे active research, सोच और validation के बिना छोड़ दिया जाए, तो यह सैकड़ों orders of magnitude धीमा computational code बना देता है, और बेहूदा alternate paths और shortcuts जोड़कर आखिर में बेकार computation तैयार कर देता है। ऐसा शायद लगभग 95% मामलों में होता है। Supervision बहुत महत्वपूर्ण है, और architectural thinking अभी outsource नहीं की जा सकती। जो outsource किया जा सकता है, वह सिर्फ execution है
    • स्थानीय tax law, accounting procedures, और ledger implementation की विशिष्टताएं domain expertise हैं, और इनके लिए software engineer का होना ज़रूरी नहीं है
      बेशक, senior software engineers अक्सर इनमें expert होते हैं, लेकिन यह अनिवार्य नहीं है। पारंपरिक रूप से, अगर engineer बिना business expert से पूछे काम का लगभग 90% संभाल सके तो frictionless production के लिए यह उपयोगी था, लेकिन मूल लेख का मुख्य बिंदु यही है कि वही “परंपरा” अब खत्म हो गई है। नई दुनिया में senior engineer का काम खुद वह domain expertise रखना नहीं है, बल्कि agent को वह expertise दिलाना या हासिल करवाना है, और यह सुनिश्चित करना है कि वह सत्यापन योग्य रूप से सही हो। जो senior engineers यह सोचकर चिपके रहेंगे कि गहरी business domain expertise उन्हें सुरक्षित रखेगी, वे भी उतनी ही जल्दी dead end पर पहुँचेंगे जितनी जल्दी वे junior engineers जो बदलाव नहीं कर पाए
    • मैं Claude या GPT-5 से आम use cases के लिए भी consistently अच्छे flowcharts नहीं बनवा पाता। Domain-specific चीजों की तो बात ही छोड़िए
      इनके पास गहरी vocabulary होती है, इसलिए ये जितना वास्तव में जानते हैं उससे ज़्यादा जानकार लगते हैं। Code लिखना और दिखाई देने वाली errors को debug करना ये बहुत अच्छी तरह करते हैं, लेकिन उसमें भी आधी सफलता test harness की वजह से होती है
    • Product features और उन regulations के बीच, जिन्हें उन features में reflect होना चाहिए, LLM की मदद से साझा समझ बनवाने की तकनीक उपयोगी हो सकती है
      मुख्य विचार यह है कि documents LLM को दिए जाएँ, और LLM बहुत सारे सवाल पूछकर ambiguity और संभावित misunderstandings दूर करे। Skills को एक बार देखना चाहिए। यह सचमुच मददगार है। https://www.youtube.com/watch?v=6BB6exR8Zd8
    • हमारी कंपनी भी बहुत-सी जटिल regulations और domain-specific system implementations पर काम करती है, और पहले AI यहाँ संघर्ष करता था
      हमने एक अच्छे से व्यवस्थित claude.md/agents.md फ़ाइल के साथ इस समस्या को हल किया। हमने इसमें supermemory.ai भी implement किया, ताकि नए लिए गए decisions हर बार नया session शुरू होने पर AI agent को हमेशा याद रहें

  • Steve Jobs का कुख्यात कथन “ideas are cheap” मुझे हमेशा याद आता है
    execution ही सब कुछ है, और अगर frontier LLM execution की समस्या हल कर दें, तो अब ideas समृद्धि का प्रवेश-द्वार बन जाते हैं। लेकिन समृद्धि अपने-आप में “बनाए रखने की ताकत” की गारंटी नहीं देती। जिस बात को अक्सर नज़रअंदाज़ किया जाता है, वह है किसी काम में टिके रहने की इंसानी इच्छा और उसकी परवाह। बहुत से लोग किसी चीज़ को बनाने, बनाए रखने और उसका मालिकाना रखने जितनी परवाह नहीं करते या ऐसा चाहते ही नहीं। V1 शायद जल्दी ship हो जाए, लेकिन क्या आप उसे लगातार आगे बढ़ा सकते हैं? इसका अच्छा उदाहरण AI music tool Suno में दिखता है। अब यह काफ़ी अच्छे results देता है। बहुत से लोग अपनी-अपनी छोटी दुनिया बनाकर उससे थोड़ी देर खेलते हैं, फिर जल्दी थककर चले जाते हैं, और केवल कुछ बहुत उत्पादक creators बचते हैं जो उसे “काम जैसा” माहौल बना देते हैं। delegation और execution का scale और economics बदल गया हो सकता है, लेकिन सोचने के लिए अब भी बहुत कुछ है

    • मैंने Suno थोड़ा इस्तेमाल किया है, लेकिन मैं इस बात से सहमत नहीं हूँ कि यह “वाकई अच्छे results देता है”
      संगीत की मेरी समझ सीमित है, फिर भी मुझे ऐसा लगता है, इसलिए संगीतकार शायद और भी ज़्यादा आलोचनात्मक होंगे। पहली कुछ बार यह प्रभावशाली लगता है, और melodies भी catchy होती हैं। पहले background में चीज़ें अजीब सुनाई देती थीं, लेकिन उनमें से ज़्यादातर ठीक हो चुकी हैं। लेकिन दर्जनों गानों के बाद सब कुछ हमेशा एक जैसा लगने लगता है। सब कुछ generic है, गाने कोई कहानी नहीं बताते, और ऐसा महसूस होता है जैसे corporate विज्ञापनों के पीछे बजने वाला music हो। prompt को और सटीक लिखने पर भी ज़्यादा फ़र्क नहीं पड़ा, और गाने को दिलचस्प बनाने वाले details को यह ज़्यादातर नज़रअंदाज़ कर देता है। सबसे दिलचस्प results तो तब मिले जब मैंने उसे bug की तरह पटरी से उतार दिया। मैंने उससे दो बहुत अलग genres मिलाने को कहा, तो ऐसा बेचैन-सा result आया जैसा मैंने पहले कभी नहीं सुना था। लेकिन उस पर आगे काम करना हमेशा मुश्किल रहता है, और वह बार-बार generic नतीजों की तरफ लौटने की कोशिश करता है तथा detailed निर्देशों को अनदेखा करता है। Suno remix कर सकता है। यह code जैसा ही है। LLMs पहले से काम कर रही किसी चीज़ को दूसरी language में चलने लायक ले जाने वाली porting में बहुत अच्छे हैं। लेकिन अगर आपके पास सिर्फ idea हो, तो वे originality वाले हिस्से में विफल हो जाते हैं। LLM से idea को ठीक से implement कराने के लिए आपको इतने ज़्यादा निर्देश देने पड़ते हैं कि natural language की ambiguity से लड़ते-लड़ते बात लगभग ख़ुद code लिखने जैसी हो जाती है
    • frontier LLM execution को “हल” नहीं करते
      अगर आप काफ़ी ज़ोर लगाएँ, और आपके पास ऐसा system हो जो सच में काम करने वाला code निकलवा सके, तो execution की समस्या हल की जा सकती है। लेकिन वही तो engineering है। अभी की default state में यह engineering को replace करने से बहुत दूर है। 3 साल बाद शायद यह संभव हो। चीज़ें तेज़ी से बदल रही हैं। लेकिन आज के दिन आप बस “मुझे एक बेहतर Rust compiler बना दो” कहकर कुर्सी पर पीछे नहीं टिक सकते और result का इंतज़ार नहीं कर सकते
    • Suno एक अच्छा उदाहरण है। मैंने बहुत से गानों के lyrics लिखे और Suno से उन्हें “produce” किया, लेकिन मनचाही sound पाने तक दर्जनों से लेकर सैकड़ों remix/cover/extension revisions करने पड़े या editor में बहुत समय लगाना पड़ा
      गाने मुझे पसंद हैं और playlist में सुनने लायक हैं, लेकिन Suno algorithm पर उन्हें कोई बड़ा response नहीं मिला। मैंने उन्हें दूसरी जगहों पर भी ज़्यादा promote नहीं किया, और जब post किया भी तो बस कुछ likes मिले। मुझे निराशा नहीं हुई। मैंने संगीत अपने लिए बनाया था, और share करना उसका side effect था। इससे मैंने यह सीखा कि लोगों को मेरी बनाई चीज़ में दिलचस्पी लेने और उसका आनंद लेने लायक बनाना बहुत काम माँगता है। आपको marketing करनी पड़ती है, लोगों के सामने ले जाना पड़ता है, और उनका ध्यान खींचना पड़ता है। मुझे यह भी यक़ीन है कि आपको उसे video, कहानी, persona, किसी vibe जैसी चीज़ों से जोड़ना पड़ता है ताकि लोगों के पास उसे पसंद करने की वजह हो। उसे “चिपकाने” के लिए आपको वही सब कुछ उसी audience के सामने बार-बार दोहराना पड़ता है, ताकि वे उससे परिचित हों। इसलिए persistence चाहिए, और आपको सच में इस बात की परवाह होनी चाहिए कि आप किसे बेचने की कोशिश कर रहे हैं। लोगों के जुड़ने से पहले मुझे ख़ुद जुड़ा रहना होगा
    • https://x.com/chamath/status/2033385903520129161
      https://en.wikipedia.org/wiki/Sturgeon%27s_law
      Sturgeon का नियम कहता है, “हर चीज़ का 90% कचरा होता है।” यह उक्ति अमेरिकी science fiction लेखक और आलोचक Theodore Sturgeon ने अपनी genre की अहमियत का बचाव करते हुए दी थी। Sturgeon का मानना था कि किसी भी क्षेत्र में अधिकांश काम निम्न गुणवत्ता का होता है, इसलिए सिर्फ science fiction को ही अलग से घटिया नहीं कहा जा सकता
    • क्या आप AI music tools के बारे में थोड़ा और समझा सकते हैं?
      मेरी धारणा यह है कि इनका इस्तेमाल one-shot generation tools की तरह होता है। मुझे music की ज़्यादा समझ नहीं है, लेकिन कलाकारों को शायद intermediate stages, track separation, instrument customization और ऐसी कई चीज़ें चाहिए होती होंगी जिनके बारे में मैं नहीं जानता। अगर ये न हों, तो मुझे लगता है कि professional काम में इनका इस्तेमाल मुश्किल होगा

  • मैं इस पोस्ट से पूरी तरह सहमत नहीं हूँ। vibe coder मध्यम जटिलता वाले systems को design, develop और implement करते हुए सब कुछ उड़ा देने से नहीं बच सकता
    Claude जैसे application का अच्छी तरह इस्तेमाल करने का एक बड़ा हिस्सा computer science concepts की वैचारिक समझ और अनुभव है। vibe coder के पास ये चीज़ें कभी नहीं होतीं। अगर होतीं, तो वे vibe coder ही नहीं होते

  • “मुझे नहीं पता क्या करना है” तो लहर पर सवार हो जाओ
    जब websites/webapps लहर थे, तब भी हम उसी पर सवार हुए थे। मैं internet से पहले software industry में आया था और तब से लगातार घोड़े बदलता रहा हूँ। नई technology सीखने के लिए कभी बहुत देर नहीं होती। नई लहरें नए तरह के काम और workers बनाती हैं। उनमें से एक बन जाओ। इस जानवर की सवारी करो, tools में mastery हासिल करो। वही खेल फिर से लौटा है

    • सहमत
      अगर कोई skill लगातार demand में रहती है, तो वह है अपने दिमाग में चीजों को structure करने की क्षमता — चाहे वह नया काम हो, नया process हो, या नए लोग। मैंने prototype machinist के रूप में काम करते हुए इस क्षमता को एक तेज़ tool की तरह समझा और विकसित किया। जो लोग परिचित नहीं हैं, उनके लिए prototype machinist वह व्यक्ति है जो हर हफ्ते छोटे schedule के भीतर मुश्किल parts बनाने के लिए जो भी ज़रूरी हो, वह कर देता है। metal, plastic, जो भी हो। आप processes, machine tools, materials से जल्दी परिचित होना सीख जाते हैं। कुछ समय तक ऐसा करने पर आप नई information बहुत तेज़ी से absorb करने लगते हैं, और बहुत से लोगों की तुलना में काम को कहीं तेज़ और अधिक सटीक तरीके से समझ पाते हैं। कोई भी इसकी शुरुआत कर सकता है। जिज्ञासु बनो और कुछ बनाओ। फिर और बनाओ। जो बनाया है उसे साझा करो, और वह बनाओ जो दूसरे लोग चाहते हैं
    • कुल मिलाकर समाज अधिक अस्थिर लगता है, लेकिन मूल रूप से वही गीत और नृत्य फिर दोहराया जा रहा है
      90s और 00s में “object-oriented programming सब कुछ बदल देगी” वाली लहर थी। पहले जो काम सैकड़ों बार सफलतापूर्वक किए गए थे, अब उन्हें object-oriented तरीके से किया जाने लगा। airplane से जुड़ा code लिखना है? college में मैंने सचमुच यह सुना था कि बस एक सर्वशक्तिमान airplane object खरीद लो जो airplane की हर चीज़ कर दे। लेकिन क्या object orientation सर्व-समाधान नहीं निकला? फिर code generation आया, Ruby on Rails चलाकर देखो। 2 सेकंड में website बन जाएगी। code generation हर जगह था। बात अजीब दिशाओं में गई, फिर TDD आया। मैंने सचमुच ऐसी बातचीत देखी है जिसमें कहा गया कि अगर तुम TDD नहीं करते तो तुम्हें जेल में डाल देना चाहिए क्योंकि तुम इतने बुरे engineer हो। नहीं, TDD नहीं, BDD ही समाधान है, ऐसा कहा गया। Lean, नहीं Agile, नहीं lowercase agile, लेकिन शुरुआत वही थी, नहीं Scrum, नहीं XML, रुको वह तो पिछले 10 साल की बात थी, JSON, और आखिर में SAFe। और अब बात है, “यह chatbot देखा क्या?”। हर चक्र, अगर ध्यान दो, तो कुछ अच्छी चीज़ें लाता है। लेकिन साथ में बहुत hype और anxiety भी लाता है। प्रयोग करो और सीखो। एक चीज़ जो मेरे लिए नहीं बदली, वह यह है कि लगभग हर कोई अपने सपने सच होने के नतीजों पर गंभीरता से सोचने की बजाय मरना पसंद करेगा। जब तक यह सच है, लोग अपने लिए बढ़ा-चढ़ाकर पेश किए गए trend के dragon पर सवारी करने के लिए किसी न किसी को पैसे देते रहेंगे
    • “tools में mastery हासिल करो” कहते हो, लेकिन इन tools की value proposition ही यह है कि इनमें कोई skill stack या mastery है ही नहीं
      यह पूरा low-quality output factory flow, या कहें “AI native” flow, कुछ ऐसा है। “वाह, मैंने chatbot को मना लिया कि वह मेरे लिए वह चीज़ बना दे जिसे मैं बिल्कुल नहीं समझता। मैं अपना काम कितनी अच्छी तरह करता हूँ!” यह कुछ बनाने के participation trophy जैसा है। कुछ और चीज़ बनाती है, और श्रेय मैं ले लेता हूँ जबकि मुझे खुद ठीक से समझ भी नहीं होता। मेरी मेहनत पर कोई compounding return नहीं है। कोई lesson learned नहीं है। कोई understanding build नहीं होती। future innovation की ओर ले जाने वाली कोई insight नहीं है। कोई differentiation नहीं है। बस सुन्न कर देने वाली हद तक खाली जगह में चिल्लाते रहो, और जब slot machine “काफी अच्छा दिखने वाला” low-quality मिश्रण उगल दे, तो अगले दिन फिर वही दोहराओ। अगर यही खेल है, तो मैं बाहर हूँ। अच्छा है कि दूसरे लोग इसे enjoy करते हैं, लेकिन यह सोचना कि इसमें कोई mastery है, भ्रम है। इस tool के साथ “successful” होने की एकमात्र शर्त है कि परवाह करना बंद कर दो और आत्मसमर्पण कर दो

  • यह पहले भी पोस्ट किया था, लेकिन दोबारा पोस्ट करने लायक है
    मैं एक ऐसी company में DevOps का काम करता हूँ जो LLM इस्तेमाल करने में बहुत आक्रामक है। चरण लगभग ऐसे थे। LLM से “बहुत सी चीज़ें” करवाना, उससे और ज़्यादा करवाना, कई agents चलाना, फिर वापस single agent पर आना लेकिन उससे tools बनवाना, और फिर ऐसे deterministic tools पर जाना जिन्हें इंसान और LLM दोनों इस्तेमाल कर सकें। वजह यह थी। deployment और testing दोनों में deterministic tools binary answers देते हैं और repeatable होते हैं। failure आने पर हमेशा ऐसे tool पर वापस लौटा जा सकता है जिसे कोई इंसान चला सके। वे तेज़ भी हैं। simple scripts 30 सेकंड से कम में चल जाती हैं, लेकिन “plausible bullshit” में हमेशा 2–3 मिनट लगते थे। आखिरकार बात फिर इसी लेख पर आकर टिकती है। https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 यानी “task list बनाओ, हर task के लिए script लिखो, scripts को functions में जोड़ो, और functions ही system बन जाते हैं”। जोड़ना चाहूँगा कि अगर LLM को खुला छोड़ दो, तो वह खुशी-खुशी code बना देगा। आप tests जोड़कर यह verify कर सकते हैं कि tests काम कर रहे हैं। पहले भी हम human-written code के साथ यही करते थे। code पढ़ा भी जा सकता है। code पढ़ने पर पता चलता है कि वह working code बनाते हुए भी कभी-कभी पूरी तरह पागलपन कर देता है। इंसान भी ऐसा करते हैं, लेकिन वह अलग बात है। अंत में आपको अब भी यह verify करना पड़ता है कि जो system बन रहा है, उसका कोई मतलब बनता है या नहीं। और सरल शब्दों में, coding मर चुकी हो सकती है, लेकिन software engineering अभी भी ज़िंदा है और अच्छी तरह दौड़ रही है

    • यही सही तरीका है
      बड़े LLM से आप सब कुछ करवा सकते हैं। यह संभव है और लोग सचमुच ऐसा करते भी हैं। लेकिन इसमें बहुत पैसा लगता है और बहुत समय भी। इसके बजाय अगर आप AI से tools बनवाएँ जो process के जितने संभव हों उतने tasks को deterministic तरीके से संभालें, और फिर AI से उन्हीं tools का उपयोग करवाएँ, तो चीज़ें कहीं अधिक तेज़ और सस्ती चलती हैं। बोनस यह कि आखिर में आप महंगे cloud AI को हटाकर छोटे/मध्यम local models पर भी जा सकते हैं

  • अगर लेखक का भविष्य-दृष्टिकोण सही है, तो सक्षम software engineer सुरक्षित रहेंगे
    domain knowledge, अच्छे engineering principles कैसे लागू करने हैं यह सीखने की तुलना में, कहीं ज़्यादा जल्दी सीखा जा सकता है। जिन engineers की मुख्य प्रतिस्पर्धात्मक बढ़त domain knowledge है, वे शायद engineering में खुद इतने उत्कृष्ट न हों। फिर भी वे अपने संचित domain knowledge की ज़रूरत वाले उद्योग के दूसरे क्षेत्रों में नौकरी ढूंढ सकते हैं

    • एक हफ्ते पहले पूरे thread में कहा गया था कि domain expertise ही हमेशा असली moat रही है: https://news.ycombinator.com/item?id=48340411
    • मुझे नहीं पता कि यह बात सार्वभौमिक रूप से सही है कि domain knowledge अच्छे engineering principles की तुलना में बहुत जल्दी सीखी जा सकती है
      ऐसे कई अच्छे software engineers रहे हैं जिन्होंने यह सोचकर कि domain knowledge आसानी से हासिल की जा सकती है, अहंकार दिखाया और बहुत-से ERP systems खराब कर दिए। IT का बहुत बड़ा हिस्सा सचमुच business rules को systems में डालने का काम है
    • मैं आंशिक रूप से असहमत हूं। broad domain knowledge जल्दी सीखी जा सकती है, लेकिन उसे complexity को ध्यान में रखने वाली सूक्ष्म समझ तक निखारने में, खासकर किसी विशिष्ट organization में, जिसे अक्सर “software development company” नहीं माना जाता, कई साल से लेकर दशकों तक लग सकते हैं
      फिर भी मैं अब भी ऐसे “professional” software developers को देखता हूं, और उनके code reviews करता हूं, जो अच्छी software engineering practices का पालन नहीं करते। यह कहना कि जिन engineers की मुख्य ताकत domain knowledge है वे engineering में बहुत अच्छे न हों, उतना ही उन engineers पर भी लागू होता है जिनके पास domain knowledge नहीं है। कम-से-कम मेरा अनुभव तो यही कहता है। हो सकता है हमारी किस्मत खराब रही हो
    • मूल्यवान domain knowledge का विकास और अधिग्रहण कठिन, जोखिमभरा, महंगा और धीमा process है
      क्योंकि मूल्यवान domain knowledge कल का नहीं, आज और कल का ज्ञान होता है। जिन क्षेत्रों में domain knowledge महत्वपूर्ण है, वहां वह engineering के साथ गहराई से जुड़ी होती है। आप Jeff Dean से Unreal Engine को scratch से develop करने को नहीं कहेंगे। फिर भी software engineering के कई principles ऐसे हैं जिन्हें domain experts ने या तो पूरी तरह internalize नहीं किया है या पर्याप्त रूप से लागू नहीं किया है। जब तक domain knowledge मूल्यवान रहेगी, यह स्थिति भी बनी रहेगी। क्योंकि software engineering भी अपने आप में एक domain है
    • क्या domain knowledge अधिक जल्दी सीखी जा सकती है? मेरी राय इससे उलट है
      methodology को expertise हासिल करने की तुलना में कहीं तेज़ी से सुधारा जा सकता है। पहला approach का सवाल है, इसलिए उसे enforce करके जल्दी ऊपर लाया जा सकता है। दूसरा व्यक्ति की सीखने की प्रवृत्ति, क्षमता और उस समय उपलब्ध समय पर निर्भर करता है, और उचित support से आगे उसे मजबूर नहीं किया जा सकता। साथ ही उसका स्वभाव cumulative होता है, इसलिए शुरुआती learning curve कहीं अधिक steep होती है

  • मैं Claude Code और Opus 4.7 इस्तेमाल कर रहा हूं, और generated code गलत होने से ज़्यादा, बहुत ज़्यादा लिखने की प्रवृत्ति रखता है
    किसी खास functionality को सोचना और उसे code में सबसे सही जगह पर फिट करना अब भी काफ़ी मूल्यवान है। Claude अक्सर stack की किसी एक layer, जैसे presentation layer, को चुनता है और चीज़ें वहीं ठूंस देता है। कुछ हफ्ते बाद जब वही data कहीं और भी चाहिए होता है, तो Claude service layer के code को reuse नहीं कर पाता और किसी तरह का “transplant” कर देता है। अगर इंसान ध्यान न दे, तो code की मात्रा दोगुनी हो जाती है और logic duplicate हो जाता है। Claude जैसे AI tools इस मामले में जल्दी बेहतर होंगे, ऐसा नहीं लगता। जहां मैं काम करता हूं, वहां पहले ही cost बचाने के लिए Opus 4.7 का इस्तेमाल कम करने का दबाव है। किसी ने कहा कि “simple bug fixes” के लिए छोटे models इस्तेमाल करें। कभी-कभी यह काम करेगा, लेकिन वास्तव में कितनी बार पहले से पता होता है कि यह simple bug fix है? अगर cost बढ़ती है, तो इस tool से “सारा code” लिखवाने की दिलचस्पी कम होती जाएगी। अगर लोग सस्ते और कम असरदार models पर चले जाते हैं, तो उस code को review न करने का दबाव भी शायद गायब हो जाएगा। आखिर में हम कहां पहुंचेंगे, देखेंगे, लेकिन शायद चीज़ें उतनी नाटकीय रूप से न बदलें जितना लेखक डर रहा है

    • मैं AI के बहुत ज़्यादा code लिखने वाली आलोचना से सहमत हूं
      सिर्फ AI से यह कहना कि production code की lines आधी कर दो, और देखो कि क्या कोई दूसरी reusable library मौजूद है, हैरान करने वाली हद तक प्रभावी है। शायद duplication ढूंढकर निकालने वाला refactoring bot भी बनाया जा सकता है। अभी यह built-in नहीं है, लेकिन यह असंभव है, ऐसा भी साफ़ नहीं है
    • मैंने भी code के बहुत ज़्यादा बढ़ जाने की समस्या देखी है
      लेकिन खुला सवाल यह है कि क्या बहुत ज़्यादा code होना वास्तव में समस्या है। ये tools अब जीवन का हिस्सा हैं। अगर वे problems जल्दी solve करते हैं या debugging तेज़ करते हैं, और software में bugs कम हैं, तो शायद यह बहुत ज़्यादा code नहीं बल्कि ठीक उतनी ही lines हैं जितनी चाहिए
    • हाल ही में codebase में fooBar() और fooBarExtended() नाम के दो functions थे
      दूसरे वाले में मौजूदा समस्या के लिए ज़रूरी extra parameters और functionality थी। लेकिन Claude उस function को call करने के बजाय पहले function में वही extra parameters बार-बार जोड़ने की कोशिश करता रहा। उसे ऐसा न करने को कहने के बाद भी उसने बाद में फिर वही सुझाव दिया, और यह कभी-कभी सच में बहुत चिढ़ दिलाता है

  • उद्योग के भविष्य को आप जैसे भी देखें, मुझे नहीं लगता कि artisan woodworking में artisan software से ज़्यादा बड़ा पेशेवर success मिलना आसान है

    • custom furniture/cabinet का market पहले से ही काफ़ी मुश्किल है, और woodworking programmers का इतना आम hobby है कि अगर हममें से बड़ी संख्या इसमें उतर जाए, तो market जल्दी ही बुरी तरह oversupply हो जाएगा
      लोगों ने मुझसे कहा है कि मैं अपने बनाए furniture बेचकर देखूं, और मेरा जवाब हमेशा एक ही होता है। मैं एक बार अपना hobby पेशे में बदलने की गलती कर चुका हूं, और दोबारा वह गलती नहीं करूंगा। कम-से-कम software अभी भी काफ़ी अच्छा पैसा देता है
    • woodworking को आप क्या मानते हैं, इस पर निर्भर करता है
      मेरे साथ काम करने वालों में एक व्यक्ति deck, garden, caravan, shed, fence जैसी चीज़ें बनाता है और बहुत अच्छा कमाता है। निष्पक्षता से कहूं तो, वह अपने काम में बेहद कुशल भी है
    • मेरे पास एक ऐतिहासिक घर है जिसमें हाथ से तराशी गई अनोखे आकार की doors हैं
      door frame सड़ गया था, इसलिए replacement बनवाने के लिए मैंने एक बढ़ई को 4,000 डॉलर दिए। सिर्फ door को बदलना हो तो आसानी से 25,000 डॉलर लग जाएंगे। अगर आप ऐसे बड़े historical district में चले जाएं जहां बहुत-सी hand-carved doors हों, तो अच्छी कमाई हो सकती है
    • market का बहुत छोटा हिस्सा, शायद 1% से भी कम, अब भी handmade चीज़ों के लिए पैसे देने को तैयार है। अगर वह पूरी तरह modern होते हुए retro भी लगे, तो bonus भी है। जैसे steampunk keyboard
      लेकिन हाथ से बने software के लिए पैसे देना चाहने वाले market का हिस्सा ठीक 0% है
    • layoffs.fyi देखो। तुम्हारे जल्द ही निकाले जाने की संभावना ज़्यादा है। अगर कल नहीं तो बस कुछ साल और दे दो, जब तक AI और बेहतर न हो जाए। यह नीचे जाने वाली one-way street है
      woodworking नहीं, farming है। ज़मीन का इंतज़ाम करो और अपना खाना खुद उगाओ। economy में बिल्कुल भाग न लेना ही शायद बचने का एकमात्र तरीका है