जनरेट करना बंद करें, सोचना शुरू करें

• LLM code generation टूल्स को लेकर इंडस्ट्री के उत्साही अपनाने के बीच, यह लेख software development में सोच की अहमियत पर ज़ोर देता है
• ऑटो-जनरेटेड code non-deterministic होता है और इसकी अंदरूनी कार्यप्रणाली अपारदर्शी होती है, इसलिए यह हर बार एक जैसे नतीजे सुनिश्चित करने वाली mechanization से मूल रूप से अलग है
• LLM मौजूदा low-quality code से सीखकर वही गलतियाँ दोहराता है, और फिर उसी को दोबारा सीखता है — इसे "human centipede epistemology" समस्या कहा गया है
• code generation को agents को सौंपने पर PR review के दौरान shared context और accountability कमजोर हो जाते हैं, जिससे software quality पर बुरा असर पड़ता है
• LLM prototyping जैसे सीमित उपयोगों में उपयोगी है, लेकिन developers का सोचने की प्रक्रिया को ही outsource कर देना खतरनाक है और बिना समझ के maintenance संभव नहीं

---

LLM code generation को लेकर असहजता

• लंबे समय तक इंडस्ट्री के नए रुझानों के साथ चलते हुए CSS, JS की नई सुविधाएँ सहकर्मियों के साथ साझा करने के बावजूद, LLM-आधारित code generation के तेज़ फैलाव ने पीछे छूट जाने जैसी बेचैनी पैदा की
• Copilot और Claude को "spicy autocomplete" और debugging सहायक के रूप में इस्तेमाल किया गया, लेकिन थोड़ा भी जटिल काम देने पर नतीजे बिखरे हुए निकले
• पर्याप्त context देना पड़ता है, लेकिन बहुत ज़्यादा देने पर overload हो जाता है, और "आप distributed systems के expert हैं" जैसे LLM के अहम को सहलाने वाले लंबे prompts लिखने पड़ते हैं
• कई बार prompt सुधारने में लगने वाले समय से खुद code लिखना ज़्यादा तेज़ होता है
• यह सवाल उठता है कि engineers coding जैसे आनंददायक काम को छोड़कर सिर्फ review जैसे उबाऊ काम तक खुद को क्यों सीमित करना चाह रहे हैं

"औद्योगिक क्रांति की पुनरावृत्ति" वाले दावे पर आपत्ति

• जैसे औद्योगिक क्रांति ने climate change में योगदान दिया, वैसे ही AI data centers की भारी energy consumption में एक समान पैटर्न दिखता है
  • सारी बिजली fossil fuel-आधारित नहीं होती, फिर भी "shrimp jesus" जैसी image generation पर भारी संसाधन बर्बाद होते हैं
• mechanization ने चीज़ों को सस्ता और व्यापक बनाया, लेकिन quality में गिरावट भी लाई; नतीजा यह कि SHEIN पर coffee के एक कप से भी सस्ती पैंट मिल जाती है
  • इससे skilled labour का क्षय, low-wage देशों में factories का स्थानांतरण और workers का शोषण बढ़ा
• generated code fast fashion जैसा है: ऊपर से ठीक दिखता है, लेकिन समय के साथ छेदों से भर जाता है, अक्सर दूसरों के code को बिना अनुमति उधार लेता है, और पर्यावरण पर भी नकारात्मक असर डालता है
• सबसे बड़ा अंतर यह है कि mechanization हर बार एक जैसा परिणाम देती थी और समस्या होने पर उसके अंदर झाँका जा सकता था, जबकि LLM output non-deterministic है और उसकी अंदरूनी कार्यप्रणाली अपारदर्शी है
  • हर बार अलग नतीजे देने वाली और बीच-बीच में hallucination मिलाने वाली mechanized प्रक्रिया उपयोगी नहीं हो सकती

"abstraction की नई layer" वाले दावे पर आपत्ति

• Java या Go इस्तेमाल करते समय assembly सीखना ज़रूरी नहीं रह गया, और garbage collection या memory allocation जैसी चीज़ें runtime संभाल लेता है
• लेकिन system architecture, critical path पर असर, maintainability बनाम deployment speed के trade-offs, browser compatibility, accessibility, security, performance जैसी बातें अब भी developer को खुद सोचनी पड़ती हैं
• LLM सबसे बड़ा नुकसान वहाँ करता है जहाँ engineer software development के लिए ज़रूरी सोचने की प्रक्रिया को ही outsource कर देता है
  • चूँकि LLM में reasoning capability नहीं होती, इसलिए अगर developer भी न सोचे और LLM भी न सोचे, तो कोई भी नहीं सोच रहा होता
• Horizon scandal का उदाहरण: Post Office software bug की वजह से निर्दोष कर्मचारियों को जेल हुई, और 13 लोगों ने आत्महत्या की
  • software के लिए accountability पहले से कहीं ज़्यादा महत्वपूर्ण है

low-quality code ही मूल समस्या है

• इंसानी developers भी ऐसा code लिखते रहे हैं जो accessibility में कमजोर है, performance में धीमा है, और JavaScript पर ज़रूरत से ज़्यादा निर्भर है
• LLM ऐसे low-quality code को training data के रूप में सीखता है (वह भी स्पष्ट सहमति के बिना) और वही गलतियाँ दोहराता है
• LLM द्वारा बनाए गए low-quality code को फिर दूसरा LLM सीखता है — यह चक्रीय संरचना ही "human centipede epistemology" कहलाती है
• assistive technology users, कमजोर internet वाले users, और facial recognition software के नस्लवादी असर से प्रभावित लोगों को ध्यान में रखें तो मौजूदा software quality पर्याप्त नहीं है
• इंसानों के रूप में सीखने और सुधारने के बजाय, हमने गलतियों को बिना सोचे-समझे algorithm को outsource कर दिया है

PR review और shared context का कमजोर होना

• FFConf में Jessica Rose और Eda Eren की talk का मुख्य संदेश: "जो code आपने खुद नहीं लिखा, वह ऐसा code है जिसे आप समझते नहीं; और जिसे आप समझते नहीं, उसका maintenance नहीं कर सकते"
• किसी सहकर्मी के लिखे PR में एक स्तर का trust और thought process शामिल होता है, लेकिन LLM-generated PR में ऐसी कोई गारंटी नहीं
• open source maintainers low-quality LLM-generated PRs की बाढ़ का सामना कर रहे हैं
• कुछ कंपनियाँ Slack में Claude से chat के ज़रिए code changes मांगती हैं, और उसी तरह auto-generated PR को वही व्यक्ति approve भी कर देता है
  • ऐसे में जिम्मेदारी सिर्फ एक reviewer पर केंद्रित हो जाती है, और two pairs of eyes में से एक खो जाता है
  • team के भीतर shared context भी घटता है
• PR review सिर्फ bugs पकड़ने की प्रक्रिया नहीं, बल्कि code और changes की साझा समझ बनाने की प्रक्रिया भी है

प्रगति के खिलाफ नहीं, hype के खिलाफ

• आपत्ति LLM से नहीं, बल्कि "artificial intelligence" की branding से है
  • LLM intelligent नहीं है, यह machine learning का एक रूप है
  • "generative AI" लोगों की अत्यधिक अपेक्षाओं से घिरा बहुत अच्छी तरह बनाया गया Markov chain है
• prototype, wireframe, या interactive demo जल्दी बनाने के लिए इसका उपयोग उचित हो सकता है
• समस्या तब है जब लोग मान लें कि "vibe coding" से production-grade software बनाया जा सकता है, या coding की सोचने की प्रक्रिया ही सौंप दें
• Zed blog पर Mikayla Maki का दृष्टिकोण: agents को ऐसे बाहरी contributor की तरह देखें जिस पर आप भरोसा नहीं करते, उनका उपयोग सिर्फ उन्हीं कामों में करें जिनका तरीका आप पहले से जानते हैं, और code को समझना अनिवार्य है
• "spicy autocomplete" का उपयोग जारी रह सकता है, लेकिन सोच को outsource नहीं किया जाएगा, और यह याद रखना चाहिए कि शुरुआत में इस काम से प्यार क्यों हुआ था