LLM कोड जनरेशन भरोसे को कमजोर कर सकती है
(jaysthoughts.com)- हाल के समय में LLM-आधारित कोड जनरेशन का उपयोग डेवलपर्स के बीच लगातार बढ़ रहा है
- ऑटो-जनरेटेड कोड के कारण कोड क्वालिटी और विश्वसनीयता को लेकर चिंताएँ बढ़ रही हैं
- डेवलपर्स, कोड की समझ की कमी और अपर्याप्त वेरिफिकेशन के कारण प्रोजेक्ट मेंटेनेंस की कठिनाई बढ़ने का अनुभव कर रहे हैं
- अविश्वसनीय कोड के उपयोग का विस्तार पूरे सॉफ्टवेयर इकोसिस्टम को प्रभावित कर रहा है
- तकनीकी प्रगति के साथ विश्वसनीयता सुनिश्चित करने के उपाय तैयार करने की आवश्यकता पर ज़ोर दिया जा रहा है
अवलोकन
Jay ने अपने ब्लॉग में हाल ही में उभरी LLM (Large Language Model)-आधारित कोड जनरेशन तकनीक का सॉफ्टवेयर डेवलपमेंट के वास्तविक कार्यक्षेत्र पर पड़ने वाले प्रभाव का विश्लेषण किया है। इन टूल्स के विकास से डेवलपमेंट एफिशिएंसी बेहतर हुई है, लेकिन साथ ही कोड की विश्वसनीयता और क्वालिटी से जुड़े सवाल भी सामने आए हैं।
LLM कोड जनरेशन तकनीक का उभार
- डेवलपमेंट वातावरण में LLM का उपयोग करने वाले ऑटोमेटेड कोड जनरेशन टूल्स तेज़ी से फैल रहे हैं
- जटिल फीचर इम्प्लीमेंटेशन या दोहराए जाने वाले कोडिंग कार्यों में ये उच्च उत्पादकता प्रदान करते हैं
- तेज़ प्रोटोटाइपिंग और नई भाषाएँ सीखने के बोझ को कम करने जैसे फायदे मौजूद हैं
विश्वसनीयता की समस्या
- LLM द्वारा जनरेट किया गया कोड हमेशा इच्छित तरीके से काम नहीं करता
- कोड के भीतर की मंशा और डिज़ाइन लॉजिक अस्पष्ट होने से समझने और वेरिफाई करने की प्रक्रिया कठिन हो जाती है
- यदि रिव्यू और टेस्टिंग पर्याप्त न हो, तो अनपेक्षित बग या कमजोरियाँ पैदा होने की संभावना रहती है
प्रोजेक्ट मेंटेनेंस और इकोसिस्टम पर प्रभाव
- ऑटो-जनरेटेड कोड में डॉक्यूमेंटेशन की कमी और अपर्याप्त व्याख्या जैसी समस्याएँ सामने आती हैं
- डेवलपर्स को कोड के काम करने के सिद्धांत को समझने में कठिनाई होती है, जिससे मेंटेनेंस की जटिलता बढ़ती है
- विश्वसनीय सॉफ्टवेयर डेवलपमेंट की संस्कृति कमज़ोर पड़ने का जोखिम झेल सकती है
निष्कर्ष और सुझाव
- LLM-आधारित कोड जनरेशन तकनीक नवोन्मेषी है, लेकिन विश्वसनीयता सुनिश्चित करना एक अनिवार्य चुनौती है
- ऑटो-जनरेटेड कोड अपनाते समय मजबूत वेरिफिकेशन और व्यवस्थित कोड रिव्यू की आवश्यकता पर ज़ोर दिया गया है
- दीर्घकाल में कंप्यूटिंग इकोसिस्टम में भरोसे की रक्षा के लिए मानक तैयार करना महत्वपूर्ण है
1 टिप्पणियां
Hacker News की राय
https://archive.is/5I9sB
पुराने browsers में भी चलता है, और CloudSnare से गुजरते समय को छोड़कर JavaScript की जरूरत नहीं होती
एक दोस्त हमेशा कहता है कि “innovation trust की रफ्तार से होती है,” और GPT-3 के बाद से यह वाक्य बार-बार याद आता है
verification महंगी होती है, और उस लागत को घटाने का मुख्य साधन trust है. समझ नहीं आता कि LLM पर भरोसा कैसे कराया जा सकता है. code और natural language दोनों में यह बेहद fluent है, लेकिन साथ ही fractal की तरह अंतहीन rabbit hole में खुशी-खुशी उतर जाता है, और ऐसे व्यवहार भी दिखाता है जिन्हें इंसान के मामले में दुर्भावनापूर्ण माना जाता
यह नई दुनिया, जहां हर चीज हमेशा verify करनी पड़ती है, काफी थकाऊ है, और सच कहूं तो बहुत धीमी भी
यह इतना उपयोगी है कि इसे नजरअंदाज नहीं किया जा सकता, और trust हमेशा एक-एक ईंट रखकर ही बनता है. यह भी नहीं भूलना चाहिए कि इंसान भी शुरुआत से ही इतने भरोसेमंद नहीं होते. car driving की तरह, पहले से defined roads पर कम bugs वाला code तैयार करने की क्षमता जल्द ही इंसानों से आगे निकलती दिखती है, और उसके बाद complexity को बेहतर बनाने के लिए बस fundamentals की लड़ाई रह जाएगी
science में आगे बढ़ते हुए trust बनाया जाता है
काम पर मेरे साथ यह उम्मीद से अलग तरीके से हुआ. मेरे colleague और मुझ पर progress दिखाने का pressure था, और मैंने जिस काफी बड़े refactoring पर काम किया था, उसे जल्दी merge करने का फैसला किया. वह draft PR था, लेकिन momentum के लिए merge कर दिया, और अगले हफ्ते untested code areas में कुछ bugs निकले
debugging के दौरान colleague ने जाहिर किया कि उसने मान लिया था कि मैंने इसे AI से लिखा होगा, और कहा कि बाद में AI-generated चीज को समझने की कोशिश करना frustrate करता है. लेकिन यह code AI का इस्तेमाल किए बिना लिखा गया था. बेशक मैं code लिखने में AI इस्तेमाल करता हूं, लेकिन यह code मैंने पूरी design को ध्यान से सोचते हुए हाथ से लिखा था. bugs refactoring की बुनियादी खामी नहीं थे, बल्कि बदले हुए API के हिसाब से existing code adjust करते समय छूटी छोटी-छोटी चीजें थीं
अंततः colleague के साथ tension पर खुलकर बात हो सकी, इसलिए यह trust बनाने वाला experience बन गया. कह सकते हैं कि अभी जो हो रहा है उसकी ताकत से हम काफी नरमी से रूबरू हुए. पीछे मुड़कर देखूं तो अच्छा है कि बात ऐसे सुलझ गई, और कल्पना कर सकता हूं कि किसी दूसरे work environment में यह कहीं ज्यादा messy हो सकता था. सावधान रहना होगा
करीब 4 साल पहले मैंने खुद बहुत बड़ी बेवकूफी की थी. एक local newspaper ने किसी व्यक्ति के बारे में एक article छापा था, जिसमें एक photo को मुख्य evidence बनाकर बेतुका दावा किया गया था, और मैंने editor को सीधे email करके समझाया कि मुझे क्यों यकीन है कि image manipulated है. मेरी reasoning मेरी गलतफहमी पर आधारित थी; मैंने इस बात को गलत समझ लिया था कि वह व्यक्ति meet-and-greet में कई लोगों के साथ pose देते समय लगभग एक ही जगह और posture में था. editor आहत हुआ और उसने मजाक उड़ाते हुए जवाब दिया, और जब मैं पीछे नहीं हटा तो उसे एहसास हुआ कि मैं कोई agitator नहीं, बस मूर्ख हूं, और उसने वह unreleased full video share किया जिससे photo निकली थी. तब मैंने गहराई से माफी मांगी और donation भी किया, और उसके बाद एक साल तक मेरा अहंकार सही मात्रा में छोटा बना रहा
email भेजने से पहले भी, झूठा आरोप नहीं लगाना चाहता था, इसलिए शांत दिमाग वाले दोस्तों के साथ photo share करके राय पूछी थी, और वे भी इस निष्कर्ष पर पहुंचे कि image manipulated होने की काफी संभावना है, इसलिए मैं काफी confident था. अब मैं उस newspaper और संबंधित लोगों पर implicitly trust करता हूं, लेकिन सिर्फ एक व्यक्ति को convince करने में भी सचमुच बहुत मेहनत लगी
आधार समझना मुश्किल है। अगर आप किसी पर अच्छा कोड लिखने का भरोसा करते हैं, तो वह भरोसा आपने इसलिए सीखा है क्योंकि उस व्यक्ति का code ठीक से काम करता था, न कि इसलिए कि उसके मन में “अच्छा code पैदा करने” का कोई a priori mental model मौजूद था
अगर कोई LLM का इस्तेमाल करके bug-free code बनाता है, तो आप भरोसा करेंगे। अगर कोई LLM का इस्तेमाल करके बहुत bugs वाला code बनाता है, तो आप भरोसा नहीं करेंगे। इसमें उस समय से क्या अलग है जब वह व्यक्ति सिर्फ अपने दिमाग से code बनाता था?
LLM की वजह से सिर्फ submitted code देखकर patch भेजने वाले developer की quality का तुरंत आकलन करना बहुत मुश्किल हो जाता है। अगर आप यह अंदाजा नहीं लगा सकते कि सामने वाला किस तरह का व्यक्ति है, तो आपको “zero trust” पर लौटकर हर चीज़ को बहुत बारीकी से review करना पड़ता है। यानी अब कोई सुरक्षित “review shortcut” नहीं बचता, और जहां काम ऐसे signals पर निर्भर करके चलता था, वहां यह दर्दनाक हो सकता है। अगर team पहले से सक्षम और high-trust है, तो यह समस्या लागू नहीं होती, और शायद concept खुद ही अजनबी लगे
contributor बदलावों को अच्छी तरह explain करे तो भरोसा बढ़ता है। उसने अतीत में बेहतरीन काम किया हो तो भरोसा बढ़ता है। reasonable commits की तरह changes को अच्छे units में manage करे तो भरोसा बढ़ता है। नया feature जोड़ने से पहले bug fix करने जैसे सही problems चुने तो भरोसा बढ़ता है। मौजूदा code को maintain कर सकने की क्षमता दिखाए, सिर्फ ऊपर से जोड़ने के बजाय, तो भरोसा बढ़ता है। नियमित रूप से contribute करे तो भरोसा बढ़ता है
समस्या अक्सर communication error होती है। worker के लिए task साफ हो सकता है, लेकिन बार-बार context reset होने की वजह से यह guarantee करना मुश्किल है कि LLM भी पूरी picture जानता है; और ambiguity हो तो वह बेवकूफाना assumptions करने में जल्दी करता है। 4o का deep research कुछ करने से पहले अतिरिक्त जानकारी पूछता है—मुझे लगता है code generation में भी यह standard होना चाहिए। इससे ढेर सारी समस्याएं रोकी जा सकती हैं
कुछ cases सरल होते हैं। यह routine desired value return करती है या नहीं, बस यही सवाल होता है। लेकिन दूसरी स्थितियां कहीं ज्यादा complex होती हैं, क्योंकि अनुमान लगाना पड़ता है कि system के दूसरे हिस्सों के साथ इसका interaction कैसा होगा, और कम दिखाई देने वाले edge cases क्या हैं। ऐसी स्थिति में “bug-free” code लिखने के लिए लेखक को code के implications समझने होंगे, और अगर developer को LLM द्वारा लिखे code के exact काम करने का तरीका समझ नहीं आता, तो वह implications भी नहीं समझ सकता। तब यह burden reviewer पर चला जाता है, और reviewer का workload बढ़ता है। यही premise था
अच्छा rule of thumb यह है कि जिस काम में LLM शामिल हो उसे सीधे reject कर दें, और LLM द्वारा लिखी communication को भी ignore करें। कोई व्यक्ति English को foreign language के रूप में इस्तेमाल करता हो तब भी, मेरी नजर में ChatGPT के उसके behalf पर बोलने से उस व्यक्ति की “टूटी-फूटी” English कहीं बेहतर है। जैसे-जैसे LLM की गंभीर समस्याएं ज्यादा स्पष्ट होंगी, मुझे लगता है ऐसी policies overall standard बनेंगी, और मैं चाहता हूं कि ऐसा ही हो
LLM किसी भी तरह के खराब काम को विश्वसनीय रूप से अच्छा काम जैसा दिखा देता है। इसलिए AI इस्तेमाल करने वाले व्यक्ति के output को अपने-आप कम भरोसेमंद मानकर देखना तर्कसंगत है
बहुत पहले मेरे एक रिश्तेदार का fraudster होना सामने आया था। पकड़े जाने के बाद मैंने उससे संबंध तोड़ते हुए कहा कि मैं उसे नहीं जानता, और उसने कहा, “मैं वही व्यक्ति हूँ जिसे तुम 10 साल से जानते आए हो।” मैंने जवाब दिया, “शायद। लेकिन अब मुझे एहसास हुआ है कि मैं कभी नहीं जानता था कि तुम कौन हो, और आगे भी नहीं जान पाऊँगा”
हम सभी मानकर चलते हैं कि हमारी जिंदगी के लोग सक्रिय रूप से हमें नुकसान पहुँचाने की कोशिश नहीं कर रहे। जब वह भरोसा टूटता है, तो बहुत जोर से टूटता है। AI इस्तेमाल करने वाला कोई भी व्यक्ति “यह मेरा काम है” दावा नहीं कर सकता। क्योंकि यह जाना ही नहीं जा सकता कि वह आपका काम है या नहीं। AI इस्तेमाल करने वाला व्यक्ति इसे अच्छा काम भी नहीं कह सकता, जब तक कि वह इसे गहराई से न समझता हो, और शायद वह गहराई से समझता भी नहीं होगा। मेरे कई छात्रों ने दावा किया कि उन्होंने मेरी लिखी चीजें पढ़ीं और समझीं, लेकिन मैंने पाया कि असल में ऐसा नहीं था। अगर मैं AI होता, और वे मेरे काम को लेकर अपने नाम से लेखक के रूप में डाल देते, तो क्या होता? वे कुछ भी समझा, बचा या आगे नहीं बढ़ा पाते। ऐसी समस्या AI से पहले भी थी, लेकिन अब यह दस गुना ज्यादा खराब हो गई है
उपयोगी LLM आने से पहले मैं जटिल application programming में “10,000 घंटे से अधिक” लगा चुका था। सालों तक हर रात documentation और दूसरों के source code में डूबकर full-stack mastery में पूरी तरह लगा रहा। अंततः उस डूबने का नतीजा गंभीर burnout हुआ, स्वास्थ्य बिगड़ा और शादीशुदा जीवन भी डगमगाया। application launch करने के तुरंत बाद recovery के लिए मुझे 3 साल तक पूरी तरह सब छोड़ना पड़ा, और मुझे यकीन था कि मैं इसे फिर कभी हाथ नहीं लगा पाऊँगा
जब मैंने बहुत सुना कि LLM code में काफी अच्छे हो गए हैं, तो सावधानी से कंप्यूटर के सामने लौटा, और वहीं मेरा अनुभव इन चिंताओं से काफी अलग हो गया। “AI इस्तेमाल करने वाला व्यक्ति ‘यह मेरा काम है’ दावा नहीं कर सकता” वाली बात से मैं सहमत नहीं हो सकता। जब मैं LLM का इस्तेमाल करता हूँ, तो मैं architect और अंतिम reviewer होता हूँ। vision मैं निर्देशित करता हूँ, system design करता हूँ, और diff tools से LLM द्वारा generate की गई हर line review करता हूँ। हाल ही में मैंने LLM के साथ business के estimate engine के लिए एक जटिल optimization model बनाया। असली optimization model इस्तेमाल करना हमेशा “सही” तरीका था, लेकिन पहले होता तो library की हर detail सीखने और दूसरे लोगों का code पढ़ने में महीनों की कठिन मेहनत लगती। इस बार यह एक हफ्ते में हो गया। क्या यह मुझे अपना काम लगता है? पूरी तरह। बस मेरे पास एक ऐसा assistant था जो थकता नहीं, बहुत सक्षम है, लेकिन कभी-कभी flawed होता है
user “गहराई से समझ नहीं पाएगा” वाली बात पर भी मेरा अनुभव उल्टा है। किसी non-trivial काम में LLM को प्रभावी ढंग से इस्तेमाल करने के लिए fundamentals की और गहरी समझ चाहिए, ताकि LLM को guide किया जा सके और उसकी अक्सर होने वाली subtle गलतियाँ पकड़ी जा सकें। मेरे वर्षों के अनुभव के बिना मैं जटिल multi-module development को lead नहीं कर पाता, output debug नहीं कर पाता, या यह नहीं जान पाता कि जो काम विश्वसनीय रूप से अच्छा दिख रहा है, वह असल में N+1 समस्या जैसी किसी वजह से गलत है
शिक्षक के रूप में आपके अनुभव से मैं सहमत हूँ। छात्रों का इन tools से समझने का दिखावा करना वास्तविक और कठिन समस्या है। academia में लक्ष्य learning process है, यानी 10,000 घंटों का कोई ठोस हिस्सा हासिल करना। लेकिन professional world में लक्ष्य results हैं, और यह बेहतर results पाने का नया और शक्तिशाली tool है। इस नई reality में शिक्षक छात्रों को कैसे पढ़ाएँ, यह मुझे नहीं पता, लेकिन LLM usage को demonize करना शायद सबसे अच्छा तरीका नहीं है
मेरे लिए इसने खराब काम को अच्छा दिखाने का काम नहीं किया। इसने बेहतरीन काम को फिर से संभव बनाया, और साथ ही मुझे मेरी जिंदगी वापस दी। इसने मुझे और मेरे परिवार को तोड़े बिना software development के craft का आनंद वापस दिलाया, और अब जीवन कहीं ज्यादा balanced है, जिसके लिए मैं आभारी हूँ
मेरे लिए तो यह पहले से ही ऐसा है। “अनदेखा करने के लिए माफ कीजिए, आप बिल्कुल सही हैं” मैंने अनगिनत बार पढ़ा है। लगभग 10 में से 8–9 बार
दूसरी तरफ, मैं लगातार देखता हूँ कि लोग paid LLM-generated code को बिना सोचे-समझे copy कर देते हैं, और जब वह expected तरीके से काम नहीं करता तो भड़क उठते हैं। वैसे वह बेहतर विकल्प है। क्योंकि ऊपर-ऊपर से काम करता दिखने वाली चीज़ की तुलना में स्पष्ट रूप से टूटी हुई चीज़ फिर भी बेहतर है
फिर भी prediction engine अभी असली engineering नहीं कर सकता। जब तक आप खास तौर पर Python generator जैसी चीज़ इस्तेमाल करने को न कहें, बहुत ज्यादा memory खाने वाला code आने की संभावना बड़ी है। दुर्भाग्य से यह मेरे जानने वाले कई Python programmers से भी बहुत अलग नहीं है, लेकिन यह इस बात का example भी है कि LLM ठीक उतना ही खराब है जितना कहा गया। positive side यह है कि यह लोगों से “feature add करो” की एक line से ज्यादा detailed specification लिखवाने लगा है
हमारे लिए AI agents सबसे उपयोगी वहाँ हैं जहाँ कोई priority नहीं देता: legacy code। हमारे पास पिछले millennium में लिखा गया data extractor है, जो fax से आने वाले एक specific document type से data निकालने के लिए लगभग 200 hardcoded coordinates इस्तेमाल करता है। document करीब 30 साल तक नहीं बदला, इसलिए यह अच्छा काम करता था, लेकिन हाल में बदल गया, और Copilot ने coordinates ठीक करने में करीब 30 seconds लिए। किसी इंसान के लिए यह शायद बेहद boring, पूरे दिन का काम होता। हालांकि vibe coding के दौर में हमारी industry experts को कैसे तैयार करने वाली है, मुझे बिल्कुल नहीं पता
LLM के खिलाफ लड़ना हवा के विरुद्ध पेशाब करने जैसा है
मौजूदा तरीके के LLM developers को ज़्यादा productive बनाते दिखते हैं। कम अनुभवी developers को शायद experienced developers से भी ज़्यादा फायदा मिल सकता है। Productivity में बढ़ोतरी, शायद बहुत बड़े multiplier वाली productivity बढ़ोतरी, उन रुकावटों की वजह से छोड़ी नहीं जाएगी जो किसी कारण से technology का विरोध करने वाले लोग खड़ी करते हैं
अगर किसी नए productivity tool से भारी नुकसान का उदाहरण भी सामने आए, जैसे कोई bug जो किसी बड़े service को काफ़ी समय तक बंद कर दे, तब भी अगर वह technology अच्छी-खासी productivity देती है तो वह रुकेगी नहीं। Technology के साथ काम करना और उसकी कमजोरियों को mitigate करना ही इकलौता तार्किक रास्ता है। और वह mitigation ऐसे rules का set नहीं होना चाहिए जो नई technology से मिलने वाले productivity gains को पूरी तरह खत्म कर दे। Mitigation को technology adoption बढ़ाने की दिशा में technology के साथ काम करना चाहिए, वरना उसे bypass कर दिया जाएगा
मेरे अनुभव में, जो लोग ज़ोर देकर कहते हैं कि LLM से उनकी productivity 10 गुना हो गई है, वे आम तौर पर अपेक्षाकृत junior frontend developers होते हैं, या serial startup developers जो बार-बार नई apps शून्य से बनाते रहते हैं। बेशक यह पूरी तरह valid use case है, लेकिन इसी वजह से junior frontend developer और senior embedded C developer AI productivity gains पर बात करते समय आसानी से एक-दूसरे से असहमत हो सकते हैं
यह कहने के बजाय कि technology के साथ काम करना और weaknesses को mitigate करना ही तार्किक है, बस इसे ज़्यादा विवेक से इस्तेमाल करना चाहिए। मसलन, क्या AI “agents” का idea अपने-आप में अच्छा है? हालिया Copilot incident[0] ने MS और AI को मज़ाक जैसा दिखा दिया। AI को autonomous तरीके से काम कराने की कोशिश अपने-आप में बहुत समझदारी भरी न हो सकती है
हालिया analogy blockchain और cryptocurrency है। पसंद करें या न करें, Coinbase वगैरह की सफलता देखकर साफ़ है कि blockchain ने एक असली लेकिन संकुचित use case खोज लिया है। लेकिन cryptocurrency hype के दौर में ऐसे लोग थे जो कहते थे, “हम coffee beans की supply chain को blockchain से track करेंगे।” 2025 में यह Twitter पर की गई अतिशयोक्ति भरी joke जैसा लगता है, लेकिन 2020 में IBM सचमुच ऐसी चीज़ बेचने की कोशिश कर रहा था[1]। शायद कभी पीछे मुड़कर देखने पर हमें लगे कि AI agents या आज के generative AI applications में से कुछ इस bubble के coffee blockchain थे
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
लेकिन इसका मतलब यह नहीं है कि model/human combination users की जरूरतों को ज़्यादा प्रभावी ढंग से पूरा करता है। इसका मतलब है कि वह “ज़्यादा code” produce करता है। ऐसा कोई LLM नहीं है जो 2000 lines of code delete करने वाला changeset output करे। इसलिए समझ आता है कि “engineers को ज़्यादा productive बनाता है” कहना generated code की मात्रा के बारे में है
ऐसा लग रहा है जैसे आप इसे LLM इस्तेमाल करना बनाम न करना वाली binary बहस के रूप में पेश कर रहे हैं, जबकि author मुख्य रूप से risk mitigation की बात कर रहा है। analogy से कहें तो, author ने बस यह point किया कि कुछ cars फट गईं और पुराने घोड़े नहीं फटते थे, इसलिए glue factory चालू करने से पहले cars को कम फटने वाला बनाना चाहिए; लेकिन आप मान रहे हैं कि author car development के ही मूल रूप से खिलाफ है
अभी भी GPT इस्तेमाल करने का मन नहीं करता, लेकिन हाल में colleagues कहते हैं “ChatGPT ने कहा” या “यह code ChatGPT ने बनाया है।” मुझे खुद code लिखने और GPT न इस्तेमाल करने पर गर्व होता है, लेकिन साथ ही मैं Google और Stack Overflow इस्तेमाल करता हूँ। उसे भी GPT का धीमा version कहा जा सकता है
लेखक शायद यह बात चूक गए कि अपूर्ण और probabilistic actors भी भरोसेमंद deterministic systems बना सकते हैं
आप garbage collection tool पर लेखक की विश्वसनीयता के आधार पर भरोसा नहीं करेंगे; बल्कि व्यापक testing के बाद यह देखकर भरोसा करेंगे कि वह इच्छित काम कर पाता है या नहीं। आगे भरोसे के कमजोर पड़ने की तस्वीर आसानी से सोची जा सकती है, और लगता है कि इसके नतीजे में test-driven development को और गति मिलेगी। भरोसा मत करो, verify करो
ज्यादा अहम सवाल यह है कि tests को खुद कौन test करता है। पारंपरिक development में सारी logic दो बार implement होती है। एक बार code में, एक बार tests में। Tests code की जांच करते हैं, और उलटा code implicitly tests की जांच करता है। यह काफी आम है कि bug application code में नहीं, बल्कि test में था। हम tests पर आंख मूंदकर भरोसा करके यह इंतजार नहीं कर सकते कि agent test bug को code में replicate करने का तरीका खोज ले
garbage collection के उदाहरण को लें तो, हां, शायद किसी दिन agentic system कुछ run करके test harness और bug fixes वगैरह से पीट-पीटकर उसे सही कर सके। लेकिन कल्पना करें कि model को garbage collector/tool itself की तरह इस्तेमाल किया जा रहा है। जैसे हर sweep पर program memory को model में डालना और उसे अनावश्यक blocks free करने को कहना। आप कभी भरोसा नहीं कर सकते कि model सही memory blocks को ठीक-ठीक identify करेगा, और कोई “patch” या “fine-tuning” आपको वहां नहीं पहुंचाएगी
JVM जैसी पुरानी abstractions में deterministic output—इस मामले में JIT द्वारा निकाली गई assembly—गलत हो जाए तो उस bug को patch किया जाता है और वह abstraction फिर कभी वही defect नहीं रखती। LLM ऐसा नहीं है। जब हम उन पुराने development tools की बात करते हैं जिन्होंने पूरी industry का चरित्र बदल दिया, तो मेरे लिए यह फर्क बहुत अहम है। मैं यह नहीं कह रहा कि LLM भविष्य के काम करने के तरीके पर गहरा असर नहीं डालेगा। बस मुझे लगता है कि हम ऐसे पूरी तरह अज्ञात क्षेत्र में आ गए हैं जिसका ऐतिहासिक precedent लगभग नहीं है
test-driven development को और गति मिलेगी—यह भी समझ नहीं आता कि TDD को software बनाने की हर समस्या का इलाज करने वाली silver bullet की तरह हमेशा क्यों पेश किया जाता है। गलत tests से शुरू होकर TDD ने गलत software बनाया है, ऐसा मैंने सच कहूं तो शर्मनाक रूप से कई बार देखा है
output को specify करना चाहिए, process को नहीं। यह अपेक्षा करना कि contributor patch को समझे, अच्छी बात है
लेकिन onboarding period में junior को कुछ समय के लिए LLM assistant tools से बचने की सलाह देना या ऐसा require करना भयानक idea है। Onboarding में बहुत सारी random environment setup problems होती हैं, और LLM अक्सर इनमें काफी अच्छे होते हैं। यह code और docs के साथ catch up करने का काम भी है, और ऐसे बेहतरीन text search/summarization tools भी हैं जिन्हें share करना चाहेंगे
अगर आप जीवन से सारी कठिनाई और जटिलता को smooth तरीके से हटा दें, तो यह बिल्कुल साफ लगता है कि ज्यादा समय नहीं लगेगा जब किसी कठिनाई या जटिलता से सामना होने पर आपको बिल्कुल पता नहीं होगा कि क्या करना है। क्या सिर्फ मुझे ही ऐसा लगता है?
LLM के बारे में लेखक जिस phenomenon को AI cliff कहते हैं—“कुछ समय तक सही जवाब के करीब approximate करता है और फिर समय के साथ accuracy तेजी से गिर जाती है”—मैंने पहली बार सुना है। क्या दूसरों ने भी इसका अनुभव किया है?
मौजूदा generators समय के साथ चीजों को सरल बनाने के बजाय ज्यादा complex बनाने की तरफ झुकते हैं। LLM को simplify करके refactor करने का prompt देना, या जब LLM के लिए चीजें बहुत complex हो जाएं तो खुद refactor करना—यह हमेशा मैं ही करता हूं। इसलिए कम-से-कम वर्तमान generation के LLMs में, अगर आप बस “LLM की लगाम छोड़ दें” और उसे मनमानी करने दें, तो काफी अनिवार्य-सा लगता है कि अंत में वह एक विशाल Rube Goldberg-style mess बना देगा और फिर आप उसे साफ करने में लगेंगे
लेख के मुद्दे से जोड़ें तो, अनुभवी व्यक्ति जल्दी पहचान लेगा कि LLM आपको खुले समुद्र की ओर खींचना शुरू कर रहा है, और थोड़ा दूर निकल भी जाए तो उथले पानी में वापस आने का रास्ता खोज लेगा। Beginner को यह समझ आने से पहले ही कि हुआ क्या है, वह अपनी गहराई से बाहर समुद्र में रास्ता भटक जाएगा
कल्पना करें कि context input में 10,000 tokens हैं जो 99% सही हैं। हर बार जवाब देते समय LLM 1,000 tokens जोड़ता है जो 90% सही हैं। कुछ बार आगे-पीछे होकर LLM को सुधारने के बाद, context window ज्यादातर LLM के अपने leftover outputs से भर जाती है। इससे भी बुरा यह है कि errors accumulate होते हैं। जो 90% सही है, वह भी गलत code पर हुई चर्चा का सही extrapolation भर है, और LLM हालिया tokens को ज्यादा importance देता है। यही समस्या prose में भी दिखती है
reasoning models में यह समस्या और बिगड़ सकती है। Reasoning process पूरा context के अंदर होता है, और अगर thinking सचमुच भटक जाए तो decay को खिलाने वाले जहरीले बीज बो देता है। अच्छा होगा अगर किसी रूप में context pruning implement हो सके, ताकि irrelevant context बनने पर उसे काटा जा सके। अभी decay महसूस होने पर मैं summary बनाता हूं और नए instance में चला जाता हूं
claude code, codex, gemini cli जैसे agentic tools में यह समस्या बहुत कम है। क्योंकि ये अपनी context window manage करते हैं और development tools चला कर खुद sanity check कर सकते हैं
यह process आपको current work state document करने की आदत सिखाती है, ताकि नया agent catch up कर सके