LLM कोड जनरेशन भरोसे को कमजोर कर सकती है

• हाल के समय में LLM-आधारित कोड जनरेशन का उपयोग डेवलपर्स के बीच लगातार बढ़ रहा है
• ऑटो-जनरेटेड कोड के कारण कोड क्वालिटी और विश्वसनीयता को लेकर चिंताएँ बढ़ रही हैं
• डेवलपर्स, कोड की समझ की कमी और अपर्याप्त वेरिफिकेशन के कारण प्रोजेक्ट मेंटेनेंस की कठिनाई बढ़ने का अनुभव कर रहे हैं
• अविश्वसनीय कोड के उपयोग का विस्तार पूरे सॉफ्टवेयर इकोसिस्टम को प्रभावित कर रहा है
• तकनीकी प्रगति के साथ विश्वसनीयता सुनिश्चित करने के उपाय तैयार करने की आवश्यकता पर ज़ोर दिया जा रहा है

---

अवलोकन

Jay ने अपने ब्लॉग में हाल ही में उभरी LLM (Large Language Model)-आधारित कोड जनरेशन तकनीक का सॉफ्टवेयर डेवलपमेंट के वास्तविक कार्यक्षेत्र पर पड़ने वाले प्रभाव का विश्लेषण किया है। इन टूल्स के विकास से डेवलपमेंट एफिशिएंसी बेहतर हुई है, लेकिन साथ ही कोड की विश्वसनीयता और क्वालिटी से जुड़े सवाल भी सामने आए हैं।

LLM कोड जनरेशन तकनीक का उभार

• डेवलपमेंट वातावरण में LLM का उपयोग करने वाले ऑटोमेटेड कोड जनरेशन टूल्स तेज़ी से फैल रहे हैं
• जटिल फीचर इम्प्लीमेंटेशन या दोहराए जाने वाले कोडिंग कार्यों में ये उच्च उत्पादकता प्रदान करते हैं
• तेज़ प्रोटोटाइपिंग और नई भाषाएँ सीखने के बोझ को कम करने जैसे फायदे मौजूद हैं

विश्वसनीयता की समस्या

• LLM द्वारा जनरेट किया गया कोड हमेशा इच्छित तरीके से काम नहीं करता
• कोड के भीतर की मंशा और डिज़ाइन लॉजिक अस्पष्ट होने से समझने और वेरिफाई करने की प्रक्रिया कठिन हो जाती है
• यदि रिव्यू और टेस्टिंग पर्याप्त न हो, तो अनपेक्षित बग या कमजोरियाँ पैदा होने की संभावना रहती है

प्रोजेक्ट मेंटेनेंस और इकोसिस्टम पर प्रभाव

• ऑटो-जनरेटेड कोड में डॉक्यूमेंटेशन की कमी और अपर्याप्त व्याख्या जैसी समस्याएँ सामने आती हैं
• डेवलपर्स को कोड के काम करने के सिद्धांत को समझने में कठिनाई होती है, जिससे मेंटेनेंस की जटिलता बढ़ती है
• विश्वसनीय सॉफ्टवेयर डेवलपमेंट की संस्कृति कमज़ोर पड़ने का जोखिम झेल सकती है

निष्कर्ष और सुझाव

• LLM-आधारित कोड जनरेशन तकनीक नवोन्मेषी है, लेकिन विश्वसनीयता सुनिश्चित करना एक अनिवार्य चुनौती है
• ऑटो-जनरेटेड कोड अपनाते समय मजबूत वेरिफिकेशन और व्यवस्थित कोड रिव्यू की आवश्यकता पर ज़ोर दिया गया है
• दीर्घकाल में कंप्यूटिंग इकोसिस्टम में भरोसे की रक्षा के लिए मानक तैयार करना महत्वपूर्ण है

[GN⁺]

Hacker News राय

• archive.is लिंक साझा किया गया, यह पुराने ब्राउज़र में भी काम करता है और JavaScript सिर्फ CloudSnare बाइपास के लिए चाहिए

• मेरा एक दोस्त हमेशा कहता है, "innovation trust की speed से होता है"। GPT3 आने के बाद से यह बात मेरे दिमाग में लगातार घूम रही है। verification की cost बहुत ज़्यादा होती है, और trust उसी cost को कम करने का मुख्य तरीका है। लेकिन LLM में trust कैसे बनाया जाए, यह समझ नहीं आता। यह बहुत fluently code भी लिखता है और natural language भी संभालता है, लेकिन साथ ही ऐसे भटक भी जाता है जिसे इंसान करे तो malicious माना जाए

  • मैं ही लेखक हूँ: यह quote मुझे बहुत पसंद आया। मैंने कई paragraphs में जो समझाया, उसे इसने बहुत संक्षेप में कह दिया। सच कहूँ तो अगर अब हर चीज़ को एक-एक करके verify करना पड़े, तो वह दुनिया बेहद थकाऊ और धीमी हो जाती है
  • LLM के output पर पूरी तरह trust नहीं किया जा सकता। लेकिन refinement और blast radius limitation संभव है। user input को filter करना, penetration test करना, secrets को dot files में छिपाना — आखिरकार बात "best practices" और "SOC-AI regulatory compliance" जैसे standards पर जाकर टिकेगी। LLM इतना उपयोगी है कि चाहकर भी नज़रअंदाज़ नहीं किया जा सकता। trust भी वैसे ही एक-एक step में बनता है। इंसान भी वैसे reliability में बहुत आगे नहीं हैं, और autonomous cars से तुलना करें तो लगता है कि तय नियमों के अंदर यह इंसानों से कम buggy code बना सकेगा। उसके बाद complexity को धीरे-धीरे बेहतर किया जाएगा
  • "innovation trust की speed से होता है" — इस बात को थोड़ा और समझाने की ज़रूरत है। जब पहली बार बिजली, उड़ान, radioactivity खोजी गई थी, तब क्या उतना trust मौजूद था? science में trust आगे बढ़ते हुए बनता है

• मैंने कंपनी में इस विषय को एक अनपेक्षित तरीके से महसूस किया। मुझ पर और एक सहकर्मी पर जल्दी result देने का दबाव था, और मेरे बड़े refactoring को, जबकि वह अभी अस्थायी PR की हालत में था, merge कर दिया गया। बाद में untested code में bug निकला। debugging के दौरान सहकर्मी ने बताया कि उसे लगा था मैं AI से coding कर रहा था, और वह AI-जनित code को बाद में समझने की कोशिश करके frustrate हो रहा था। लेकिन वह code मैंने खुद बहुत सावधानी से लिखा था, और bug की वजह API change के दौरान हुई छोटी मानवीय गलतियाँ थीं। उल्टा, इस अनुभव ने मुझे और मेरे सहकर्मी को trust से जुड़ा तनाव स्वाभाविक रूप से सामने लाने और उस पर रचनात्मक बातचीत करने का मौका दिया। अब पीछे मुड़कर देखता हूँ तो ऐसा trust-building अनुभव मायने रखता था, और अगर माहौल अलग होता तो बात कहीं ज़्यादा उलझ सकती थी। हमेशा सावधान रहने की ज़रूरत महसूस होती है

• मुझे यह premise ठीक से समझ नहीं आता। किसी के अच्छा code लिखने पर trust इस वास्तविक अनुभव से आता है कि उसने खुद code किया और result अच्छा निकला। LLM इस्तेमाल करने पर भी अगर वह bug-free code देता है तो trust होगा, और अगर bug वाला code देता है तो trust नहीं होगा। दिमाग से खुद लिखने और इसमें फर्क क्या है, समझ नहीं आता

  • मैं ही लेखक हूँ: मेरा point यह है कि medium-trust वाली बड़ी teams या open source जैसे low-trust माहौल में, LLM की वजह से सिर्फ submitted code देखकर developer की skill पहचानना लगातार कठिन होता जाएगा। सामने वाले की tendencies पता नहीं चलतीं, इसलिए आखिरकार "zero trust" की तरह हर code को बारीकी से देखना पड़ेगा। जो shortcuts अब तक fast review में काम आते थे, वे अब नहीं चलेंगे, और ऐसी culture की आदी organizations के लिए यह काफी painful हो सकता है। अगर टीम में पहले से high trust है, तो शायद यह समस्या बिल्कुल relatable न लगे
  • पहले अगर A=B था, तो B के अच्छा होने का मतलब A भी अच्छा है। अब A+AI=B हो गया है, इसलिए B अच्छा होने पर भी A अच्छा हो, यह ज़रूरी नहीं। और अभी AI की हालत probabilistic है, इसलिए कई बार यह कुछ न करने से भी बदतर हो जाता है
  • आपने कहा "जो code काम करे, उसी पर trust" — लेकिन trust की बुनियाद यह है कि developer पहले से जानता हो कि code सच में bug-free है। पर complex systems में code दूसरे हिस्सों से कैसे interact करेगा और edge cases कैसे आएँगे, यह समझने के लिए code लिखने वाले को पूरा context समझना पड़ता है। अगर LLM ने code लिखा और developer खुद उसे पूरी तरह नहीं समझता, तो verification का बोझ reviewer पर चला जाता है और overload पैदा होता है। point यही है
  • LLM से coding करते हुए कुछ बार अच्छे result मिलते हैं, फिर overconfidence आ जाता है और testing ढीली पड़ जाती है। असल में communication errors से बहुत दिक्कत होती है। worker पूरा task समझता है, लेकिन LLM के लिए state बनाए रखना मुश्किल होता है, और context ambiguous हो तो यह बेहूदा assumptions बना लेता है। काश 4o की तरह पहले लगातार extra information माँगने वाला approach सभी code generation models में standard बन जाए, इससे सच में बहुत सी समस्याएँ रुक सकती हैं
  • trust सिर्फ काम करने वाले code से नहीं बनता। changes को साफ़-साफ़ explain करना, पहले अच्छे contributions का इतिहास, changes का सही granularity में होना, problems की priority सही तय करना, existing code को maintain करने की क्षमता, लगातार सक्रिय रहना — इन सब बातों से भी trust बनता है

• हम पहले ही ऐसे दौर में हैं। "यह point miss करने के लिए sorry, आप सही कह रहे थे" — यह लाइन बहुत ज़्यादा दिखती है। 10 में 8~9 बार देखी है। दूसरी तरफ़, लोग LLM से बना code बिना समझे copy-paste कर देते हैं और उम्मीद पूरी न होने पर गुस्सा करते हैं। सच कहूँ तो वह ज़्यादा बेहतर है। जो चीज़ साफ़ तौर पर टूटी हुई हो, वह ऊपर-ऊपर ठीक दिखने वाली चीज़ से बेहतर है

  • मेरे अनुभव में, LLM अक्सर requirements पूरी करने के बजाय code को बस इतना बदलता है कि tests pass हो जाएँ
  • क्या आप browser chatbot से LLM इस्तेमाल कर रहे हैं? हम तो ऐसे AI agent इस्तेमाल करते हैं जिन्हें code तक सीधा access है, वे बहुत कम बोलते हैं और कई बार आसपास के junior developers से बेहतर काम भी कर देते हैं। छोटे, specific tasks अच्छे से कर लेते हैं, इसलिए बस code review करके लगभग तुरंत इस्तेमाल कर लेते हैं। हाँ, prediction engine सच में engineering नहीं जानता। उदाहरण के लिए, अगर Python generator साफ़-साफ़ न माँगो तो यह अक्सर बहुत memory खाने वाला code दे देता है। लेकिन आसपास के Python developers भी वैसी गलतियाँ बहुत करते हैं। बल्कि इसी वजह से यह "add feature" कहने के बजाय clear spec लिखवाने में मदद करता है। AI agent सबसे ज़्यादा वहाँ काम आता है जहाँ legacy code है और कोई ध्यान नहीं देता। हमारे पास एक system है जो पहले fax से आए documents से 200 coordinates के आधार पर data निकालता था, 30 साल से वैसा ही चल रहा था, हाल में document बदल गया। copilot ने coordinates बदलने में 30 सेकंड लिए। इंसान को इसमें कम से कम एक दिन लगता। लेकिन ऐसी coding दुनिया में expert कैसे बना जाए, समझ नहीं आता
  • 10 में 8~9 बार कहना बहुत बढ़ा-चढ़ाकर कहा गया है। यह 100% गढ़ा हुआ आँकड़ा है

• पहले के abstraction tools complexity कम करते थे और साथ ही उस abstraction की "correctness" को default premise मानते थे। हाँ, वे perfect नहीं थे, bugs भी थे, लेकिन समस्या implementation में होती थी, कोई intrinsic error नहीं। एक बार patch हो जाए तो वह और मजबूत हो जाता था। दूसरी तरफ़, LLM probabilistic prediction engine है, जो कुछ समय तक सिर्फ approximate correctness देता है। यहाँ लेखक एक बात छोड़ रहा है: imperfect probabilistic agents से भी trustworthy deterministic systems बनाए जा सकते हैं। उदाहरण के लिए, हम garbage collection tool के author पर trust करके नहीं, बल्कि इस बात पर trust करते हैं कि tool खुद पर्याप्त रूप से test किया गया है और साबित करता है कि वह चाहा गया काम करता है। भविष्य में शायद test-driven development और मज़बूत होगा। trust नहीं, verification

  • यह मान लेना naïve है कि automated tests हर समस्या पकड़ लेंगे। concurrency, resource management, security vulnerabilities जैसी बहुत सी चीज़ें automate करना कठिन है। और tests को कौन verify करेगा? code और test दोनों अलग-अलग logic implement करते हैं, और कई बार bug की जड़ code नहीं बल्कि test में निकलती है। tests पर भी blindly trust नहीं किया जा सकता
  • मैं ही लेखक हूँ: यहाँ मेरा focus tool के effect पर नहीं, tool पर ही है। मान लीजिए model खुद garbage collector का काम करे — program का memory dump ले और तय करे कि कौन-से blocks बेकार हैं और उन्हें free करे — तो मैं उसके judgment पर कभी स्थायी trust नहीं कर पाऊँगा। चाहे उसे कितना भी "patch" या "fine-tune" कर लो, उसकी सीमा रहेगी। JVM जैसे deterministic output वाले system में अगर error हो, तो patch के बाद वह error स्थायी रूप से हट जाता है। LLM में ऐसा नहीं है। मुझे लगता है यही पुरानी abstractions और LLM की दुनिया के बीच मूल विभाजन है। LLM का industry पर असर बड़ा होगा, लेकिन historical examples सीमित हैं, इसलिए यह सचमुच अनजाना इलाका है
  • "probabilistic factor (entropy machine) से trustworthy deterministic system निकल सकता है" — यह बात मुझे काफ़ी radical लगती है। और TDD को हमेशा ऐसा पेश किया जाता है मानो वह हर समस्या का universal solution हो। लेकिन गलत tests के कारण गलत software बनते मैंने शर्मिंदगी की हद तक बहुत बार देखे हैं

• LLM के ख़िलाफ़ नाराज़गी का कोई फ़ायदा नहीं। अभी LLM developers की productivity बढ़ाता है। कम से कम कम-अनुभवी developers के लिए तो और भी ज़्यादा। productivity बहुत बढ़ाने वाले tools को, लोग कुछ भी कहें, छोड़ा नहीं जाएगा। भले बड़े bugs की वजह से बड़ी services लंबे समय तक down हों, अगर productivity अहम है तो technology रुकेगी नहीं। उसका यथार्थवादी रास्ता यही है कि उसकी कमज़ोरियों को solve या mitigate करते हुए उसके साथ चला जाए। इस प्रक्रिया में अगर mitigation productivity को चोट पहुँचाएगा तो लोग उसे bypass करेंगे, और आखिर में वही complementary उपाय टिकेंगे जो technology के साथ तालमेल बिठाएँ

  • "LLM developer productivity बढ़ाता है" — यह व्यक्ति और context पर बहुत निर्भर है। मेरे अनुभव में "10x productivity" कहने वाले ज़्यादातर junior frontend developers होते हैं, या startup वाले जो बार-बार शुरुआती apps बनाते हैं। यह अच्छे use cases हैं, लेकिन ऐसे developer और embedded C के senior developer बिल्कुल अलग भाषा में बात करते हैं। इसलिए AI productivity की बहस अक्सर अलग contexts की बातचीत होती है। और "rational use" की दृष्टि से भी, AI agent की अवधारणा ही सही है या नहीं, यह सवाल है। Copilot incident को देखें तो MS और AI दोनों मज़ाक का विषय बने। AI को autonomy देकर काम सौंपना हमेशा समझदारी नहीं हो सकता। इसी तरह blockchain में भी crypto boom के दौर में बेहिसाब बढ़ा-चढ़ाकर किए गए दावे थे, लेकिन Coinbase जैसी कुछ चीज़ें सच में किसी meaningful niche में टिक गईं। 2020 में IBM यह दावा कर रहा था कि वह coffee beans supply chain को blockchain से manage कर रहा है — आज 2025 में देखें तो Twitter joke जैसा लगता है, लेकिन तब वह गंभीर दावा था। इसलिए आज के AI agents, और generative AI के दूसरे applications भी, बाद में hype के उदाहरण बन सकते हैं Copilot incident Forbes लेख
  • "ज़्यादा productive" यह बात बार-बार आती है, लेकिन इससे यह नहीं पता चलता कि human/AI combo अंततः user requirements को बेहतर ढंग से पूरा कर रहा है या नहीं; बस इतना कि "ज़्यादा code बन रहा है"। मैंने कभी LLM से 2000 lines code delete करने वाला PR बनने की कहानी नहीं सुनी। "engineering productivity improvement" का मतलब असल में ज़्यादा code लिखना ही माना जा रहा है
  • यह मानना गलत है कि लेखक का इरादा केवल आलोचना करना है। बात LLM को अपनाने या छोड़ने की binary choice की नहीं, बल्कि risk management और mitigation पर focus की है। जैसे यह कहना कि कारों का विकास रुकना नहीं चाहिए, लेकिन अगर उनमें explosion का risk है तो उस risk को कम करने पर ज़्यादा ध्यान देना चाहिए
  • मुझे मूल पोस्ट "बेकार की शिकायत" नहीं लगती, बल्कि LLM के साथ काम करते समय आसानी से होने वाली लापरवाहियों और team-level safeguards पर एक यथार्थवादी चिंता लगती है
  • जब React पहली बार आया था, तब उसे न सीखने का मुझे पछतावा है। GPT के प्रति अनिच्छा अभी भी है, और आसपास लोग कहते रहते हैं "chatGPT ने कहा" या "यह chatGPT code है", जबकि मुझे खुद मेहनत करके coding करने पर गर्व है। मैं GPT इस्तेमाल नहीं करता, लेकिन सच कहें तो Google या Stack Overflow को भी धीमे GPT की तरह देखा जा सकता है

• "यह वादा करो कि contribution किया गया code LLM की उपज नहीं, original है और पूरी तरह समझा गया है" या "ज़्यादातर manual work अनिवार्य है" जैसी policies से बेहतर है कि focus output पर रखा जाए। contributor से यह अपेक्षा करना ठीक है कि वह अपने changes को अच्छी तरह समझे। लेकिन "juniors कुछ समय तक LLM tools न इस्तेमाल करें या उन पर रोक हो" जैसी policies ठीक नहीं लगतीं। onboarding के दौरान होने वाली उलझी हुई environment setup की समस्याओं में LLM बहुत मदद करता है। साथ ही code और documentation समझने में भी, और एक उपयोगी text search तथा summarization tool की तरह भी

  • onboarding दरअसल random environment problems को solve करना सीखने की प्रक्रिया भी है। अगर automation से हर कठिनाई और complexity हटा दी जाए, तो बाद में कोई नहीं समझ पाएगा कि ऐसी स्थिति में क्या करना है। क्या सिर्फ मुझे ही ऐसा लगता है?

• "AI Cliff" — यानी LLM accuracy का अचानक गिर जाना — यह विचार मैंने पहली बार सुना। क्या दूसरों ने भी ऐसा अनुभव किया है?

  • मैं तो यह अक्सर अनुभव करता हूँ। जब code complexity एक threshold पार कर जाती है, तो LLM पूरे context को दिमाग में नहीं रख पाता और अजीब व्यवहार करने लगता है। मेरी भूमिका यह manage करना है कि LLM को कितनी complexity दिखाई जाए। आज के LLM समय के साथ structure को और complex बनाते जाते हैं। आम तौर पर मैं उससे refactor करवाकर चीज़ें सरल कराता हूँ, या अगर बहुत जटिल हो जाए तो खुद साफ़ करता हूँ। अभी के LLM को लगातार छोड़ दो तो अंत में वह एक विशाल Rube Goldberg शैली का chaos बना देता है, और उसे अंततः इंसान को साफ़ करना पड़ता है। अनुभवी developers जल्दी समझ जाते हैं कि LLM कहाँ तक उन्हें समुद्र में ले जा रहा है और समय रहते वापस आ जाते हैं, लेकिन beginner तो कई बार यह समझने से पहले ही पूरी तरह भटक जाता है कि कुछ गड़बड़ हुई है
  • इसे कुछ लोग context drunk कहते हैं। मान लो input context 10,000 tokens का है और 99% सही है, फिर LLM 1,000 tokens का जवाब देता है जो 90% ही सही है। आगे ऐसे ही आदान-प्रदान चलते रहने पर context window का अधिकांश हिस्सा LLM के कम-सटीक output की पुनरावृत्ति से भर जाता है। errors जमा होते जाते हैं, और हाल की जानकारी को ज़्यादा weight मिलने से output और बेकार होता जाता है। यह समस्या सिर्फ code में नहीं, prose में भी दिखती है
  • मैं इसे context rot कहता हूँ। context जमा होने के साथ output quality गिरती जाती है। जितनी ज़्यादा बेकार बात या off-topic सामग्री होगी, quality उतनी तेज़ी से गिरेगी। खासकर जब chain of thought (COT) context में रह जाता है, तो अगर reasoning भटकती है तो उसके निशान quality को और खराब करते हैं। व्यक्तिगत रूप से मैं चाहता हूँ कि context के कुछ हिस्से prune करने की सुविधा हो। मैं खुद summary बनाकर उसे नई session में ले जाकर context rot से निपटता हूँ
  • vibe coding जैसे chat interface में ही यह ज़्यादा देखा है; agent-type tools code context window खुद manage करते हैं और dev tooling सीधे चलाकर sanity check करते हैं, इसलिए वहाँ यह बहुत कम होता है
  • काम के AI sessions मैं अक्सर reset कर देता हूँ, इसलिए 'AI cliff' कम महसूस होता है। लेकिन जब creative fiction लिखता हूँ, वहाँ context की length और consistency अहम होती है, और AI एक बिंदु पर पात्रों के personality traits ठीक से बनाए नहीं रख पाया और अजीब प्रतिक्रिया देने लगा। उसे वापस नहीं लाया जा सका, यह बहुत अजनबी अनुभव था

• मूल लेखक कहता है कि वह कई लोगों की बातों का सार नहीं बताएगा, लेकिन व्यवहार में वही कर रहा है। फिर भी, अगर PR में AI-generated code वाले files को mark किया जाए तो अच्छा होगा। LLM code और human code की mistakes के pattern अलग होते हैं, इसलिए उन्हें अलग करके review किया जा सके तो समय बचेगा। क्या किसी ने बड़ी organizations में ऐसी policy देखी है, या इसके लिए automation tools पहले से मौजूद हैं? अगर कंपनियाँ LLM-generated code का अनुपात माप रही हैं, तो detailed metrics के लिए ऐसे tools शायद पहले से मौजूद भी हों

  • मैं ही लेखक हूँ: सच कहूँ तो teams के भीतर trust और LLM पर बहुत चर्चा नहीं देखी, इसलिए कोई formalized example नहीं मिला। यह इसलिए है कि मैं गलत circles में काम कर रहा हूँ, या इसलिए कि ऐसी बातें mainstream में दिखना मुश्किल है — यह मैं खुद भी नहीं जानता