कोड लिखना कभी भी असली bottleneck नहीं था

• सॉफ़्टवेयर डेवलपमेंट में bottleneck कोड लिखना नहीं, बल्कि code review, knowledge transfer, testing, debugging, collaboration/communication जैसी कई human-centered processes में होता है
• LLM की वजह से code generation खुद बहुत आसान हो गया है, लेकिन समझने, verify करने और trust बनाने की लागत और बोझ उल्टे और बढ़ गए हैं
• तेज़ code generation, reviewer, integrator और maintenance की ज़िम्मेदारी निभाने वालों पर और ज़्यादा बोझ डालता है, और पूरी टीम की गति वास्तव में तेज़ नहीं होती
• Code understanding सबसे कठिन हिस्सा है, और LLM कोड बना भी दे तो भी टीम में trust और context sharing के बिना quality की गारंटी नहीं होती
• LLM prototyping और automation में शक्तिशाली है, लेकिन सावधानीपूर्ण design, review और shared context जैसी सॉफ़्टवेयर डेवलपमेंट की बुनियादी ज़रूरतों की जगह नहीं ले सकता

---

कोड लिखने का असली bottleneck

• कई वर्षों से कोड लिखने का काम खुद सॉफ़्टवेयर इंजीनियरिंग का bottleneck नहीं रहा है
• असली bottleneck code review, mentoring और pair programming के ज़रिए knowledge transfer, testing, debugging, और collaboration/communication की लागत में पैदा होता है
• Ticket management, planning meetings, agile meetings जैसी जटिल प्रक्रियाएँ गति को और धीमा करती हैं
• Quality assurance के लिए ये प्रक्रियाएँ वास्तव में कोड लिखने से कहीं ज़्यादा समय और सोच की माँग करती हैं
• लेकिन LLM की वजह से काम करने वाला code generate करने की लागत लगभग 0 के करीब पहुँच रही है
• इसके विपरीत, code समझने, test करने और उस पर trust बनाने की लागत और बढ़ जाती है
• शुरुआती implementation की रफ़्तार बढ़ी है, लेकिन ज़्यादा कोड review/integration/maintenance के दायरे में आकर बोझ बढ़ाता है

LLM काम की प्रकृति बदलता है – उसे हटाता नहीं

• Claude जैसे LLM tools शुरुआती implementation की गति बढ़ाते हैं, लेकिन अंततः कम समय में ज़्यादा कोड सिस्टम में आने लगता है, जिससे review और maintenance संभालने वालों पर ज़्यादा बोझ पड़ता है
• ख़ास तौर पर यह बोझ इन स्थितियों में और बढ़ जाता है
  • यह स्पष्ट न हो कि लेखक अपने ही जमा किए गए कोड को पर्याप्त रूप से समझता है या नहीं
  • Generated code ऐसे patterns का हो जिनसे टीम परिचित न हो, या वह मौजूदा conventions का उल्लंघन करता हो
  • Boundary conditions और अनचाहे side effects साफ़ तौर पर दिखाई न दें
• इसकी वजह से कोड बनाना आसान हो जाता है, लेकिन verification की कठिनाई बढ़ जाती है, और नतीजतन पूरी टीम की रफ़्तार नहीं बढ़ती
• पहले डेवलपर्स के बीच “copy-paste engineering” को लेकर मज़ाक होता था, लेकिन LLM के साथ यह प्रवृत्ति बहुत ज़्यादा बढ़ गई है

कोड को समझना ही असली कठिनाई है

> “कोड की सबसे बड़ी लागत उसे लिखना नहीं, उसे समझना है”

• LLM की वजह से code production तेज़ हो सकता है, लेकिन उसके व्यवहार का अनुमान लगाना, सूक्ष्म bugs ढूँढना, या लंबी अवधि की maintenance सुनिश्चित करना कभी आसान नहीं होता
• ख़ास तौर पर तब यह और कठिन हो जाता है जब reviewer generated code और manually लिखे गए code में अंतर न कर पाए, या चुने गए समाधान के पीछे की वजह समझना मुश्किल हो

टीम अब भी trust और shared context पर निर्भर है

• सॉफ़्टवेयर डेवलपमेंट मूल रूप से collaboration पर आधारित है, और पूरी तरह shared understanding, alignment, और mentoring पर निर्भर करता है
• जब कोड, discussion और review की गति से तेज़ी से generate होने लगता है, तब टीम को ऐसा भ्रम हो सकता है कि quality पहले ही verify हो चुकी है, जबकि वास्तव में उसने quality को जाँचा ही नहीं होता
• इससे reviewers और mentors पर मनोवैज्ञानिक बोझ बढ़ता है, और पूरी टीम की गति एक नए तरीके से धीमी पड़ सकती है

LLM शक्तिशाली है, लेकिन मूल समस्या हल नहीं करता

• तेज़ prototyping, scaffold, और automation में LLM बहुत मूल्यवान है, लेकिन यह स्पष्ट सोच, सावधानीपूर्ण review, और गहरी design की ज़रूरत को समाप्त नहीं करता
• कोड लिखने की लागत घटी है, लेकिन टीम द्वारा कोड को साथ मिलकर समझने और उसे अर्थ देने की लागत नहीं बदली है
• असली bottleneck अब भी "समझ और collaboration" में ही है

[sixthtokyo]

मैं भी ठीक वैसा ही डेवलपर हूँ जैसा इस लेख में बताया गया है—मेरे पास उन तकनीकों की कमी है और मैं LLM पर बहुत ज़्यादा निर्भर हूँ।
तकनीकी ज्ञान कम होने की वजह से AI के बिना WBS के मुताबिक काम करना मुश्किल हो जाता है..
फिर भी, सीनियर डेवलपर्स के review समय को कम करने के लिए मैं क्या करूँ तो अच्छा रहेगा..?
साथ में मेरा अपना ज्ञान भी बढ़ जाए तो अच्छा होगा..

[cosine20]

रिव्यू समय को कम करना है तो आपको खुद तय करना होगा और समझा पाना होगा कि आपने जो कोड लिखा, वह किस पृष्ठभूमि से निकला और कई implementation तरीकों में से आपने वही क्यों चुना। इसके लिए 3. को आपको वीकेंड या बचे हुए समय में लगातार करना चाहिए, और मशहूर libraries या GitHub पर दूसरे लोगों द्वारा अपलोड किए गए कोड को रैंडम तरीके से देखते हुए code structure और implementation style जैसी चीज़ों का विश्लेषण करना फायदेमंद होगा।

[sixthtokyo]

आपके अच्छे शब्दों के लिए धन्यवाद!!

[cosine20]

1. Claude Code, Devin जैसी अपने-आप चलने वाली services की बजाय Claude जैसे chat-based client + Windsurf Tab जैसे autocomplete extension तक ही इस्तेमाल करना
2. चैट में पूछने वाली चीज़ों को development direction, libraries के बीच तुलना, structure analysis, और error solving तक सीमित रखना, और code लिखना खुद जितना संभव हो उतना सीधे करना
3. Programming language, software engineering, और तरह-तरह की introductory books जैसी किताबें पढ़ने में आलस न करना

[jjw951215]

फिर भी लोगों की संख्या घटाई जा रही है, यह देखकर निराशा होती है.. 12 प्रोजेक्ट 4 लोगों से कैसे करवाएंगे.. और उनमें से एक तो मैनेजमेंट भी कर रहा है..

[laeyoung]

T_T आपकी मेहनत बहुत ज़्यादा हो रही होगी

[GN⁺]

Hacker News राय

• एक अनुभवी मेंटर के रूप में, महत्वाकांक्षी लेकिन अभी अपरिपक्व इंटर्न्स को गाइड करते हुए मैंने देखा है कि वे एक ही दिन में एक हफ्ते, बल्कि दो हफ्तों के बराबर कोड उगल देते हैं। लेकिन मेरा काम पहले से भी ज़्यादा मुश्किल हो गया है। कोड रिव्यू करते समय इंटर्न्स अपने लिखे कोड पर गहराई से सोचे बिना काम करते हैं, इसलिए मेरी फ़ीडबैक उन तक ठीक से नहीं पहुँचती। साधारण बग या छोटी-मोटी समस्याएँ लगभग गायब हो गई हैं, लेकिन जो समस्याएँ बचती हैं वे कहीं ज़्यादा सूक्ष्म और जटिल होती हैं, और उन्हें समझाना भी बहुत कठिन हो गया है। ऊपर से, ऐसे नए तरह के बग सामने आ रहे हैं जो पहले कभी नहीं देखे। ऊपर-ऊपर से ठीक दिखने वाला कोड असल में बिल्कुल काम नहीं करता, और कई बार जो चीज़ काफी पूरी हुई लगती है वह बुनियादी स्तर पर ही टूटी हुई होती है। LLM के साथ काम करने वाले जूनियर्स साधारण लेकिन चर्चा के लायक कोड देने के बजाय, ऐसे जटिल कोड को एक ही बार में लगभग तैयार चीज़ की तरह बना देते हैं जो कई स्तरों पर collaboration और maintenance में समस्या पैदा करता है। नतीजतन, एक PR को अंतिम गुणवत्ता तक पहुँचाने वाली पारंपरिक “क्रमिक सुधार” वाली प्रक्रिया मानो ठीक से काम ही नहीं कर रही। फ़ीडबैक देने पर वे मूल PR को सुधारने के बजाय कभी-कभी पूरी तरह नया approach ले आते हैं—और अक्सर उससे कोई नई समस्या भी पैदा हो जाती है। इसलिए एक ही PR पर सीनियर्स को जूनियर्स से कहीं ज़्यादा समय लगाना पड़ता है। जूनियर पक्ष को लग सकता है कि वे बहुत productive हैं, लेकिन धीरे-धीरे सीनियर reviewers की फ़ीडबैक का स्वर पहले जैसा गर्मजोशी भरा या प्रोत्साहित करने वाला नहीं रह जाता। आखिरकार बहुत सारे test cases को अनिवार्य बनाना ही कुछ हद तक असरदार रहा, लेकिन ये tests भी इसी तरह की समस्याओं के कारण अपनी सीमा से टकरा रहे हैं

  • इस तरह के 'पूरा दिखने वाले लेकिन बिल्कुल काम न करने वाले' कोड को देखकर मुझे 2.5 लाख डॉलर के एक विदेशी software development project की याद आ गई। specification को देखें तो सब कुछ सही लगता था, लेकिन वास्तव में वह बिल्कुल असंगत system था। specification की व्याख्या पर इतना अटका गया कि सामान्य समझ ही गायब हो गई, और अंत में पूरा project तुरंत फेंकना पड़ा था। अब यह देखना दिलचस्प है कि LLM की वजह से ऐसी चीज़ें automate होकर लगभग मुफ्त हो रही हैं

  • मैं इस समस्या से पूरी तरह सहमत हूँ। मेरे निजी अनुभव में भी LLM से हज़ारों lines का code बहुत तेज़ी से बन जाता है, लेकिन असली मुश्किल code review, bug fixing, security vulnerabilities की जाँच, refactoring, और बेकार code हटाने में होती है। आखिरकार, बहुत बार खुद coding करना ज़्यादा productive साबित हुआ। LLM का सबसे व्यावहारिक उपयोग auto-complete या छोटे code snippets बनाने तक सीमित है। अगर कोई जूनियर LLM को बीच में लगाकर मुझे कुछ पहुँचाए और फिर मुझे ही उसे समझना पड़े, तो efficiency और गिरती है। जो लोग आज LLM से खुद को ज़्यादा productive महसूस कर रहे हैं, हो सकता है वे वास्तव में इन अहम कामों को छोड़ ही रहे हों या उन पर ध्यान ही न दे रहे हों। असल में product quality की परवाह करने वाले कुछ ही लोगों पर भारी code volume सँभालने का बोझ आ जाता है। उन्हें अक्सर बेवजह बहुत picky समझ लिया जाता है, जबकि सच में वही लोग users तक सबसे अच्छा product पहुँचाने की कोशिश कर रहे होते हैं। सुधार का कोई साफ़ रास्ता नहीं दिखता; बल्कि हालात और बिगड़ते लगते हैं। सिर्फ LLM के सहारे प्रशिक्षित developers लगातार industry में आ रहे हैं, और tools बनाने वाली कंपनियाँ बढ़ा-चढ़ाकर marketing करती रहती हैं। अंत में quality बनाए रखने का बोझ ही बढ़ता जाता है

  • PR पर सीनियर्स को जूनियर्स से ज़्यादा मेहनत करनी पड़ती है—इस 'effort inversion' को मैं भी झेल रहा हूँ। मेरे मामले में PR writers blog posts या press releases लिखने के लिए AI का उपयोग करते हैं, और जब subject-matter expert होने के नाते मुझे output मिलता है, तो तरह-तरह की AI hallucinations और गलतियाँ ठीक करने में मेरा काम 3-4 गुना बढ़ जाता है। उनका काम मूल रूप से मुझे support करना था, लेकिन अब हालत यह है कि मुझे उनकी मदद करनी पड़ रही है। ऊपर से AI hallucinations हर बार अलग होती हैं, इसलिए हर बार नई मशक्कत करनी पड़ती है। मैंने यह बात executives तक भी पहुँचा दी है, और अगर यही चलता रहा तो लगता है अगले साल PR staff का आधा हिस्सा गायब हो जाएगा। अगर उनका काम सिर्फ email को copy करके ChatGPT में paste करना और फिर मुझे वापस भेजना है, तो वह मैं खुद कर सकता हूँ

  • "रिव्यू के दौरान मेरी दी हुई फ़ीडबैक ठीक से समझी नहीं गई"—क्या इस हिस्से पर थोड़ा विस्तार से बता सकते हैं? मैं भी ऐसी ही समस्या से जूझ रहा हूँ, इसलिए अगर कोई समाधान या insight हो तो साझा करें

  • मेरी ओर से जोड़ूँ तो, पिछली पीढ़ियाँ refactoring और unit tests के माध्यम से software structure और design की गहरी समझ स्वाभाविक रूप से बनाती थीं। लेकिन अगर आगे LLM unit tests भी बनाने लगे, तो developers के पास "मुझे वास्तव में क्या चाहिए?", "इसे और सरल कैसे बनाया जाए?" जैसे self-reflection और सीखने के मौके कम हो सकते हैं। मेरे हिसाब से 'developer', 'engineer', और 'architect' के बीच का फ़र्क यहीं से पैदा होता है। LLM या 'vibe coding' ऐसा mindset कभी नहीं बना सकते। Go जैसी कम syntax-burden वाली language में ऐसे design mistakes review में और जल्दी उजागर होते हैं। Go की unit test structure code complexity को diagnose करने में उपयोगी है। आखिरकार हमें बेहतर testing/review तरीकों की ज़रूरत है। सिर्फ fuzz testing, unit tests, और integration tests पर्याप्त नहीं हैं। मुझे लगता है कि ऐसे automated testing framework की ज़रूरत है जो तार्किक रूप से यह verify कर सके कि code की branches सही तरह invoke हो रही हैं या नहीं, और आवश्यक conditions वास्तव में संतुष्ट हो रही हैं या नहीं

• LLM की वजह से नया software अपनाने की लागत लगभग शून्य के करीब आ रही है, लेकिन उस code को गहराई से समझने, test करने और भरोसा करने की लागत पहले से कहीं ज़्यादा लगती है। फिर भी मेरे अनुभव में LLM द्वारा बनाया गया code, उन ढेरों legacy codebases से बहुत बदतर नहीं है जिन्हें किसी जा चुके व्यक्ति ने छोड़ दिया हो और जिनके बारे में ठीक से पूछ भी न सकें, या उस code से जो इंटरनेट पर इधर-उधर पड़ा रहता है। बल्कि LLM test code लिखते समय इंसानों की तरह आलसी नहीं होते, न थककर चीज़ों को यूँ ही छोड़ते हैं। मेरा दर्शन यह है कि ‘हर code संभावित technical debt है’। इसलिए मैं code की विश्वसनीयता को लेकर बहुत चिंतित नहीं रहता। वास्तव में मैंने AI के सहारे बड़े codebase बनाए और उन्हें ठीक-ठाक चलाया भी है—लेकिन यह तभी संभव हुआ जब domain verifiable था और testing व iteration बहुत थे। निष्कर्ष यह है कि LLM outputs की वजह से code production तेज़ हुआ है, लेकिन coding का बौद्धिक रोमांच कम हो गया है, और ऐसा लगता है कि मेरा दिमाग भी साथ में सुस्त हो रहा है। बल्कि अब requirements definition, design जैसी शुरुआती दिमागी मेहनत पहले से कहीं अधिक महत्वपूर्ण हो गई है

• LLM के बिना भी industry पहले से "code की कमी" से नहीं, बल्कि market demand और capital limits के कारण development speed की सीमा से जूझ रही थी। tooling इतनी बेहतर हो चुकी थी कि coding खुद मुख्य चीज़ नहीं रह गई थी। शुरुआती दौर से यह माहौल पूरी तरह बदल चुका है। Bill Gates के किशोर दिनों का एक किस्सा याद आता है, जब सिर्फ ‘coding कर पाने की क्षमता’ ही एक दुर्लभ resource हुआ करती थी। कंपनी इतनी desperate थी कि उसने 16 साल के Gates और Paul Allen को hire कर लिया, और सिर्फ इसलिए चकित थी कि वे तेज़ी से code लिख सकते थे। आज सवाल यह ज़्यादा महत्वपूर्ण है: "क्या बनाया जाए, और क्या उसमें business टिकेगा?"
  संबंधित वीडियो

  • मैं इस दावे से सहमत हूँ कि coding bottleneck नहीं थी; असली वजह market demand थी। AI boom से पहले Marc Andreessen ने भी कहा था, "capital बहुत है लेकिन निवेश लायक अच्छे ideas कम हैं।" मुझे नहीं लगता कि वह बात वास्तविकता को पूरी तरह दर्शाती है, लेकिन कम से कम data के लिहाज़ से उनका कथन विश्वसनीय लगता है

  • Bill Gates के पुराने किस्से की तरह, आज भी उच्च-गुणवत्ता वाला code लिखने और उसे गहराई से समझने की क्षमता दुर्लभ resource है। फर्क बस इतना है कि अब industry के माहौल में उस क्षमता को उतनी अहमियत नहीं दी जाती

  • AI impact analysis के नज़रिए से देखें तो हम efficiency पर कुछ ज़्यादा ही भरोसा कर लेते हैं। लेकिन वास्तविक अर्थव्यवस्था में bottlenecks कहीं अधिक जटिल संरचनाओं में पैदा होते हैं। code production 100 गुना बढ़ भी जाए, तो भी यह स्पष्ट नहीं कि उससे वास्तव में उपयोगी चीज़ें बनेंगी

• आजकल लोगों के अनुभव पढ़कर सब कुछ बहुत निराशाजनक लगता है। अगर कोई जूनियर बिना कुछ चलाकर देखे, बिना खुद test/verify किए, बिना concise बनाने की कोशिश किए, दस्तावेज़, comments या explanation के बिना एक विशाल code dump थमा दे, तो वह अपने-आप में "इंसान में फिट किया गया LLM" जैसा ही है। आखिरकार महत्वपूर्ण चीज़ है critical thinking और परिणाम के प्रति जिम्मेदारी। बल्कि मुझे तो लगता है कि feedback के प्रति LLM, पारंपरिक जूनियर software engineers से ज़्यादा ईमानदारी से प्रतिक्रिया दे सकता है

  • बहुत से लोग जूनियर द्वारा LLM से लिखा code सीनियर से review करवाने की समस्या को LLM की कमी मानते हैं, लेकिन मुझे यह ज़्यादा जूनियर की अपनी कमजोरी को उजागर करने वाली बात लगती है। बल्कि बेहतर यही होगा कि सीनियर खुद LLM का उपयोग करे

• मैं भी कभी सोचता था कि code लिखना ही bottleneck है, लेकिन 10 साल में समझ आया कि असली कठिनाई technology को business के साथ align करने में है। चाहे माहौल B2B या SaaS जैसा हो, जहाँ हर customer के कारण codebase जटिल होता जाए, अगर technology business के साथ सही बैठती है तो सब कुछ सुचारु चलता है। आज technology काफी आगे बढ़ चुकी है, इसलिए अब असली सवाल developer के ‘ego’ और customer value पर केंद्रित रहने की क्षमता का है। यह सोचना पड़ता है कि customer वास्तव में क्या चाहता है, क्या वह उसके लिए पैसे देगा, और क्या उसे web interface की भी ज़रूरत है। developer की self-satisfaction के लिए बनाए गए “cat-toy features” ही cloud costs बढ़ाने का असली कारण हैं। और इससे भी दुखद बात यह है कि aggressive incentives, stock options, या ऊँची salary फेंक देने से भी यह मूल समस्या हल नहीं होती। कोई न कोई ऐसा व्यक्ति चाहिए—कम से कम एक—जिसमें software को सही ढंग से बनाने का sense of mission हो, जो सीधे customers से बात करे और चीज़ों को सही तरह करना चाहे

• किसी संगठन में LLM ने सच में मेरी सबसे ज़्यादा मदद personal projects या side projects में की है। छोटे-छोटे problems हल करने के लिए app बनाते समय, समय की कमी के कारण code लिखना वास्तव में बड़ा bottleneck बन जाता है। ऐसे projects में LLM का उपयोग 100% है

  • मैं भी पूरी तरह सहमत हूँ। अगर रोज़ 1-2 घंटे Claude code को दिए जाएँ, तो weekend खत्म होने तक एक इस्तेमाल लायक परिणाम तैयार हो जाता है। कम समय में ideas validate करना या experiments करना आसान हो जाता है। मुझे लगता है कि ऐसे LLM tools professional organizations में भी बहुत value दे सकते हैं। जो तरह-तरह के admin tools या automation systems समय की कमी से नहीं बन पाते थे, उन्हें तेज़ी से prototype किया जा सकता है। अगर किसी colleague को DB query या कोई simple automation चाहिए, तो Claude से पूछकर review करो और सीधे paste कर दो। engineers के अलावा दूसरे लोग भी अपने domain के repetitive tasks खुद संभाल सकें—यह मेरे project mcp-front[0] का भी उद्देश्य है
    mcp-front GitHub

  • सच कहूँ तो मेरे career के इस stage पर मैं हफ्तों तक डूबकर काम नहीं कर सकता, और लंबे अनुभव के कारण non-functional requirements व long-term perspective को हमेशा ध्यान में रखता हूँ। tests जैसी चीज़ें छोड़ भी दूँ, तब भी अंत में सोचने के लिए बहुत कुछ बचता है

• Robert C. Martin का यह कथन याद आता है: "code पढ़ने में, उसे लिखने की तुलना में 10 गुना से भी अधिक समय लगता है"
  संबंधित उद्धरण

  • दुर्भाग्य से, कई बार उनका clean code style वास्तव में context को टुकड़ों में बाँट देता है, जिससे intent समझना और कठिन हो जाता है

  • उससे भी बुरा यह है कि लिखने का समय भले घटे, लेकिन पढ़ने का समय बढ़ जाए, तो कुल काम का बोझ शायद कम ही न हो

• किसी ने Joel Spolsky की 2 अक्टूबर 2000 की पोस्ट का ज़िक्र नहीं किया, इसलिए उसे यहाँ साझा कर रहा हूँ
  Joel on Software: Painless Functional Specifications (2000)
  असली bottleneck code नहीं, बल्कि functional specification है। software को कैसे काम करना चाहिए, यह अंग्रेज़ी, diagrams, user stories आदि में स्पष्ट रूप से लिखना ज़्यादा महत्वपूर्ण है। अगर specification अच्छी तरह तैयार हो, तो LLM एक साथ अच्छा solution, tests, और integration tests भी बना सकता है। अगर चीज़ बहुत बड़ी हो, तो specification को एक markdown file में बंद करके नहीं रखना चाहिए; उसे wiki की तरह features के हिसाब से तोड़कर links और references से manage करना चाहिए। असली प्रतिस्पर्धात्मक बढ़त implementation की कठिनाई में नहीं, बल्कि specification पर लगाए गए श्रम में है

• लेखक की राय से मैं सहमत नहीं हूँ। बड़ी कंपनियों के नज़रिए से code bottleneck न हो, लेकिन startups के लिए limited resources के बीच efficient planning अधिक महत्वपूर्ण रही है। यानी कई मामलों में वास्तव में सही ढंग से काम करने वाला code बनाना ही सबसे बड़ा bottleneck था। इसलिए ऐसी चर्चाओं में "AI/LLM कितना उपयोगी है" इसे सामान्यीकृत नहीं किया जा सकता। कुछ teams के लिए code bottleneck था, कुछ के लिए नहीं

  • मैंने भी ज़मीन पर यही देखा है। LLM, बेहद सक्षम छोटे development teams को ज़बरदस्त leverage देता है। अच्छे लोग हों तभी LLM भी अच्छा output देता है, जबकि बड़े teams में collaboration cost इतनी बढ़ जाती है कि LLM का लाभ सीमित हो जाता है। जो छोटी teams पहले से अच्छा कर रही थीं, वही सबसे ज़्यादा 'supercharge' होती दिखती हैं

• जैसा कि सभी जानते हैं, LLM द्वारा बनाया गया code अक्सर बेहद खराब होता है और कई बार review करना भी मुश्किल हो जाता है। जब कोई जूनियर अजीब LLM code submit करता है और उससे पूछा जाता है कि ऐसा क्यों है, तो वह खुद भी नहीं जानता और बस कह देता है कि LLM ने बनाया। आखिरकार यह रुझान code maintenance में सिर्फ ‘noise’ और ‘overhead’ बढ़ाता है। अगर LLM अपनाने से बचा नहीं जा सकता, तो शायद review और maintenance भी LLM को ही सौंपना पड़ेगा। नतीजा, जाहिर है, और भी उलझी हुई spaghetti बनेगी। लेकिन व्यावहारिक रूप से ज़्यादातर businesses में quality उतनी महत्वपूर्ण नहीं होती; अगर LLM code लगभग ठीक-ठाक चल जाए, तो वही काफी मान लिया जाता है। या फिर ज़रूरत भर LLM को ऊपर-ऊपर जोड़ते रहो, और अगर अंततः किसी तरह समस्या हल हो जाए, तो उतना ही पर्याप्त समझा जाता है