आलस्य के गुण के खोने का ख़तरा

• प्रोग्रामिंग में आलस्य सिर्फ़ साधारण टालमटोल नहीं, बल्कि abstraction और simplicity की खोज करने वाला एक बौद्धिक गुण है
• सच्चा आलस्य समस्या पर गहराई से विचार कर भविष्य का समय बचाने की प्रक्रिया है, और इससे आगे आने वाले developers को भी लाभ मिलता है
• आधुनिक high-level abstraction और ‘brogrammer’ संस्कृति इस गुण को कमज़ोर कर रहे हैं और इसकी जगह झूठी परिश्रमशीलता ले रही है
• LLM इस प्रवृत्ति को चरम पर ले जाकर, code की मात्रा को ही value समझने की भूल कराने वाले अतिउत्पादन के उपकरण की तरह काम करते हैं
• इंसान के सीमित समय से जन्म लेने वाले गुणात्मक आलस्य को बनाए रखते हुए, LLM का उपयोग सरल और टिकाऊ system design के लिए किया जाना चाहिए

---

प्रोग्रामर के गुण के रूप में आलस्य और उसके खोने का ख़तरा

• Larry Wall ने 『Programming Perl』 में प्रोग्रामर के तीन गुण — आलस्य(laziness), अधीरता(impatience), और अहं(hubris) — बताए थे, जिनमें आलस्य का अर्थ सबसे गहरा है
  • आलस्य सिर्फ़ आत्म-परिहास नहीं, बल्कि abstraction की आवश्यकता और उसकी सौंदर्य-दृष्टि को समेटने वाली धारणा है
  • यह सिस्टम को यथासंभव सरल बनाने और शक्तिशाली abstraction के ज़रिए अधिक काम को अधिक आसानी से करने की प्रेरक शक्ति है
• सच्चा आलस्य ‘hammock-driven development’ की तरह ऊपर से आराम जैसा दिख सकता है, लेकिन वास्तव में यह भविष्य का समय बचाने के लिए समस्या पर गहराई से विचार करने वाला बौद्धिक श्रम है
  • जब सही abstraction बन जाती है, तो उसका लाभ सिर्फ़ डेवलपर को नहीं बल्कि आने वाली पीढ़ियों के developers को भी मिलता है
  • ऐसा आलस्य software को लिखना और systems को बनाना दोनों आसान करता है

• वह दौर जिसमें आलस्य का गुण गायब हो रहा है

  • पिछले 20 वर्षों में software निर्माण का दायरा बढ़ने के साथ, खुद को प्रोग्रामर न मानने वाले लोग भी बड़ी संख्या में इसमें आए हैं
    • उनके लिए आलस्य का यह गुण अपना मूल अर्थ खो बैठा है
  • आधुनिक high-level abstraction से आई productivity की विस्फोटक बढ़ोतरी उलटे झूठी परिश्रमशीलता(false industriousness) को बढ़ावा देती है
    • यह ‘brogrammer’ संस्कृति और ‘hustle porn’ के रूप में दिखती है, जहाँ विडंबनापूर्ण आलस्य की जगह लगातार code उगलते रहने की प्रवृत्ति ले लेती है

• LLM द्वारा लाई गई नई अति

  • LLM(large language model) का आगमन इस प्रवृत्ति को और चरम पर ले गया है
    • LLM इंसानी रचनात्मक प्रवृत्तियों को बढ़ाने वाला औज़ार है और ‘brogrammer’ संस्कृति के लिए steroid जैसा काम करता है
  • उदाहरण के तौर पर Garry Tan ने कहा कि उन्होंने LLM की मदद से एक दिन में 37,000 lines of code लिखीं
    • तुलना के लिए DTrace का पूरा codebase लगभग 60,000 lines का है
  • लेकिन यह तरीका आलस्य के गुण से रहित एक अवगुण है, जो software की value को code की मात्रा से मापने की गलती को उजागर करता है

• LLM की सीमाएँ और मानवीय आलस्य का मूल्य

  • LLM की labor cost शून्य होती है, इसलिए वे भविष्य का समय बचाने की चिंता किए बिना अनंत रूप से जटिल systems बना सकते हैं
    • नतीजतन systems और बड़े व जटिल हो जाते हैं, vanity metrics तो पूरी हो सकती हैं लेकिन मौलिक quality को नुकसान पहुँचता है
  • मानवीय आलस्य सीमित समय की बाधा से पैदा होता है, और यही बाधा स्पष्ट abstraction और सरल system design को मजबूर करती है
    • बेहतरीन engineering हमेशा constraints से जन्म लेती है; इंसानी समय की सीमा cognitive load को सीमित करती है और simplicity की ओर धकेलती है
    • LLM के पास ऐसी कोई बाधा नहीं होती, इसलिए उनके पास खुद से simplicity चुनने की प्रेरणा नहीं होती

• LLM को एक tool के रूप में इस्तेमाल करने की दिशा

  • LLM अब भी software engineering के शक्तिशाली tool के रूप में महत्वपूर्ण भूमिका निभा सकते हैं
    • Oxide के LLM उपयोग-निर्देशों के अनुसार, LLM सिर्फ़ tool हैं; वे इंसानी गुणों का स्थान नहीं ले सकते
  • LLM का उपयोग technical debt जैसी अनुत्पादक आलस्य की समस्याओं को सुलझाने या engineering rigor को मजबूत करने में किया जा सकता है
  • लेकिन उनका उपयोग हमेशा ‘गुणात्मक आलस्य’ को साकार करने की दिशा में होना चाहिए
    • यानी ज़्यादा सरल और शक्तिशाली systems बनाए जाएँ, ताकि भविष्य की developer पीढ़ियों के लिए उपयोगी परिणाम छोड़े जा सकें

[GN⁺]

Hacker News की राय

• मेरे क्षेत्र Computational Fluid Dynamics में भी ऐसे लोग हैं जो LOC की तरह ज़्यादा tests होने का दिखावा करते हैं
  लेकिन ध्यान से देखें तो वे tests बहुत सख्त नहीं होते, और मेरे हाथ से बनाए गए tests की तुलना में कहीं ज़्यादा ढीले होते हैं
  10 लाख आसान tests का कोई मतलब नहीं, अगर वे code के मुख्य हिस्सों को cover ही नहीं करते

  • मुझे भी समझ आया कि tests मुझे खुद लिखने चाहिए
    और जब code काम नहीं करता तो Claude tests को “ठीक” न कर दे, इसके लिए मैं हमेशा git diff से test changes चेक करता हूँ
    अगर tests को सख्ती से manage किया जाए, तो Claude मुश्किल research paper algorithms भी अच्छी तरह implement कर देता है और समय बचता है, लेकिन काफी देखभाल चाहिए
  • यह किसी तरह का reward hacking लगता है
    model tests नाम के reward function का दुरुपयोग “जीत घोषित करने” के लिए कर रहा है
    शायद RL pretraining data में भी ऐसा pattern शामिल रहा हो, ऐसा अनुमान है
  • LLM से बेवकूफ़ी-भरे न लगने वाले tests बनवाना सच में बहुत मुश्किल है
    assert(1==1) जैसे बेकार tests सैकड़ों बन जाते हैं
    इसलिए “ऐसे tests मत बनाओ” वाली एक अलग ban list रखनी पड़ती है

• 30 साल खुद coding करने के बाद अब मैं पूरी तरह AI coding पर आ गया हूँ, और यह अजीब लगता है कि लोग AI-generated code के LOC या features का श्रेय खुद ले रहे हैं
  दिन में लाखों lines “code” करने का दावा करना आखिरकार कुछ prompt lines लिखने जैसा ही तो है

  • यह एक spectrum जैसा है
    जिन changes को आपने खुद approve किया, उनका कुछ श्रेय लेना ठीक है, लेकिन पूरी तरह vibe-coded app में आपकी भागीदारी लगभग नहीं होती
    मैं बीच में कहीं हूँ — AI ने जो code बनाया, उसका मैं सब कुछ review नहीं करता, लेकिन architecture design और refactoring की दिशा मैं तय करता हूँ
    नतीजा वैसा ही होता है जैसा मैं खुद बनाता, बस बहुत तेज़ी से तैयार हो जाता है
  • Meta में अब AI usage leaderboard है, जिसमें सबसे ज़्यादा Claude tokens खर्च करने वाले लोगों को दिखाया जाता है
    Meta अगर Claude इस्तेमाल कर रहा है, तो Anthropic के लिए यह काफ़ी खुशी की बात होगी
  • सच कहें तो ज़्यादा LOC होना खराब नतीजे का संकेत भी हो सकता है
  • कुछ लोग कहते हैं कि LoC quality metric के रूप में बेमानी है
    अब हम ऐसे दौर में हैं जहाँ implementation, testing और maintenance सब agents संभालते हैं
    LoC बस इतना दिखाता है कि agent requirements को कितनी दूर तक push कर सकता है, यानी यह एक capability metric भर है
    इंसानी critical review अब भी feedback के रूप में डाला जा सकता है

• “हमें ज़्यादा abstractions इस्तेमाल करनी चाहिए” — यह बात पहले सही रही होगी, लेकिन अब मुझे उल्टा लगता है
  मुझे WET(Write Everything Twice) दर्शन पसंद है — दो बार लिखो, तीसरी बार abstraction पर सोचो

  • इसे अक्सर Rule of Three भी कहा जाता है
    wiki article देखें
  • software की असली खूबसूरती सही abstraction में होती है
    operating systems, RDBMS, cloud orchestration जैसी innovations इसके उदाहरण हैं
    लेकिन ज़्यादातर code साधारण business logic होता है, जहाँ abstraction उल्टा रुकावट बन जाती है
    इसलिए मेरा नियम है: “तीन वास्तविक use cases साबित होने से पहले platform मत बनाओ”
  • किसी चीज़ को दो बार से ज़्यादा लिखना कोई बहुत नीचे का मानक नहीं है, और यह Perl के उस मशहूर quote से भी टकराता नहीं, ऐसा मेरा मानना है
  • दूसरी बार लिखना, समस्या को बेहतर समझ लेने के बाद उसे सुधारने का मौका होता है
    तीसरी बार abstraction की कोशिश करते समय Second-System Effect से सावधान रहना चाहिए — ज़्यादा आत्मविश्वास बहुत जटिल system पैदा कर सकता है
  • 1991 की Programming Perl के बाद abstraction layers का विस्फोट वाकई हैरान करने वाला रहा है

• जर्मन जनरल Kurt von Hammerstein-Equord का मशहूर quote साझा किया गया
  बुद्धिमान और मेहनती लोग staff के लिए, मूर्ख और आलसी लोग रोज़मर्रा के काम के लिए, बुद्धिमान और आलसी लोग leadership के लिए,
  और मूर्ख और मेहनती लोग खतरनाक होते हैं, इसलिए उन्हें कभी ज़िम्मेदारी नहीं देनी चाहिए

  • किसी ने मज़ाक में कहा, “मेरे जैसे 90% आलसी लोगों का क्या?”

• LLM से 2 लाख LOC लिख देने पर शेखी बघारना जितना मूर्खतापूर्ण है, उतना ही यह कहकर हँसना भी गलत है कि “वह code बेवकूफ़ी भरा है”
  आखिरकार महत्वपूर्ण चीज़ code output नहीं, value creation है
  Garry Tan ने सच में कुछ मूल्यवान बनाया या नहीं, यह मुझे नहीं पता

  • अगर आपको लगता है कि code quality मायने नहीं रखती, तो यह खतरनाक है
    Horizon IT scandal जैसे मामलों में खराब code ने वास्तविक नुकसान किया है
    Garry के project का विश्लेषण करने वाले पोलिश developer Gregorein की review के अनुसार, उस app में test harness, Hello World app, duplicate logo files जैसी अव्यवस्थित चीज़ें भरी हुई थीं
    चिंता यह है कि कहीं ऐसे code ने security attack surface और न बढ़ा दी हो
  • Garry सिर्फ़ एक developer नहीं, बल्कि YC के CEO हैं
    वह LOC की चिंता नहीं कर रहे थे, बल्कि AI प्रचार के लिए पोस्ट कर रहे थे
  • असली metric है value – cost
    AI development और operations cost घटाता है, लेकिन security और legal risk जैसी छिपी हुई costs बढ़ाता है
    AI के समर्थक अक्सर सिर्फ़ पहले हिस्से पर ज़ोर देते हैं
  • मेरे पास 2 लाख LOC पढ़कर यह साबित करने का समय नहीं है कि वह बुरा idea है
    यह साबित करना vibe coder का काम है
    LOC के आधार पर शेखी बघारना अब भी बेवकूफ़ी ही है
  • “value creation” शब्द खुद भी खतरनाक हो सकता है
    जैसे fossil-fuel आधारित growth में, short-term value long-term cost पैदा कर सकती है

• हाल की कुछ PRs में मैंने अक्सर LLM को गलत solution देते देखा है
  उदाहरण के लिए, पहले से मौजूद JSON parser होने के बावजूद वह खुद parser implement करने लगता है
  इंसान होता तो सोचता, “यह बहुत inefficient है,” लेकिन LLM में आलस नहीं होता, इसलिए वह गलत दिशा में भी मेहनत करता रहता है

  • वह project के भीतर duplicate functions को भी बिल्कुल नहीं पहचानता
    formatTimestamp जैसे function तीन-तीन बार मौजूद हों, तो भी एक बार grep करने से पता चल जाने वाली बात को नज़रअंदाज़ कर देता है

• LLM के आलसी न होने वाली बात से मैं सहमत हूँ
  बस यह नहीं पता कि यह स्थायी समस्या है या अगले model upgrade या CICD pipeline में हल हो जाएगी
  मैं feature पूरा होने के बाद prompt देता हूँ कि “देखो, कोई bugs हैं या refactoring की ज़रूरत है,”
  आगे चलकर शायद ऐसा चरण भी आए जहाँ system अपने-आप recent commits का analysis करके simplification suggestions दे

  • लेकिन अगर आप कहें “X ढूँढो”, तो LLM हमेशा कुछ-न-कुछ ढूँढ ही लेता है
    इसलिए termination condition define करना मुश्किल हो जाता है
  • अंत में समस्या tool की प्रकृति से ज़्यादा उसके इस्तेमाल की सीमा है
    “कुछ जोड़ो” कहेंगे तो वह जोड़ता जाएगा, “कम करो” कहेंगे तो LOC घटाएगा
    बड़े काम देकर review छोड़ देंगे, तो code slop जमा होना आसान है

• LLM साधारण console output program की जगह full SPA बना देने की ओर झुकता है
  और spec.md file को concise भी नहीं रख पाता
  अगर आप कहें “इस document को update करो और आसपास की चीज़ों को simplify करो,” तो वह उल्टा उसे और जटिल बना देता है
  आखिरकार पढ़ने लायक document के लिए इंसान को खुद summary लिखनी पड़ती है
  LLM output को edit करना तकलीफ़देह है, और चीज़ों को समझते रहने के लिए खुद लिखना बेहतर है

• अब समय है कि LLMs और vibe coders को software development के क्लासिक सबक सिखाए जाएँ
  Negative 2000 Lines of Code की कहानी की तरह, कई बार code कम करना ही असली प्रगति होता है

• ऐसा leadership अगर साथ काम करने को मिले तो कितना अच्छा हो
  सच में समझदार leader के साथ काम करना बहुत बड़ा सौभाग्य है