AI रॉकस्टार डेवलपर्स के बाद की सफाई

 (codingwithjesse.com)
1 पॉइंट द्वारा GN⁺ 7 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • पहले के ‘रॉकस्टार डेवलपर्स’ द्वारा छोड़े गए कठिन codebase की समस्या अब LLM-जनित code के फैलाव के साथ पूरी टीम पर maintenance burden बनकर बढ़ रही है
  • रॉकस्टार डेवलपर्स नई तकनीक, नए paradigm और नई architecture को तेजी से अपनाते थे और मुश्किल काम जल्दी खत्म कर देते थे, लेकिन ऐसा code लिखने में उनकी रुचि कम थी जिसे दूसरे लोग समझ सकें और साथ मिलकर उस पर काम कर सकें
  • LLM agents पिछला काम याद रखे बिना थोड़े समय में दसियों हजार lines of code बना देते हैं, और यह नहीं देखते कि वह पूरे system के साथ फिट बैठता है या उसे समझना आसान बनाता है
  • जितना अधिक generated code बढ़ता है, system की complexity उतनी ही ज्यादा बढ़ सकती है, और उसे समझने के लिए फिर से LLM पर निर्भर होने वाला एक चक्र बन सकता है
  • लंबे समय तक चलने वाले software के लिए LLM को छोटे code snippets तक सीमित रखना, design की अगुवाई इंसानों द्वारा करना, और समस्या की जटिलता के हिसाब से architecture को सरल बनाना जरूरी है

रॉकस्टार डेवलपर्स द्वारा छोड़ी गई संरचना

  • रॉकस्टार डेवलपर टीम में शामिल होने के बाद नई तकनीक, नए paradigm और नई architecture को लेकर मजबूत विचार पेश करता है
  • वह कंपनी की ज्यादातर core architecture को फिर से लिखता है, और नए build process, tools और languages को अपनाता है
  • वह कई pull requests को reject करता है, टीम के साथियों के लिए अपेक्षित मानक ऊंचे कर देता है, और दूसरे लोग यह नहीं दिखा पाते कि वे उस code को समझते हैं या नहीं
  • सबसे मुश्किल काम रॉकस्टार डेवलपर को सौंपे जाते हैं, और वह उन्हें दूसरों से ज्यादा तेजी से पूरा करता है
  • बाकी टीम सदस्य नई libraries सीखने और रॉकस्टार डेवलपर के तरीके के हिसाब से ढलने में धीमे पड़ जाते हैं
  • कुछ साल बाद रॉकस्टार डेवलपर और कठिन तथा बड़ी कंपनी के project की चाह में टीम छोड़ देता है

प्रभाव से निपटना

  • पीछे बचे टीम सदस्य रॉकस्टार डेवलपर के projects अपने हाथ में लेते हैं और code के भीतर खुद को दबाव में पाते हैं
  • data flow का पीछा करना मुश्किल था, और यह लगभग ऐसा लगता था जैसे कोई हत्या छिपाने की कोशिश कर रहा हो
  • उन्होंने साधारण bug fixes से शुरुआत की, लेकिन laptop पर code चलाने में ही एक हफ्ता लग गया
  • आधा code ऐसी language में लिखा था जिसे वे समझते नहीं थे, और बाकी आधा ऐसी libraries से बना था जिनका नाम भी उन्होंने नहीं सुना था
  • उन्होंने अपने manager से कहा कि code को फिर से लिखना जरूरी है, लेकिन यह कहकर बात ठुकरा दी गई कि यह रॉकस्टार डेवलपर का लिखा हुआ code है
  • बिखरे हुए code में भटकते-भटकते वे job postings देखने लगे और जाने की कल्पना करने लगे

रॉकस्टार के बाद सफाई करना

  • कई teams और agencies को ऐसे रॉकस्टार डेवलपर्स द्वारा छोड़े गए codebase की सफाई करनी पड़ती है
  • जटिल codebase को समझने और बचाने की प्रक्रिया उस उलझी हुई लाइट की तार को सुलझाने जैसी है जिसे फिर से इस्तेमाल लायक बनाना हो
  • रॉकस्टार डेवलपर्स को coding, learning और नए paradigm का इस्तेमाल पसंद होता है, और वे खुद को अपनी क्षमता की सीमा तक धकेलते हैं
  • वे जितना हो सके उतना clever code लिखना चाहते हैं और ज्यादा से ज्यादा तेजी से आगे बढ़ने पर ध्यान देते हैं
  • ऐसा code लिखना जिस पर दूसरे लोग साथ मिलकर काम कर सकें, रॉकस्टार डेवलपर के लिए सबसे कम प्राथमिकता वाली बात बन जाती है

AI का आगमन

  • पिछले कुछ वर्षों में कई teams ने खुद को रॉकस्टार डेवलपर्स की पूरी फौज के सामने दबा हुआ पाया है
  • हर बार जब कोई नया chat शुरू करता है, तो टीम में एक और रॉकस्टार डेवलपर जुड़ जाने का जोखिम पैदा हो जाता है
  • agents को याद नहीं रहता कि उन्होंने कल क्या किया था, और वे कुछ ही मिनटों में दसियों हजार lines of code बना देते हैं
  • agents ऐसे वेग से काम पूरा करने की कोशिश करते हैं जो इंसानों के लिए संभव नहीं है
  • उन्हें इस बात से मतलब नहीं होता कि generated code system के बाकी code के साथ मेल खाता है या system को समझना आसान बनाता है
  • AI के पास best practices का ऐसा toolbox होता है जो हर स्थिति के लिए उपयुक्त हो, यह जरूरी नहीं
  • जब complexity, फायदे से अधिक हो जाती है तब भी AI “belt and suspenders” शैली की जरूरत से ज्यादा safety layers पर अड़ा रह सकता है
  • जब उससे code review मांगा जाता है, तो वह सुधारों की एक लंबी सूची बना देता है जिसमें कई बिंदुओं से सहमत होना मुश्किल होता है
  • बहुत से लोगों को लगने लगा है कि अगर वे LLM का इस्तेमाल नहीं करेंगे तो वे हमेशा के लिए पीछे रह जाएंगे
  • लेखक का मानना है कि LLM से सारा code लिखवाने का तरीका आखिरकार पीछे छूट जाने की ओर ले जाता है

सैकड़ों AI रॉकस्टार्स के बाद सफाई करना

  • बिखरे हुए generated code के ढेर को साफ करना, एक रॉकस्टार डेवलपर के code को व्यवस्थित करने जितना भी सुखद नहीं होता
  • कम से कम रॉकस्टार डेवलपर के पास कोई design intent तो होता था, और वह अपना सर्वश्रेष्ठ देने की कोशिश करता था
  • vibe coding से बने बिखरे code के ढेर को किसी एक कृत्रिम डेवलपर ने नहीं लिखा होता
  • वह कई chats और कई contexts में एक-एक feature या एक-एक bug fix के रूप में जनरेट हुए codebase में बदल जाता है
  • यह उस codebase जैसा हो जाता है जिसे सैकड़ों अलग-अलग रॉकस्टार डेवलपर्स ने लिखा हो
  • कुछ मामलों में technical debt इतना बढ़ जाता है कि उसे कभी चुकाया ही नहीं जा सकता

लंबे समय तक टिकने वाला software बनाना

  • LLM को रॉकस्टार डेवलपर की तरह व्यवहार करने से रोकते हुए इस्तेमाल करने के कई तरीके हैं
  • इंसान engineering की अगुवाई कर सकते हैं, और LLM को एक बार में केवल छोटे code fragments बनाने के लिए निर्देशित कर सकते हैं
  • यह सुनिश्चित करना चाहिए कि software ऐसे तरीके से लिखा जाए जिसे टीम के सभी सदस्य आसानी से समझ सकें और जिस पर काम कर सकें
  • अगर LLM क्या कर रहा है और क्यों कर रहा है, यह समझे बिना आप रास्ता खोने लगे हैं, तो गति धीमी करनी चाहिए
  • जो software बनाया जा रहा है उसकी quality सुनिश्चित करने के लिए अधिक धीरे चलना स्वीकार्य है
  • over-engineering को रोकना, और architecture को तब तक सरल बनाते रहना भी ठीक है जब तक वह समस्या की जटिलता से मेल न खाने लगे
  • कभी-कभी LLM को toolbox में ही छोड़कर खुद code लिखना भी ठीक है
  • craftsmanship हमेशा इंसानी हाथों में ही रहती है, यह ऐसा क्षेत्र है जिसे मशीन को outsource नहीं किया जा सकता

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

2 टिप्पणियां

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

  • आख़िरी वाक्य कि कारीगरी हमेशा इंसानी हाथों में ही रहती है और उसे कभी मशीनों को आउटसोर्स नहीं किया जा सकता, थोड़ा चिंताजनक लगता है
    दूसरे उद्योगों में भी कारीगरी मरी नहीं है, लेकिन उसे कहीं सस्ते और आसानी से उपलब्ध विकल्पों ने पीछे छोड़ दिया है। हाथ से बने चमड़े के जूते आज भी खरीदे जा सकते हैं, लेकिन $1000 से ज़्यादा देना चाहने वाले लोग कम हैं, और कई हफ़्तों में बनी पेंटिंग भी खरीदी जा सकती है, मगर ज़्यादातर लोग HomeGoods से दीवार सजावट और घरेलू सामान खरीदते हैं
    मुख्य फ़र्क डिस्पोज़ेबल होने की धारणा है, और दुर्भाग्य से software भी धीरे-धीरे दूसरे उत्पादों की तरह “डिस्पोज़ेबल” बनता जा रहा है। अगर वह सिर्फ़ एक साधारण countdown app है तो उसे फेंका जा सकता है, लेकिन लंबे समय तक चलने वाली business process को संभालने वाले software के साथ ऐसा व्यवहार नहीं होना चाहिए
    अगर software craftsmanship पर ज़ोर दिया जाए, तो समस्या “मेरे उपयोग के लिए ज़रूरी चीज़” बनाम “boutique, महँगी और अनावश्यक चीज़” जैसी दिख सकती है। जबकि असल में यह “maintainable और reliable चीज़” बनाम “फेंक देने लायक चीज़” होना चाहिए
    यह रुझान OpenAI या Anthropic जैसे बड़े model providers के लिए फ़ायदेमंद है या नहीं, यह अलग बात है, पर यहाँ बात वह नहीं है

    • दूसरे उद्योगों की कारीगरी software में जिस तरह कहा जा रहा है, उस तरह ख़त्म नहीं हो रही
      जो सस्ता desk सपाट डिब्बे में आया और जिसे मैंने screwdriver से जोड़ लिया, वह भी फ़ैक्टरी में mass-produced था, लेकिन उसके design में किसी custom-made चीज़ से कहीं ज़्यादा विशेषज्ञ कारीगरी लगी हो सकती है। इसमें ऊँची शुरुआती design cost और उसके बाद कम marginal cost पर mass production वाला ढाँचा है
      software तो शुरू से ही ज़्यादातर ऐसा ही था। जब आप Firefox डाउनलोड करते हैं, तो कोई कारीगर सिर्फ़ आपके लिए web browser नहीं बना रहा होता, बल्कि कहीं किसी datacenter का CDN server cache से bytes कॉपी कर रहा होता है
      AI जिस चीज़ को ख़तरे में डाल रहा है, वह शुरुआती निवेश वाली कारीगरी का प्रतिस्थापन है, ऐसा कुछ जो दूसरे उद्योगों में बड़े पैमाने पर नहीं हुआ। AI ने जिस चीज़ को ज़्यादा सफलतापूर्वक बदला है, वह सस्ता “हस्तशिल्प जैसा” software है, और यह वह क्षेत्र है जो अब तक इतनी कम आर्थिक उपयोगिता वाला था कि व्यवहार में लगभग मौजूद ही नहीं था
    • भौतिक उद्योग और software बहुत अलग हैं। चमड़े के जूते हर ग्राहक के लिए एक-एक जोड़ी कई बार बनाए जाते हैं, लेकिन code एक बार बनाया जाता है और सभी ग्राहक वही उत्पाद इस्तेमाल करते हैं
      इसलिए quality investment का leverage बहुत बड़ा होता है
      software को उसी अर्थ में डिस्पोज़ेबल कहना भी मानना मुश्किल है। अगर समस्या अस्थायी है, तो code फेंककर अगली समस्या आने पर नया बनाया जा सकता है। लेकिन अगर समस्या लगातार बनी रहने वाली है, तो code भी बना रहता है
    • machining के नज़रिए से इसमें एक दिलचस्प दृष्टिकोण है
      screw कभी custom-made कीमती चीज़ हुआ करता था, और एक अच्छा screw बनाने में बहुत समय और मेहनत लगती थी। जिसे आज हम machine screw कहते हैं, उसे भी बनाने के लिए बेहद कुशल व्यक्ति की अत्यधिक मेहनत चाहिए होती थी
      लेकिन machine कारीगरी को स्थानांतरित कर सकती है। अगर आप एक सचमुच अच्छा screw बना लें, तो machine उस screw की quality को अनगिनत नए screws में पहुँचा सकती है
      आज के दौर में हर तरह और हर quality के screws लगभग एक जैसे consumable बन गए हैं, और जिन screws को पहले हाथ से तराशने में कई दिन या हफ़्ते लगते, आज वे अरबों की संख्या में बनाए जाते हैं
      मैं AI को बिना leadscrew वाली lathe की तरह देखता हूँ। शुरू में आपको हाथ से screw बनाना पड़ता है, और उसके बाद आप अपनी गुणवत्ता को जितने चाहें उतने नए screws में स्थानांतरित कर सकते हैं। जब आप और बेहतर screw बना सकें, तो उसे lathe में लगाकर और ज़्यादा अच्छे screws बना सकते हैं। लेकिन मूल रूप से आप उसी quality तक सीमित रहते हैं जितना अच्छा screw आप ख़ुद बना सकते हैं। अगर आप सिर्फ़ टेढ़ा-मेढ़ा, ऊबड़-खाबड़ कबाड़ ही बना सकते हैं, तो machine से भी वही स्तर निकलेगा
    • यह पूरी तरह ग़लत नज़रिया है। software में “कारीगरी” का समकक्ष जूते का निर्माण नहीं बल्कि जूते का design है
      software developers अद्वितीय बौद्धिक संपदा बनाते हैं, software units का निर्माण नहीं करते। वे किताब के लेखक या संगीतकारों के ज़्यादा क़रीब हैं
      software में unit manufacturing जैसी कोई चीज़ नहीं है। वहाँ तो बस bits की कॉपी इधर-उधर होती है
      इसलिए software के संदर्भ में “कारीगरी” का मतलब है कि आप कुछ अच्छा design करने में कितनी परवाह करते हैं। जब तक हम उस बिंदु पर नहीं पहुँच जाते जहाँ हमारे इस्तेमाल के software की quality ही मायने न रखे, यह ग़ायब नहीं होगी, और अभी ऐसा कोई संकेत नहीं है कि हम उस दिशा में जा रहे हैं
    • हाथ से बने जूतों वाली उपमा तब तक सही नहीं लगती जब तक बात ऐसे software की न हो जिसे सिर्फ़ एक व्यक्ति इस्तेमाल करता हो
      इससे बेहतर तुलना शायद उन engineers से होगी जो जूते की फ़ैक्टरी के manufacturing equipment को बनाते और maintain करते हैं। वे उपभोक्ता से एक स्तर दूर हैं, लेकिन वहाँ भी साफ़ तौर पर कारीगरी होती है

  • AI या outsourced code को ठीक करना अच्छा लगता है। पिछले हफ़्ते पता चला कि एक ग्राहक ने अपने विभाग के लिए एक tool को vibe coding से बनाने की कोशिश की थी, और नतीजा था एक विशाल Next.js कबाड़, जिसे compile करने के लिए 10GB memory चाहिए थी, lint errors हज़ारों में थे, और Git में शोर-भरे development logs तक शामिल थे
    अब हमें इसे ठीक करना है, तो ऐसी चीज़ें बार-बार 10,000 से 50,000 euro के मुफ़्त काम जैसी लगती हैं। अगर आपको पता है कि क्या कर रहे हैं, तो यह बहुत आसान है; अगर नहीं, तो असंभव है। ऐसे और आते रहें

    • एक तरह से देखें तो ग्राहक ने implementation के लिए spec और UI mockups दे दिए
    • इस बात से 1000 गुना सहमत हूँ
      मैं छोटे और मध्यम व्यवसायों के लिए incident response का काम करता हूँ, और पिछले कुछ वर्षों में काम इतना बढ़ गया है कि संभालना मुश्किल हो गया है, जबकि bank account किसी अजगर के ख़ज़ाने जैसा लगने लगा है
      मेरा मानना हमेशा यही रहा है कि security को शुरुआत से integrate और plan किया जाना चाहिए, और मेरा बिल्कुल मतलब यह नहीं कि मैं breach incidents देखना चाहता हूँ
      लेकिन जिन लोगों की विशेषज्ञता बस कुछ धुँधली-सी है, वे अब एक घंटे में apps उगल सकते हैं, और यह मेरे जैसे लोगों के लिए बहुत बड़ा windfall साबित हुआ है
    • जो agencies ऐसे काम पर फ़ोकस करेंगी, वे बहुत पैसा कमाएँगी। हमें पहले ही ऐसे कुछ काम मिल चुके हैं, और जब तक लोग यह मानते रहेंगे कि वे products को vibe coding से बना सकते हैं, तब तक ऐसे काम आते रहेंगे। जैसा कहा, यह आसान पैसा है
    • बहुत से लोग AI पर बहुत पैसा लगा रहे हैं। उनमें से कुछ दाँव promising हैं, लेकिन हर bet सफल नहीं होगी
      इस मानसिकता को ऐसे समझें जैसे लोग पैसे एक human slot machine में डाल रहे हों
    • मैं जानना चाहता हूँ कि असल में यह कैसे आगे बढ़ता है, बशर्ते आपकी या ग्राहक की पहचान सामने न आए
      जब ग्राहक आपके पास आते हैं, तो क्या वे शुरू से ही production environment में ले जाने में मदद चाहते थे, या AI वाला तरीका पूरी तरह असफल होने के बाद यह आख़िरी विकल्प बनता है?
      क्या ऐसे projects के टूटने का कोई आम पैटर्न होता है, या ज़्यादातर विफलताएँ काफ़ी सूक्ष्म होती हैं?

  • ज़िंदगी में कुछ ऐसे लोगों से मिला हूँ जिन्हें सच में असाधारण कहा जा सकता है। ऐसे लोग जिन्हें देखकर लगता है, “आख़िर कोई इतना स्मार्ट कैसे हो सकता है?”
    सच में बहुत स्मार्ट लोगों में दो बातें दिखती हैं, और आम तौर पर ये दोनों एक-दूसरे के विपरीत होती हैं। पहली यह कि उन्हें पता ही नहीं होता कि वे कितने स्मार्ट हैं। जो चीज़ उनके लिए आसान है, या जिस विषय को वे जानते हैं, उसके बारे में वे मान लेते हैं कि computer science degree वाला हर व्यक्ति उसे जानता, याद रखता और समझता होगा। क्रिप्टोग्राफी से जुड़ी math धाराप्रवाह बोलने वाले दोस्तों को सुनकर कई बार लगा है, “मैंने वह course पास तो किया था, लेकिन अभी तुमने जो कहा, यह नहीं कह सकता कि मैं सच में उस विषय को जानता हूँ।”
    दूसरी बात यह कि कुछ लोग इस बात से लगभग पीड़ादायक स्तर तक हमेशा सचेत रहते हैं कि वे अपने आसपास के ज़्यादातर लोगों से ज़्यादा स्मार्ट हैं। उनमें से कुछ बुरे हो जाते हैं, और कुछ अपने से अपेक्षाकृत “कम बुद्धिमान” लोगों से घिरे रहने से थक जाते हैं। दूसरे तरह के लोगों के लिए मुझे कुछ हद तक सहानुभूति है। ज़रा कल्पना कीजिए कि आपकी ज़िंदगी ऐसी हो जहाँ सब कुछ साफ़, स्पष्ट और आसानी से हल होने वाला लगे, और फिर आपको देखना पड़े कि जवाब बहुत पहले से पता होने के बावजूद मानवता बार-बार मूर्खतापूर्ण फैसले दोहराती रहती है

    • तीसरी समस्या भी है। वह यह कि बहुत बड़े बहुमत के लोग मानते हैं कि ऊपर की आख़िरी पंक्ति उन्हीं पर लागू होती है
    • मैं यह दावा नहीं करता कि मैंने बहुत किताबें पढ़ी हैं या मेरा IQ बहुत ऊँचा है, लेकिन छोटी-छोटी ऐसी बातें जो सामान्य समझ जैसी लगती हैं उनमें मुझे भी कुछ वैसा ही महसूस होता है
      जब लोग इधर-उधर भटकते हैं, या X करते हैं जबकि साफ़ दिख रहा होता है कि उसका बुरा नतीजा -Y होगा, तो पागलपन-सा महसूस होता है। ज़्यादातर लोगों ने बस यह सीख लिया है कि ऐसी बातों को ज़ुबान पर नहीं लाना है
      करीबी पारिवारिक रिश्तों में यह खास तौर पर स्वस्थ नहीं होता। इतना ज़्यादा दिखता है कि लगता है मानो लगातार टोका-टोकी करके किसी को मार ही डालूँगा
    • ऐसे लोगों को जानता हूँ और मिला भी हूँ
      लेकिन उनमें से कोई भी ऐसा 10x developer नहीं था जिसने इतना बड़ा कचरा-घर खड़ा कर दिया हो कि टीम और मुझे उसे साफ़ करने में महीनों लग जाएँ
    • किसी बुनियादी गुण में extreme outlier होकर जीना अकेलापन भरा होता है
      चाहे जितनी कोशिश कर लें, ज़्यादातर लोगों से जुड़ना मुश्किल होता है, और उनके लिए भी मुझे समझना खासा कठिन होता है। जीए गए अनुभवों का अंतर बहुत बड़ा होता है, और अक्सर उसे पाटना आसान नहीं होता
    • बहुत से developers बस रोज़मर्रा के काम करते रहने या cargo cult को फॉलो करने का चुनाव करते हैं
      सभी developers एक जैसी output नहीं दे सकते, लेकिन अगर कोई सांस्कृतिक औसत से आगे बढ़कर लगातार सोचना चुने, तो हर व्यक्ति अपने तरीके से स्मार्ट बन सकता है
      ज़्यादातर लोगों को एहसास ही नहीं होता कि वे ऐसा कर सकते हैं

  • ये दो वाक्य दिल को लगे
    “डेटा फ्लो को फॉलो करना इतना मुश्किल था कि लगा जैसे कोई हत्या छिपाने की कोशिश कर रहा हो”
    “सिर्फ़ कोड को laptop पर चलाने में ही एक हफ़्ता लग गया”
    मैं हमेशा सोचता था कि data flow समझने या एक ठीक-ठाक development environment सेट करने में दिक्कत सिर्फ़ मुझे ही होती है। impostor syndrome और कभी-कभी “speed” को ठेलने वाला toxic environment भी मददगार नहीं रहा।
    यह जानकर अच्छा लगा कि ऐसा सिर्फ़ मेरे साथ नहीं है

    • “सिर्फ़ कोड को laptop पर चलाने में ही एक हफ़्ता लग गया” वाला हिस्सा चौंकाने वाला था
      CLI में Claude Code ने app को खड़ा करना और random dependency या Docker से जुड़ी समस्याओं को debug करना पहले की तुलना में बहुत आसान बना दिया है। पहले मुझे architecture सीखने के साथ-साथ अपने machine पर न चलने वाली चीज़ों को भी ठीक करना पड़ता था
    • ऐसा सिर्फ़ मेरे साथ नहीं है। मुझे भी बिल्कुल ऐसा ही लगा, और ऐसी जानकारी आम तौर पर लोगों के दिमाग़ में या किसी random Slack thread में पड़ी होती है
      AI code में तो यह और भी बुरा हो जाता है, क्योंकि उस समय बस कुछ ऐसा generate कर दिया गया था जो ऊपर-ऊपर से ठीक लगता था

  • जो लोग दूसरों का छोड़ा हुआ साफ़ करते हैं, उनसे थोड़ी ईर्ष्या होती है। कम से कम उसमें puzzle solve करने जैसा एहसास तो होता है
    मेरा मौजूदा काम सच में बहुत उबाऊ है। काम इतने साधारण हैं कि junior भी कर सकता है, फिर भी कहते हैं कि इसके लिए mid-level developer चाहिए। मेरा मतलब यह नहीं कि मैं इस काम से बेहतर हूँ, या mid-level लोग ऐसा काम नहीं करते। बस मैं खुद को इस कंपनी के बनाए कोड में दिलचस्पी लेने के लिए मजबूर नहीं कर पाता। यह पुराना है, धूल-धूसरित है, और महत्वपूर्ण लोगों द्वारा इस्तेमाल भी नहीं होता। ग्राहक कभी इस tool को खरीद चुके थे, और अब सिर्फ़ इसलिए इस्तेमाल कर रहे हैं क्योंकि यह इतना नीरस tool है कि उसे बदलने लायक दिलचस्पी भी नहीं है
    मुझसे कहा गया था कि जल्द ही मेरे अनुभव से बेहतर मेल खाने वाला काम आएगा, लेकिन ऐसी जड़ हो चुकी कंपनी में वैसा ग्राहक आने की उम्मीद नहीं लगती
    यह कंपनी ग्राहक और कर्मचारी खो रही है, इसमें हैरानी नहीं। लेकिन मुझे mortgage चुकानी है। आज यह भी सुनने को मिला कि शायद contract extend न किया जाए, और यह लगभग उसी वेतन पर ज़्यादा ownership और ज़्यादा काम करने की धमकी जैसा लगा
    अफ़सोस की बात है कि सच में दिलचस्प नई जगह मिलने तक मुझे टिके रहना होगा। मुझे बहुत पैसे भी नहीं चाहिए, और “growth” जैसी चीज़ में तो बिल्कुल दिलचस्पी नहीं है। बस इतना चाहिए कि गुज़ारा हो जाए
    हो सकता है यह comment काफ़ी हद तक विषय से हटकर हो, माफ़ी चाहता हूँ। इसे लिखने के लिए और कोई outlet नहीं है

    • आप अकेले नहीं हैं। Microsoft में मेरी हालत बिल्कुल यही थी, और आख़िर में मैंने इस्तीफ़ा दे दिया
      मैं L63 पर था, लेकिन जो काम कर रहा था वह L60~L61 भी कर सकते थे, और अक्सर लगता था कि मैं David Graeber की बताई Bullshit Jobs में से एक में हूँ। pay अच्छा था, लेकिन joining bonus stock ख़त्म होने के बाद मुझे साफ़ दिखा कि मैं वहाँ सिर्फ़ stability के लिए टिका हुआ हूँ
      ऐसा लगता था जैसे मैं Hooli office terrace पर stock vest होने का इंतज़ार करते हुए धूप सेंकने वाले engineers में से एक बन गया हूँ। करियर के 9वें साल में मुझे नहीं लगा कि यह मेरे लिए सबसे अच्छा रास्ता है
      हाँ, मेरे ऊपर बड़े financial obligations नहीं थे, इसलिए मेरे लिए यह फ़ैसला कहीं आसान था
    • पहले मुझे लगा “medior” शायद “senior” की कोई अजीब typo है, लेकिन दो बार दिखने पर मैंने खोजा। लगता है यूरोप के कुछ हिस्सों में यह मिड-लेवल के अर्थ में इस्तेमाल होता है
    • “मैं खुद को इस कंपनी के बनाए कोड में दिलचस्पी लेने के लिए मजबूर नहीं कर पाता” वाली बात से बहुत गहरी सहमति है
      घटिया कंपनियों के बनाए घटिया products, ज़्यादातर लोगों की आलस और खराब taste पर पलते हैं, और marketers उसी का monetization करते हैं
      अब इससे भी बुरा यह है कि पूरा क्षेत्र LLM-करण से 100 गुना बढ़ गया है। यह code को maintain न किए जा सकने लायक बनाता है, और उससे भी बुरा यह कि हम सबको और मूर्ख बना देता है
      सच कहूँ तो काश हमने यह खोजा ही न होता
    • अगर आप अभी जिस codebase पर काम कर रहे हैं, उसे ध्यान से देखें, तो शायद काफ़ी मौके मिलेंगे कुछ साफ़ करने के—चाहे वह किसी और का छोड़ा हुआ हो या आपका अपना
    • “उसी वेतन पर ज़्यादा ownership और ज़्यादा काम करने की धमकी” वाली बात ने थोड़ा उत्सुक किया
      क्या इसका मतलब बस extra hours और बेकार काम करने का दबाव है, या सच में ज़्यादा coding के मौके हैं, या फिर अचानक यह उम्मीद है कि आपको साबित करना होगा कि आपकी value ज़्यादा है?
      मैं आपके अनुभव को हल्का करके नहीं देख रहा। बस अगर आख़िरी बात है, तो जानना चाहूँगा कि क्या वहाँ वास्तव में कुछ किया जा सकता है

  • शुरुआती कुछ सेक्शन असरदार लगे। पहले मुझे लगता था कि मैं एक rockstar developer था, लेकिन बाद में समझ आया कि यह कोई अच्छी बात नहीं थी
    हो सकता है मैं अपने साथियों से 10 गुना तेजी से काम खत्म कर लेता था। लेकिन एक समय पर एहसास हुआ कि इसकी वजह यह नहीं थी कि मैं आम लोगों से 10 गुना ज़्यादा productive था, बल्कि यह थी कि मेरे काम करने का तरीका आसपास के सामान्य लोगों को 1/10 जितना ही productive बना देता था
    उसके बाद मैंने अपनी रफ्तार धीमी की, और यह मेरी पूरी ज़िंदगी के लिए एक सकारात्मक बदलाव था। टीम प्लेयर बनना इस पागल इंडस्ट्री में उसी स्तर की upward mobility नहीं देता, लेकिन mental health के लिए यह हैरान करने वाला रूप से अच्छा था

    • मैंने भी पहले rockstar स्टाइल में implement करते हुए निश्चित रूप से खुद अपने ही पैर पर कुल्हाड़ी मारी है
      मेरे मामले में यह अक्सर ऐसी चीज़ों को over-abstract करना होता था जिनकी ज़रूरत नहीं थी, या उन use cases के लिए कुछ बना देना जो वास्तव में कभी होने ही नहीं थे। इसलिए जब भी सोच ज़्यादा abstraction की तरफ भागती है, मैं YAGNI और KISS को याद रखने की कोशिश करता हूँ

  • इस लेख की वैल्यू बहुत कम है
    यह कहना क्या चाहता है, यह भी ठीक से समझ नहीं आता, और यह बस खुद की पीठ थपथपाने वाला लेख लगता है

    • खराब code निश्चित रूप से होता है। लेकिन यह लेख “खराब code” और “ऐसा code जो complex, बड़ा, और जिसे समझने में समय लगता है” — इन दोनों को मिलाता हुआ लगता है
      जिसे “rockstar developer” द्वारा छोड़ा गया बहुत बड़ी मात्रा में खराब code कहा जाता है, उसका बड़ा हिस्सा दरअसल requirements में बदलाव के खिलाफ complexity के लंबे समय में धीरे-धीरे जमा होने का नतीजा था
      और लोग अक्सर सोचते हैं कि वे “readability के लिए refactor” कर रहे हैं, जबकि असल में कई बार वे “code को फिर से लिखते हुए उसी प्रक्रिया में उसे समझ” रहे होते हैं
    • सार यह है: “LLM इस्तेमाल करते समय रफ्तार धीमी करो और सोचो कि क्या कर रहे हो।” मेरे 5 मिनट बच गए
      मुझे इससे ज़्यादा, या कुछ वास्तविक examples जैसी चीज़ों की उम्मीद थी। लेख का 90% हिस्सा लेखक की शिकायतों और समस्या को परिभाषित करने में चला जाता है, और आखिरी से पहले वाले पैराग्राफ में हाथ हिलाकर दिया गया-सा एक धुंधला समाधान आता है। वास्तविक प्रासंगिकता या उपयोगिता लगभग नहीं के बराबर है

  • मेरे दो profitable projects के आसपास की infrastructure बनाने के लिए production engineers दो लोगों पर बहुत दबाव डालना सचमुच बेवकूफी थी
    अगर मैं सब कुछ 10x boss की तरह spaghetti code में बना देता और Anthropic चला जाता और 9-digit compensation package ले लेता, तो शायद मैं बहुत ज़्यादा पैसा कमा सकता था। मैं बेवकूफ था, और बहुत बेवकूफ था
    कम से कम, यहाँ से मैंने यही निष्कर्ष निकाला

  • लिखा गया code आमतौर पर लेखक के अलावा किसी और द्वारा maintain किया जाना होता है। इसलिए अगर आप ऐसा code लिखते हैं जिसे कोई समझ ही न सके, तो उसका अंत maintenance failure में होगा
    टीम के लिए आसानी से समझ आने वाला code, speed, technical excellence — किस चीज़ को optimize करना है, यह अलग हो सकता है
    लेकिन अगर आपने technical excellence को optimize भी किया हो, फिर भी टीम में बाकी कोई उस code को समझ ही न सके, तो वह फिर भी विफलता है
    मैंने over-engineered code देखा है
 
GN⁺ 7 시간 전
Lobste.rs की राय

  • इस लेख में वास्तव में काम की सलाह बहुत कम है

    • यह किसी की निजी झुंझलाहट को भरोसेमंद दिखाने के लिए दो buzzword में लपेट देने जैसा लगता है
      “रॉकस्टार डेवलपर” जैसी अभिव्यक्ति हमेशा संदिग्ध लगती है, लेकिन बेहतरीन डेवलपर सचमुच होते हैं। बस वे इस लेख में बताए गए तरीके से व्यवहार नहीं करते; वे मौजूदा माहौल के भीतर जितना संभव हो उतना काम करते हैं, codebase को बेहतर बनाते हैं, अप्रमाणित नई चीज़ों को खिलौने की तरह नहीं ले आते, और tests, scripted deployment, linting आदि के जरिए अपने जाने के बाद सिस्टम को ज़्यादा स्थिर हालत में छोड़ते हैं
      यहाँ AI को जैसे इस तर्क में जोड़ दिया गया है कि इससे ऐसा व्यवहार और खराब होगा; हो सकता है, लेकिन अभी यह बात पर्याप्त रूप से सिद्ध नहीं लगती। मैंने दशकों तक consultant के रूप में काम करते हुए बहुत से बिखरे हुए codebase साफ किए हैं, और कभी वजह हद से ज़्यादा आगे निकल जाने वाले लोग थे, लेकिन उससे भी ज़्यादा बार वजह ऐसी टीमें थीं जिन्हें बेहतर तरीका पता ही नहीं था। किसी भी मामले में मैंने कभी यह नहीं सोचा कि “यह किसी रॉकस्टार/निंजा/buzzword डेवलपर का काम होगा”

  • अब क्या हमें सिर्फ वह कचरा नहीं साफ करना है जो chatbot हमारे सिर पर उड़ेल देता है, बल्कि उन लोगों के बाद भी सफाई करनी है जिन्हें इसकी परवाह ही नहीं?
    बस bubble के फूटने का इंतज़ार करने का मन होता है

    • पहले भी हमेशा ऐसा ही था, AI बस समस्या को बढ़ा रहा है। उल्टा यह भी कहा जा सकता है कि सफाई का काम अब आसान हो गया है

  • अगर 2026 में आप किसी कंपनी में शामिल हों और पता चले कि वहाँ अभी भी create-react-app इस्तेमाल हो रहा है, तो सच में सुझाया गया व्यवहार क्या है? क्या बस कुछ कहना ही नहीं चाहिए?

    • अगर यह नया project है, तो आप बस कह सकते हैं कि यह अब deprecated है और इसकी अब सिफारिश नहीं की जाती
      अगर यह पुराना project है, तो आपने technical debt पहचान लिया है। यह हर जगह होती है। लोगों को इसे ठीक करने के लिए मनाने का सबसे अच्छा तरीका है ऐसा business case बनाना जो समझ में आए। अगर यह काम कर रहा है, तो क्या यह सच में risk है? दूसरे technical debt की तुलना में इसकी priority क्या है? upgrade न करने पर कौन-से छिपे हुए risk उठाने पड़ते हैं? upgrade में कितना effort लगेगा?
      अगर effort कम है और सहकर्मी भी चाहते हैं, तो बिना अनुमति माँगे चुपचाप काम करके इसे किया भी जा सकता है। लेकिन यह सबसे अच्छा तब चलता है जब इस बदलाव से प्रभावित लोगों का support हो, और यह आपके अपने deliverables में बाधा न बने। जॉइन करने के पहले हफ्ते में करने वाली चीज़ शायद यह नहीं है
      आम तौर पर “यह कैसे होना चाहिए” कहने से बेहतर हमेशा यह पूछना और समझना होता है कि अभी यह ऐसा क्यों है। इतिहास वाले हर codebase में हज़ारों ऐसे फैसलों के निशान होते हैं जिनके बारे में आप अभी नहीं जानते। ज्ञान और सहानुभूति के साथ आगे बढ़ना चाहिए
    • जब मैं किसी टीम में शामिल होता हूँ, तो क्या-क्या अलग होना चाहिए यह बताने से पहले पहले observe करना पसंद करता हूँ। किसी नए व्यक्ति के टीम में आते ही सब कुछ बदलने और सच में impact डालने वाले काम पर ध्यान देने के बीच एक संतुलन होता है। शुरुआत में आपको अभी पता ही नहीं होता कि impact किससे बनता है
    • यह इस पर निर्भर करता है कि आप कौन-सी लड़ाई चुनते हैं। मेरे हिसाब से यह शायद उतना worth it नहीं है, लेकिन मैं आप नहीं हूँ। legacy code हर जगह है, और create-react-app जैसे framework से बाहर निकलकर फिर से लिखने की लागत अक्सर उस लागत से कहीं अधिक होती है जिसमें लोग पहले से परिचित चीज़ के साथ टिके रहते हैं
    • मैं web developer नहीं हूँ, तो इस सवाल का मतलब क्या है? क्या create-react-app के पुराने हो जाने की बात है, या React के पुराने हो जाने की?
    • मैं बस यह बताना चाहता हूँ कि लोगों का अब CRA से नफरत करना मुझे बहुत validated महसूस कराता है
      मैं इसे 2020 से ही नापसंद करता था, जब यह अभी भी cool माना जाता था

  • “agent को याद नहीं रहता कि उसने कल क्या किया था” — यह हल की जा सकने वाली समस्या है। memory approaches वगैरह इस्तेमाल किए जा सकते हैं। यह हर जगह आदर्श नहीं है, लेकिन धीरे-धीरे बेहतर हो रहा है
    “इसे फर्क नहीं पड़ता कि यह code सिस्टम के बाकी code के साथ ठीक बैठेगा या नहीं” — यह मेरी experience से मेल नहीं खाता। आम तौर पर LLM-generated code संबंधित हिस्से के समान code जैसा ही बनने की प्रवृत्ति रखता है। दिशा पकड़ने के लिए उसने जो code पढ़ा होता है, उसका असर लगभग जस का तस दिखता है
    “इसे इससे फर्क नहीं पड़ता कि सिस्टम समझने में आसान हो रहा है या बदतर” — यह भी हल किया जा सकता है। आप LLM से इसका मूल्यांकन करवा सकते हैं और धीरे-धीरे score घटा सकते हैं। क्या चीज़ समझने में आसान है, यह अक्सर सिस्टम का non-deterministic गुण होता है, इसलिए विडंबना से यह दूसरी tools की तुलना में LLM से मापना आसान तरीका हो सकता है। नई session में यह पूछकर कि “इस नए जोड़े गए code को समझने के लिए सिस्टम का कितना हिस्सा समझना पड़ेगा”, और फिर उस दायरे को घटाते हुए optimize किया जा सकता है
    “AI के पास best practices का ऐसा toolbox है जो शायद यहाँ फिट न बैठे” — इस हिस्से में, AI के साथ काम करना अक्सर ऐसे junior developer को ट्रेन करने जैसा होता है जो नए project में वही आदर्श लेकर आया हो। junior को आप बातें बताकर उम्मीद करते हैं कि वह याद रखेगा और लागू करेगा, लेकिन AI के लिए अगर AGENTS.md / CLAUDE.md फ़ाइलों में दस्तावेज़ कर दिया जाए, तो वह ज्ञान बना रहता है
    “जब code review करने को कहते हैं तो यह बहुत सारे ऐसे सुधार सुझाता है जिनसे आप सहमत नहीं होते” — Codex के मामले में इसे सूची छोटी, संक्षिप्त और high-value रखने के लिए tune किया गया है। दूसरे model अलग हो सकते हैं, लेकिन अंत में यह भी instruction की बारीकी का सवाल है। जिन बातों की आपको परवाह है, वे अक्सर दस्तावेज़ करने लायक होती हैं, और AI इस्तेमाल करने पर इसकी ज़रूरत पड़ती है

  • रॉकस्टार से निपटने में आधी समस्या ego होती है, लेकिन फिर भी इंसान द्वारा लिखे code छोड़ जाने वाले रॉकस्टार के पीछे कुछ आत्मचिंतन और इरादा होता था
    इसके उलट, AI के ऊपर सिर्फ इंसानी खोल चढ़ाए हुए “रॉकस्टार” अक्सर उतनी ही या उससे भी ज़्यादा अकड़ रखते हैं, लेकिन जिन समस्याओं को वे हल करने का दावा करते हैं, उनकी आधी भी बात उन्हें पूरी तरह पता नहीं होती

  • अगर आप functional programming approach को जितना संभव हो उतना लागू करके ऐसे context-independent components बनाएँ जिन्हें अलग-अलग तरीकों से जोड़ा जा सके, तो आपको काफ़ी leverage मिल सकता है
    implementation details को abstract करने वाले अलग building blocks और किसी खास context पर निर्भर काम को अलग रख देने से, requirements बदलने पर या कोई दूसरा approach चुनने पर उन blocks को आसानी से फिर से व्यवस्थित किया जा सकता है। साथ ही, पूरे deployment context को जाने बिना भी हर हिस्से पर अलग से तर्क किया जा सकता है, और उन हिस्सों के जुड़ने के तरीके को देखकर higher-level logic समझा जा सकता है
    functional languages LLM के साथ काम करने के लिए अच्छा आधार देती हैं। क्योंकि वे स्वाभाविक रूप से code को ऐसे लिखने के लिए प्रेरित करती हैं जो context को सीमित रखे। इससे program की किसी खास functionality को समझने के लिए ज़रूरी दायरा कम होता है, जो model और मानव उपयोगकर्ता दोनों के लिए मददगार है