एलएलएम आलोचक सही हैं। फिर भी मैं एलएलएम का उपयोग करता हूँ

आलोचना का दायरा बनाम उपयोग

• कई टिप्पणीकार मानते हैं कि एलएलएम से जुड़ी प्रमुख आलोचनाएँ (हैलुसिनेशन, कौशल-क्षय, केंद्रीकरण, पर्यावरणीय लागत, नैतिकता) वैध हैं, फिर भी वे एलएलएम का बड़े पैमाने पर उपयोग करते हैं।
• कुछ का तर्क है कि किसी त्रुटिपूर्ण उपकरण का उपयोग करना विरोधाभासी नहीं है, बशर्ते उसकी सीमाएँ ध्यान में रखी जाएँ; आलोचक और उपयोगकर्ता परस्पर अलग समूह नहीं हैं।
• कुछ लोग एलएलएम आउटपुट को बिना सोचे-समझे “slop” कहकर खारिज करने को वर्तमान क्षमताओं से इनकार मानते हैं; दूसरे लोग अंध उत्साह को भी उतना ही पक्षपाती मानते हैं।

कौशल-क्षय और ज्ञान की गहराई

• यह गंभीर चिंता है कि “निम्न-स्तरीय” काम (कोडिंग के विवरण, regex, डिबगिंग) को बाहर सौंपने से वर्षों में मौलिक कौशल और वास्तुकला-संबंधी निर्णय-क्षमता कमजोर हो जाएगी।
• प्रतिवाद: हमने हमेशा परतों को अमूर्त किया है (कैलकुलेटर, कंपाइलर, क्लाउड); वास्तव में बहुत कम लोगों को गहरे निम्न-स्तरीय कौशल की ज़रूरत होती है।
• कई लोग बताते हैं कि एजेंटों पर निर्भर रहने से उनकी स्मरण-शक्ति और retention पहले से कमजोर लगने लगी है; कुछ लोग जानबूझकर अपने शौकिया प्रोजेक्ट्स को एलएलएम-रहित रखते हैं ताकि अपनी कौशल-क्षमता का “exercise” कर सकें।
• इस पर बहस कि क्या उच्च-स्तरीय डिज़ाइन निम्न-स्तरीय समझ के बिना अच्छी तरह किया जा सकता है; “systems engineers” और एआई उपयोगकर्ताओं द्वारा असंगत आर्किटेक्चर बनाने के उदाहरण दिए जाते हैं।

उत्पादकता, गुणवत्ता, और सत्यापन

• रिपोर्टें “कोई शुद्ध लाभ नहीं” (समीक्षा में लगा समय जनरेशन लाभ को खा जाता है) से लेकर “व्यक्तिगत उत्पादकता ~1.5–2x” और “छंटनी के बाद टीम आउटपुट ~25% ऊपर” तक फैली हुई हैं।
• उद्धृत शोध के अनुसार डेवलपर लाभ को व्यवस्थित रूप से अधिक आँकते हैं; टीम-स्तर पर वृद्धि मामूली होती है और अक्सर ओवरहेड या अतिरिक्त प्रयोगों में खप जाती है।
• लाभ बहुत हद तक संदर्भ और गुणवत्ता-मानक पर निर्भर हैं: जब “slop is fine” हो या boilerplate के लिए, तब एलएलएम चमकते हैं; उच्च-गुणवत्ता, सुरक्षा-महत्वपूर्ण काम में ये आपको धीमा कर सकते हैं।
• कई लोग कहते हैं कि डेवलपर इन लाभों को अधिक burnout से बचने या साइड प्रोजेक्ट्स के लिए “cash in” करते हैं, न कि कॉर्पोरेट आउटपुट बढ़ाने के लिए।
• साझा दृष्टिकोण: भरोसा और समीक्षा इस बात से अधिक महत्वपूर्ण हैं कि कोड AI-लिखित है या नहीं। छोटे, परीक्षण-समर्थित diffs संभाले जा सकते हैं; बड़े agent-generated बदलाव नहीं।

टेस्टिंग, कोड रिव्यू, और एजेंट्स

• चिंता है कि एलएलएम-लिखित tests सतही हो सकते हैं, फिर भी प्रभावशाली coverage numbers दिखा सकते हैं, जिससे झूठा आत्मविश्वास पैदा होता है।
• कुछ लोग test suites जनरेट या refactor करने के लिए एलएलएम का प्रभावी उपयोग करते हैं, लेकिन मानव समीक्षा और line/branch coverage से बेहतर metrics पर ज़ोर देते हैं।
• Agents संरचनात्मक रूप से गंदे codebases बना सकते हैं, भले ही स्थानीय snippets ठीक हों; architecture और constraints की ज़िम्मेदारी मानवों पर ही रहती है।

जूनियर्स, मेंटरशिप, और ओपन सोर्स

• चिंता है कि “junior tasks” को agents से बदलना training pipelines और दीर्घकालिक code quality को नुकसान पहुँचाता है।
• ओपन सोर्स maintainers कम-गुणवत्ता वाले, AI-लिखित PRs की बाढ़ की रिपोर्ट करते हैं, जिन्हें अक्सर सुधार खुद लिखने से भी अधिक मुश्किल होता है, और इससे अधिक gatekeeping होती है।
• दूसरे लोग बताते हैं कि LLM-सहायता प्राप्त सहकर्मी कभी-कभी अधिक idiomatic code जमा करते हैं, जिससे review load वास्तव में घटता है।

संज्ञानात्मक और सामाजिक प्रभाव

• आशंका है कि सर्वव्यापी एलएलएम उपयोग लेखन और सोच को समरूप बना देगा, जैसे platforms संस्कृति को आकार देते हैं; दूसरे इन्हें केवल “common sense” को विस्तारित करने वाला एक और उपकरण मानते हैं।
• कुछ लोग एलएलएम को tutors और interview-prep partners की तरह उपयोग करते हैं और वास्तविक सीखने के लाभ रिपोर्ट करते हैं।

नैतिकता, पर्यावरण, और token उपयोग

• नैतिक आपत्तियाँ data provenance, corporate behavior, और environmental impact पर केंद्रित हैं; इसके बावजूद एलएलएम का उपयोग करना एक ज्ञात dissonance माना जाता है।
• carbon cost पर बहस: कुछ के अनुसार रोज़ाना token उपयोग commute/food की तुलना में मामूली है; दूसरे data center growth के संचयी प्रभाव और AI energy share के अनुमानित हिस्से पर ज़ोर देते हैं।
• बड़े token spends (जैसे ~$10k/month) विवादास्पद हैं: कुछ इसे waste या agents का misuse मानते हैं; दूसरे इसकी तुलना एक और engineer की लागत से अनुकूल रूप में करते हैं।