AI ने software engineering को सरल नहीं बनाया: इसने सिर्फ खराब engineering को आसान बनाया है

• LLM ने कोड लिखने की गति बढ़ाई है, लेकिन software engineering की मूलभूत जटिलता को कम नहीं किया
• कोड generation आसान होने के साथ यह भ्रम फैल रहा है कि expertise की अब ज़रूरत नहीं रही, और कुछ संगठन इसी आधार पर engineers की छंटनी कर रहे हैं
• असली कठिनाई कोड लिखने में नहीं, बल्कि system design, specification, verification, और consistency बनाए रखने में है, और AI इस क्षेत्र का बोझ उल्टा और तेज़ कर देता है
• specification, test, और implementation के बीच mismatch (spec drift) तेज़ी से बढ़ सकता है, जिससे system reliability टूटने का जोखिम बढ़ता है
• 40 साल से अधिक के अनुभव में बार-बार दिखा एक पैटर्न है; 1990 के दशक के Visual Basic दौर में भी यही "expertise की ज़रूरत नहीं" वाला दावा उठा था, लेकिन अंत में engineering discipline की ज़रूरत फिर साबित हुई
• LLM design exploration और शुरुआती implementation को तेज़ करने का बेहतरीन tool है, लेकिन इसका उपयोग engineering discipline को replace करने के लिए नहीं, बल्कि उसे मजबूत करने के लिए होना चाहिए

---

उद्योग का खतरनाक भ्रम

• जैसे ही LLM कोड generate करने लगे, software industry में ऐसा माहौल बन गया कि software engineering की अब ज़रूरत ही नहीं रही
• architecture, specification, और careful verification जैसी disciplines को मानो बीते ज़माने की चीज़ समझा जा रहा है
• कुछ संगठनों में यह सोच पहले ही policy में बदल चुकी है, और AI की प्रगति का हवाला देकर engineers की बड़े पैमाने पर layoffs हो रहे हैं
• AI दरअसल गलत business decisions या market pressure से बचने का सबसे नया बहाना भर है
• AI को prompt देना धीरे-धीरे उस discipline के विकल्प के रूप में पेश किया जा रहा है जो software engineering को परिभाषित करती थी

इतिहास का दोहराया जाने वाला पैटर्न

• 40 साल से अधिक के करियर में एक ही पैटर्न बार-बार दिखा: नया tool आता है → घोषणा होती है कि मुश्किल समस्याएँ हल हो गईं → productivity उछलती है और प्रभावशाली demo दिखते हैं → headcount में कटौती → system complexity बढ़ती है → और आखिर में नतीजे उम्मीद से अलग निकलते हैं
• tools और दावे बदलते रहते हैं, लेकिन पैटर्न लगभग वही रहता है

विमान रखरखाव की उपमा

• aircraft maintenance में tools, computer diagnostics, digital manuals, और AI telemetry interpretation जैसी बड़ी प्रगति हुई है, फिर भी skilled technicians की ज़रूरत बनी हुई है
• commercial aircraft सैकड़ों लाख parts और हजारों interconnected subsystems वाले बेहद जटिल systems हैं
• समस्या का diagnosis केवल सही tool या checklist का पालन करना नहीं है, बल्कि वास्तविक operating conditions में system कैसे behave करता है, इस पर अनुभव और judgment चाहिए
• कोई भी airline सिर्फ tools बेहतर हो जाने के कारण trained mechanics को हटाकर gate agents से repair कराने का प्रस्ताव नहीं देगी
• लेकिन software industry लगभग यही बात अपने बारे में कह रही है

DIY बनाम पेशेवर systems

• hobby projects, छोटे personal apps, और नए ideas पर experiment करना बिल्कुल समस्या नहीं है; computing के इतिहास के कई सबसे रोचक ideas ऐसे ही प्रयोगों से आए हैं
• लेकिन professional software development एक पूरी तरह अलग श्रेणी है: payment processing, sensitive data storage, infrastructure management, और वे systems जिन पर लोग हर दिन निर्भर रहते हैं
• customers स्वाभाविक रूप से उम्मीद करते हैं कि system सही चले, evolve होने पर भी सही बना रहे, और जो लोग इसे बना रहे हैं वे system के काम करने के तरीके को समझते हों
• ये अपेक्षाएँ professional engineering की बुनियादी शर्तें हैं, और यहीं discipline व expertise अपरिहार्य हो जाते हैं

कोड कभी मुश्किल हिस्सा था ही नहीं

• software development में कोड लिखना ही सबसे कठिन हिस्सा है, यह बहुत पुरानी गलतफहमी है
• syntax टाइप करना हमेशा system building का सबसे कम रोचक हिस्सा रहा है; असली कठिन काम है system behavior तय करना, components के interaction का design करना, और complexity बढ़ने पर understandability बनाए रखना
• यह coding problem नहीं, बल्कि engineering problem है
• कोड उत्पादन में लगने वाला प्रयास कम होने से ये समस्याएँ खत्म नहीं होतीं; बस अब बड़े और अधिक जटिल systems को तेज़ी से बनाना संभव हो जाता है
• इसे productivity gain मानना भ्रम है: बोझ बस दूसरी जगह चला गया है
  • code review और generated code को संभालने में लगने वाला cognitive load अक्सर कोड लिखने से भी बड़ा productivity drag बन जाता है
  • अगर underlying behavior को पर्याप्त रूप से समझे बिना केवल गति बढ़ा दी जाए, तो यह सिर्फ उस बिंदु को तेज़ करता है जहाँ complexity असंभालनीय हो जाती है, और नतीजा फिर भी गलत होता है

यह पैटर्न पहले भी देखा गया: Visual Basic युग

• 1990 के दशक में Visual Basic को लेकर भी ऐसे ही वादे थे: programming का लोकतंत्रीकरण हो गया है और specialist knowledge की अब ज़रूरत नहीं रही
• वास्तव में, Visual Basic ने कई ऐसे applications बनाना संभव किया जो अन्यथा शायद कभी नहीं बनते
• लेकिन जैसे-जैसे systems बड़े और interconnected हुए, यह फिर स्पष्ट हुआ कि software artifacts बनाना और reliable systems engineer करना एक ही बात नहीं है
• आज हम उसी पैटर्न का और अधिक तीव्र संस्करण देख रहे हैं: अब बाधा सिर्फ application building की नहीं, बल्कि code production की भी कम हो गई है
• यहीं से यह आकर्षक विश्वास पैदा होता है कि expertise अब ज़रूरी नहीं रही

Alignment की समस्या

• reliable software उस alignment पर निर्भर करता है जिसकी engineering के बाहर बहुत कम चर्चा होती है
• system की शुरुआत behavior के एक idea से होती है → उसे specification में document किया जाता है → engineers specification को tests और production code में बदलते हैं
• किसी system की long-term reliability के लिए specification, tests, और implementation — इन तीनों का हर समय aligned रहना ज़रूरी है
• जैसे ही ये तीनों अलग होने लगते हैं, system धीरे-धीरे अपनी integrity खोने लगता है
  • specification ऐसे behavior का वर्णन करने लगती है जो अब implement ही नहीं है
  • tests behavior के केवल कुछ हिस्सों को verify करते हैं और बाकी छूट जाता है
  • बाद में जुड़ने वाले engineers code पढ़कर system behavior का अनुमान लगाते हैं, जबकि वह code मूल design को दर्शाता भी हो सकता है और नहीं भी
• समय के साथ ये अनुमान जमा होते जाते हैं, और अंत में system ऐसा बन जाता है जिसे वास्तव में कोई भी पूरी तरह नहीं समझता
• इस घटना को "spec drift" कहा गया है: system का विवरण और system स्वयं धीरे-धीरे एक-दूसरे से अलग हो जाते हैं
  • code बदल गया, लेकिन specification वैसी ही रही
  • specification evolve हुई, लेकिन tests स्थिर रहे
  • behavior धीरे-धीरे बदलता गया, और किसी को भी भरोसे से नहीं पता कि मूल intent क्या था
• alignment टूटने पर reliability लंबे समय तक टिक नहीं सकती

AI drift को तेज़ करता है

• LLM code production को नाटकीय रूप से तेज़ कर देते हैं, और यही उनकी सबसे बड़ी ताकत होने के साथ जोखिम का बिंदु भी है
• जब कोड उसके आसपास की engineering discipline से तेज़ी से बनने लगता है, तो spec drift पैदा करने वाली ताकत भी तेज़ हो जाती है
• जो बदलाव कभी careful thinking और manual implementation मांगते थे, वे अब कुछ ही सेकंड में हो सकते हैं
• system के पूरे section को rewrite किया जा सकता है इससे पहले कि कोई यह जाँच सके कि behavior अभी भी specification के अनुरूप है या नहीं
• code अक्सर ठीक-ठाक, compilable, readable दिखता है, और शायद existing tests भी पास कर लेता है, लेकिन system को नियंत्रित करने वाला alignment पहले ही गायब हो चुका हो सकता है
• जो चीज़ productivity जैसी दिखती है, वह वास्तव में पहले से कहीं तेज़ misalignment की दिशा में बढ़ने की क्षमता हो सकती है

जहाँ AI वास्तव में मददगार है

• LLM कोई गलती नहीं हैं; सोच-समझकर इस्तेमाल किए जाएँ तो वे engineers के system explore करने और design करने के तरीके को नाटकीय रूप से बेहतर बना सकते हैं
• जिन क्षेत्रों में वे खास तौर पर मजबूत हैं: समस्या पर reasoning, design alternatives का exploration, complex systems का सार निकालना, और implementation के शुरुआती चरणों को तेज़ करने वाले drafts तैयार करना
• जिन क्षेत्रों में वे कमजोर हैं: वे काम जिनमें समय के साथ कठोर discipline और consistency चाहिए
• specification, tests, और implementation के बीच alignment बनाए रखना अब भी engineering responsibility है; कोई tool इस जिम्मेदारी की जगह नहीं ले सकता, सिर्फ मदद कर सकता है
• असली अवसर LLM का उपयोग engineering process को चुपचाप replace करने में नहीं, बल्कि उसे मजबूत करने में है

Conversational software engineering

• LLM ने जो दिलचस्प संभावना खोली है, उनमें से एक यह है कि software engineering का कुछ हिस्सा अधिक conversational हो सकता है
• दशकों तक system design tools काफ़ी rigid रहे हैं: specifications documents में, architecture diagrams में, और वहाँ तक पहुँचने वाली reasoning meetings और hallway conversations में खो जाती थी
• LLM के साथ engineers ideas को interactive तरीके से explore कर सकते हैं, assumptions को test कर सकते हैं, और design work को स्वाभाविक बातचीत के अधिक करीब तरीके से कर सकते हैं
• लेकिन conversation engineering नहीं है: conversation ideas explore करने का तरीका है, जबकि engineering तब शुरू होती है जब ideas को verified, tested, और maintainable रूप में capture किया जाता है
• अगली पीढ़ी के engineering tools के सामने चुनौती यह है कि इन दोनों दुनियाओं को कैसे जोड़ा जाए, बिना उस discipline को खोए जिसकी complex systems को ज़रूरत होती है

Expertise अब भी मायने रखती है

• professional software को आज भी ऐसे engineers की ज़रूरत है जो वे systems वास्तव में कैसे काम करते हैं, यह समझते हों
• tools development को तेज़ कर सकते हैं, लेकिन complex systems को design, reason, और maintain करने के लिए ज़रूरी expertise को खत्म नहीं कर सकते
• industry इस बात को भूल जाने के खतरनाक रूप से करीब पहुँच गई है
• LLM अनुभवी engineers को बहुत अधिक productive बना सकते हैं, लेकिन reliable systems बनाने के लिए आवश्यक engineering discipline की जगह नहीं लेते
• इन tools का उपयोग पूजा की तरह नहीं, बल्कि प्रभावी ढंग से किया जाना चाहिए

[GN⁺]

Hacker News की राय

• मैं लेख के आधारभूत तर्क से सहमत नहीं हूँ। मुझे लगता है कि इंजीनियरिंग समग्र रूप से आसान हुई है, चाहे अच्छे अर्थ में हो या बुरे में। पहले भी मैंने बहुत से लोगों को बिना समझे बस ढेर सारे null checks डालते देखा है। अब बस वही चीज़ बड़े पैमाने पर हो रही है। दूसरी ओर, बेहतरीन इंजीनियरिंग और भी ज़्यादा amplified हुई है; मैंने ऐसे मामले भी देखे हैं जहाँ पहले जिन features में हफ्तों लगते थे, वे अब कुछ दिनों में बन रहे हैं

  • मुझे लगता है कि लेख थोड़ा बढ़ा-चढ़ाकर लिखा गया है। अच्छी इंजीनियरिंग भी LLM-आधारित agents की मदद ले सकती है, लेकिन परिणामों का सत्यापन अभी भी इंसानों का काम है। खराब इंजीनियरिंग वही चरण छोड़ देती है, इसलिए Amdahl's Law के नज़रिए से देखें तो LLM खराब इंजीनियरिंग को कहीं ज़्यादा तेज़ करता है
  • खराब इंजीनियरिंग बहुत ज़्यादा आसान हो गई है, और अच्छी इंजीनियरिंग थोड़ी आसान हुई है। इसलिए जो लोग पहले अच्छी इंजीनियरिंग कर रहे थे, वे अब तीन गुना ज़्यादा खराब इंजीनियरिंग करने लगे हैं
  • enterprise app development में मैंने mock tests ऐसे देखे हैं जो बस यह जाँचते हैं कि expected value वापस आई या नहीं। इसका मतलब ही क्या है, समझ नहीं आता
  • यह भूलना आसान है कि LLM कोई जादुई oracle नहीं है। उसके outputs को आप कैसे handle करते हैं, वही परिणाम की quality तय करता है। कुछ मामलों में उसे ज्यों-का-त्यों इस्तेमाल किया जा सकता है, लेकिन ज़्यादातर बार उसमें बदलाव चाहिए होता है। “LLM ने कहा है तो सही ही होगा” वाले जाल में फँसना आसान है, इसलिए खराब इंजीनियरिंग आसान हो जाती है
  • अगर मूल लेख से सहमत भी हों, तब भी व्यवहार में ऐसे बहुत से application domains हैं जहाँ software quality अच्छी हो या खराब, उससे खास फर्क नहीं पड़ता। कई बार बस काम चल जाना ही काफी होता है

• ऐसे मामले होते हैं जहाँ सौ unit tests भी code की correctness साबित करने के लिए काफी नहीं होते। ज़्यादातर developers को पता ही नहीं होता कि कितना पर्याप्त है। जो लोग बहुत vibe coding करते हैं, वे testing भी मशीन पर छोड़ देते हैं। system design के स्तर पर पहुँचने पर ऐसी design चाहिए जो समग्र safety और temporal invariants की गारंटी दे सके। लेकिन ज़्यादातर लोग बस boxes और arrows बनाते हैं और “best practices” का हवाला देते हैं। Sussman effect की तरह software प्राकृतिक विज्ञान के अधिक करीब है, इसलिए हम observation पर ज़्यादा समय लगाने लगते हैं। GenAI को एक tool की तरह इस्तेमाल करना उपयोगी हो सकता है, लेकिन सोचना बंद करके tool पर निर्भर हो जाना खतरनाक है

  • मुझे unit test क्या होता है, यह भी नहीं पता, लेकिन AI की वजह से मैं ऐसे programs बना सकता हूँ जो मेरे असली काम में बहुत मदद करते हैं। elite programmers तो पैसे देने पर भी ईमेल का जवाब नहीं देते

• हर कुछ साल में जब भी कोई नया tool आता है, लोग कहते हैं कि “software engineering का कठिन हिस्सा हल हो गया।” productivity उछल जाती है, demos प्रभावशाली होते हैं, और industry खुद की पीठ थपथपाती है। लेकिन उसके बाद जल्दी ही headcount reduction आता है। अगर सचमुच कोई breakthrough हो तो अच्छा है, लेकिन अगर उसका नतीजा layoffs है, तो उसका क्या मतलब? आखिर सवाल वही है — अगर लक्ष्य jobs कम करना है, तो जब लोग अपनी आजीविका नहीं चला पाएँगे, तब corporate vision क्या होगा?

  • लक्ष्य व्यक्तिगत रोजगार नहीं है। AGI बनाना ही अंतिम लक्ष्य है, और इस प्रक्रिया में developers की salary और employment शायद पहले ही peak पर पहुँच चुके हैं। कुछ AI super developers इसका अपवाद हो सकते हैं
  • मुझे नहीं लगता कि complexity को हटाना संभव है। वास्तविकता और इंसान खुद जटिल हैं। यह सोचना कि software सरल हो सकता है, अवास्तविक है। बड़े परिप्रेक्ष्य में देखें तो लक्ष्य आखिरकार मध्यवर्ग के क्षय जैसा लगता है
  • अगर मांग नहीं है, तो दूसरा काम करना होगा। मना करोगे तो भूखे रहोगे
  • पूँजीवाद निम्न वर्ग के अस्तित्व पर निर्भर करता है। वही दूसरे workers पर दबाव बनाता है ताकि वे कम वेतन और बदतर शर्तें स्वीकार करें। programmers बस कुछ समय के लिए उस वास्तविकता से बचे हुए थे। यह संरचना प्रवासी श्रम से भी जुड़ी है, और कंपनियाँ खतरनाक काम करवाकर अवज्ञा होने पर deport भी करवा सकती हैं। अंततः, यह सब labor cost कम करने की व्यवस्था है

• मैं इस बात से सहमत हूँ कि “coding कभी असल में कठिन हिस्सा था ही नहीं।” experts पहले से जानते थे कि क्या बनाना है; बस repetitive काम उबाऊ था

  • code maintenance अब भी इंसानों और अनुभव का सवाल है। “कौन-सा code नहीं लिखना चाहिए” यह और ज़्यादा महत्वपूर्ण हो गया है। अब code generation इतना आसान हो गया है कि spaghetti code का ढेर लगाना बहुत आसान है
  • LLM बहस का केंद्र यही है। कुछ लोग बस output चाहते हैं, कुछ लोग maintainability और stability चाहते हैं। दोनों दृष्टिकोणों की ज़रूरत है, और prototype तथा production की भूमिकाएँ स्वाभाविक रूप से अलग हो जाएँगी
  • जो लोग सचमुच कुशल हैं, वे अब भी खुद करना चाहते हैं। LLM की वजह से नहीं, वे पहले से ऐसे ही थे। बल्कि सबसे ज़्यादा फायदा उन्हें हो रहा है जो कहते थे, “syntax टाइप करना मज़ेदार नहीं है।” मेरे लिए तो typing खुद ही एकमात्र दिलचस्प हिस्सा है

• जो junior developers AI पर बहुत ज़्यादा निर्भर हो रहे हैं, उन्हें बाद में बुनियादी चीज़ें न आने की कीमत चुकानी पड़ेगी। अंततः job security सिर्फ अनुभवी लोगों के पास बचेगी

• “code लिखना कठिन हिस्सा नहीं था” इस दावे से सहमत होना कठिन है। बेशक यह हमेशा कठिन नहीं होता, लेकिन time constraints हों तो code लिखना bottleneck बन जाता है। AI ऐसे प्रयास संभव बना रहा है जो पहले असंभव थे, और इससे अधिक engineering time मिलता है

  • “इसे गंभीरता से लेना कठिन है” कहते हुए भी अंत में सहमत होना विरोधाभासी है। मूल लेख में इससे कहीं अधिक सूक्ष्म बारीकियाँ हैं
  • code लिखना सबसे समय खा जाने वाला काम था, और AI ने उसी को रेखांकित किया है। typing तो कोई भी कर सकता है, लेकिन code पढ़ने की क्षमता ही असली कौशल है। कुल्हाड़ी की जगह chainsaw पकड़े लकड़हारे की तरह, efficiency बढ़ती है लेकिन नुकसान भी बड़ा हो सकता है

• AI ने अच्छी इंजीनियरिंग को भी आसान बनाया है। आखिरकार यह एक behavior amplifier है

  • अच्छे engineers अब और बेहतर कर सकते हैं, लेकिन ज़्यादातर लोगों को property testing क्या है, यह भी नहीं पता। ऐसे लोगों के लिए AI कितना उपयोगी होगा, इस पर संदेह है
  • इंटरनेट ने दुनिया भर के ज्ञान को जोड़ दिया, लेकिन इंसान आखिरकार बकवास और खपत-प्रधान कंटेंट में ही डूब गए। मानव स्वभाव को देखें तो AI भी शायद उसी रास्ते पर जाएगा
  • रचनात्मक समस्याएँ अक्सर खुद code लिखने की प्रक्रिया में हल होती हैं। AI का उपयोग करने पर वह दिमागी सर्किट कम सक्रिय होता है
  • DORA report जैसे data भी इसका समर्थन करते हैं
  • “AI मौजूदा व्यवहार का amplifier है” यह पंक्ति सचमुच बहुत सटीक है। इसे ज्यों-का-त्यों इस्तेमाल करना चाहिए

• मैं AI skeptic हूँ, लेकिन मुझे नहीं लगता कि यह मेरे सहकर्मियों की jobs छीन रहा है। इसके बजाय यह मेरा समय बचाता है। मैं इसे Google से बेहतर research tool की तरह इस्तेमाल करता हूँ, और यह codebase exploration, helper functions बनाने, और errors की समीक्षा में उपयोगी है

  • मैं भी सहमत हूँ। मुझे लगता है कि यही अंततः AI उपयोग का अंतिम ठिकाना है

• आजकल software engineering और research के बीच का अंतर और स्पष्ट होता जा रहा है। exploratory research में AI एक अद्भुत tool है। जब संभावना दिखती है, तब मैं SWE mode में स्विच करता हूँ, code को समझता और बदलता हूँ, और अपने अनुभव से उसे निखारता हूँ। AI की भूमिका सीमित है, लेकिन फिर भी उपयोगी है

  • LLM इंसानों की तुलना में बहुत व्यापक ज्ञान-क्षेत्र को तुरंत explore कर सकता है। लेकिन अंतिम निर्णय अब भी इंसान की रुचि और quality sense पर निर्भर करता है

• इन लोगों (निराशावादियों) के हार मानने तक और कितने model versions आने होंगे? दो? तीन?