समझ ऋण: LLM-जनित कोड जो एक टिक-टिक करता टाइम बम छोड़ जाता है

(codemanship.wordpress.com)

46 पॉइंट द्वारा GN⁺ 2025-10-01 | 8 टिप्पणियां | WhatsApp पर शेयर करें

हाल के समय में LLM (Large Language Model) द्वारा जनरेट किए गए कोड को संशोधित और बेहतर बनाने में डेवलपर्स को अधिक समय लग रहा है
पुराने legacy code की तरह, कोड को सुरक्षित रूप से बदलने के लिए पहले यह समझना ज़रूरी होता है कि क्या बनाया गया और क्यों इस तरह implement किया गया, लेकिन LLM कोड इस प्रक्रिया को और कठिन बना देता है
कुछ टीमें कोड को पर्याप्त रूप से review और rework करती हैं, इसलिए उनकी गति धीमी हो जाती है, लेकिन कई टीमें ऐसा कोड जो ठीक से पढ़ा भी नहीं गया और बस सतही तौर पर test किया गया उसे सीधे repository में डाल देती हैं
इससे “समझ ऋण (Comprehension Debt)” पैदा होता है, और जब आखिरकार कोड में बदलाव की ज़रूरत पड़ती है, तो यह कहीं बड़े समय-खर्च के रूप में वापस आता है
LLM आम तौर पर लगभग 70% स्तर तक समस्या-समाधान में उपयोगी हो सकते हैं, लेकिन बार-बार विफल होने वाले “Doom Loop” से बचा नहीं जा सकता, और अंततः ऐसी स्थिति अनिवार्य रूप से आती है जहाँ इंसान को खुद कोड समझना और ठीक करना पड़ता है

LLM द्वारा जनरेट किए गए कोड और समझ ऋण की समस्या

हाल के डेवलपमेंट माहौल में ChatGPT, Copilot जैसे LLM-आधारित code auto-generation tools का उपयोग बढ़ रहा है
ये tools डेवलपर के ज्ञान या प्रत्यक्ष समझ के बिना भी जटिल कोड को तेजी से जनरेट कर देते हैं
लेकिन इस प्रक्रिया में कोड का इरादा, सीमाएँ, और काम करने का तरीका स्पष्ट रूप से समझ में नहीं आता, जिससे 'समझ ऋण' जमा होने लगता है

समझ ऋण (Comprehension Debt) क्या है

समझ ऋण का अर्थ है ऐसी स्थिति जहाँ टीम के सदस्य कोड की quality, structure, और intent को पर्याप्त रूप से समझ नहीं पाते
अल्पकाल में इससे डेवलपमेंट की गति बढ़ सकती है, लेकिन दीर्घकाल में maintenance cost बढ़ना, bugs आना, और feature expansion सीमित होना जैसी कई समस्याएँ पैदा हो सकती हैं

LLM-जनित कोड के अतिरिक्त जोखिम

LLM द्वारा जनरेट किया गया कोड अक्सर स्पष्ट comments या context दिए बिना सिर्फ परिणाम जल्दी दे देता है
टीम सदस्यों के बीच knowledge sharing की कमी और मौजूदा सिस्टम के साथ compatibility की कमी जैसी समस्याएँ सामने आने की संभावना अधिक होती है
यदि बार-बार LLM कोड पर निर्भर रहा जाए, तो पूरे प्रोजेक्ट की code reliability में गिरावट आ सकती है

तकनीकी ऋण से तुलना

पारंपरिक technical debt आम तौर पर डेवलपर्स द्वारा सचेत रूप से किया गया समझौता होता है, लेकिन LLM-आधारित समझ ऋण अनजाने में जमा हो सकता है, इसलिए इसका जोखिम अधिक है
समस्या को पहचानना कठिन होता है, और कारण का पता लगाना व समाधान करना और अधिक जटिल हो जाता है
समस्या सुलझाते समय “Doom Loop” (जहाँ LLM को बार-बार चलाने पर भी विफलता का दुष्चक्र बना रहता है) का अनुभव आम है

निष्कर्ष और संकेत

आखिरकार इंसान को ही सीधे कोड पढ़ना और ठीक करना पड़ता है
LLM का उपयोग करते समय यह महत्वपूर्ण है कि कोड का context और intent पूरी टीम समझे, इसके लिए documentation और sharing पर ध्यान देना चाहिए
code review को मजबूत करना, comments और documentation को बेहतर बनाना, तथा knowledge sharing sessions जैसे संगठनात्मक उपाय आवश्यक हैं
समझ ऋण को संभाले बिना automation tools के फायदे उल्टा दीर्घकालिक जोखिम में बदल सकते हैं
पूरा उद्योग इस समय तेजी से बढ़ते समझ ऋण के पहाड़ पर बैठा हुआ है

8 टिप्पणियां

shakespeares 2025-10-07

मैं भी हमेशा मानता हूँ कि AI पूरी तरह निर्णय नहीं ले सकता, इसलिए हर कोड में फैसला मैं खुद करता हूँ और यह भी खुद जाँचता हूँ कि वह सही तरीके से काम कर रहा है या नहीं.

cgl00 2025-10-05

मेरे हिसाब से तो यह बस 10 लाइनों से कम के snippets लिखने के काम आता है (जैसे json parsing, sorting implementation)। सिर्फ़ ऐसे इस्तेमाल से भी काफ़ी ज़्यादा समय बचता है।

pcj9024 2025-10-02

AI की मदद से सिर्फ़ बुनियादी ढांचा बनाना तो ठीक है, लेकिन आखिर तक details को सही तरह से निखारना वाकई बहुत मुश्किल लगता है।

dongho42 2025-10-01

मुझे भी व्यक्तिगत रूप से कई बार ऐसे साइड इफेक्ट्स महसूस हुए हैं जब मैंने 0 से 90 तक का काम LLM से करवाया। इसलिए आजकल मैं 0 से 90 तक जितना संभव हो खुद करता हूँ, और 90 से 100 तक जाने की प्रक्रिया में मुख्य रूप से इसका इस्तेमाल करता हूँ, और मैं इससे संतुष्ट हूँ।

GN⁺ 2025-10-01

Hacker News राय

LLM पर निर्भरता बढ़ने के साथ पहले से मौजूद समस्याएँ और भी बदतर होती देखीं।
Naur के "theory building" कॉन्सेप्ट का ज़िक्र करते हुए कहा गया कि अगर किसी प्रोग्राम डेवलपमेंट टीम का विघटन हो जाए, तो वह प्रोग्राम व्यावहारिक रूप से मृत हो जाता है।
Lamport के 'programming ≠ coding' तर्क का हवाला देते हुए यह ज़ोर दिया गया कि programming का सार इस बात की theory बनाना है कि 'क्या' और 'कैसे' हासिल किया जाएगा।
ऐसा लगता है कि जो programmers ज़रूरी models या theories नहीं बनाते, वे LLM से जल्दी मदद मिलने का एहसास अधिक करते हैं।
- वास्तव में कंप्यूटर और टेक्नोलॉजी से पूरी तरह दूर होने पर भी software projects में अधिक value create करने का अनुभव रहा है।
  जब बिल्कुल स्पष्ट हो कि क्या चाहिए, तो development की गति बहुत बढ़ जाती है, और तब LLM बेहद उपयोगी हो जाता है।
  अगर लक्ष्य साफ हो, तो LLM की hallucination भी तुरंत पहचानी जा सकती है।
  सिर्फ खाली canvas को देखते हुए शुरू करने वाला approach प्रभावी नहीं लगता।
  LLM शुरुआत में मदद कर सकता है, लेकिन गलत दिशा में भटकाने के मामले भी बहुत रहे हैं।
  सबसे कठिन समस्याएँ कई बार रसोई में खाना बनाते हुए सोचने पर हल हुईं।
- AI coding में साथियों की तुलना में थोड़ा ज़्यादा सफल होने का एक कारण यह रहा कि LLM आने से पहले भी मैं जल्दी prototype बनाकर, फिर structure को पूरी तरह बदलने या फेंक देने की प्रक्रिया दोहराता था।
  यह approach—तेज़ prototyping, लगातार refactoring वगैरह—काफी जाना-पहचाना है, लेकिन कई engineers या तो शुरुआत से ही सब कुछ perfect design करना चाहते हैं, या prototype पर बिना सुधार किए लगातार patch ही लगाते रहते हैं।
  AI के साथ कई parallel implementations कम लागत पर संभव हो जाते हैं, इसलिए अलग-अलग versions को आज़माकर और तुलना करके अंततः program theory या design को तेज़ी और प्रभावी ढंग से बेहतर बनाया जा सकता है।
  AI इस loop को छोटा कर देता है और output की review पर ज़्यादा ध्यान देने देता है, जिससे development process कहीं अधिक efficient हो जाती है।
- 'theory building' का विचार LLM code के 'understanding debt' से जुड़ता है, यह बात प्रभावशाली लगी।
  यह सिर्फ programming तक सीमित नहीं है, बल्कि मानव सोच और समझ की प्रक्रिया से भी गहराई से जुड़ा है।
  LLM द्वारा बनाया गया code, text या image सिर्फ सतही परिणाम हैं; इनके पीछे की theory को खुद बनाए और अनुभव किए बिना समझ केवल सतह पर ही रह जाती है।
  भविष्य में अगर LLM theory building भी करने लगे, तब भी मनुष्य की प्रत्यक्ष भागीदारी के बिना बनी कृत्रिम समझ अर्थहीन-सी लगेगी।
  चिंता यह है कि जैसे-जैसे मशीनें हमारी जगह सोचना आसान बनाती जाएँगी, मनुष्य की <समझ> की क्षमता धीरे-धीरे क्षीण हो सकती है।
- Lamport की बात से सहमत होते हुए भी लगता है कि AI 'theory building' प्रक्रिया—यानी codebase, algorithms और पूरे system की समझ—में मौजूदा टीमों और handover लेने वाली टीमों दोनों की कुछ हद तक मदद कर सकता है।
  भले ही यह सारी knowledge को पूरी तरह replace न कर सके, फिर भी AI कुछ खाइयाँ भर सकता है।
- ऐसा अनुभव रहा कि पुराने developers के पूरी तरह चले जाने के बाद नई टीम ने project संभाला, और पिछली टीम की सारी knowledge गायब हो चुकी थी, जिससे बहुत कठिन समय गुज़रा।
  मूल design को समझने की कोशिश में bugs बढ़े, और अंततः code के बड़े हिस्से को rewrite और extend करना पड़ा।
  लेकिन इस कठिनाई के बीच कई design issues को खुद दोहराकर सीखने का मौका भी मिला।
LLM अक्सर काम करने वाले solutions दे देता है, लेकिन कई बार ज़रूरत से कहीं अधिक complex code पैदा करता है।
जब code पहली बार लिखा जाता है, तब समस्या को सबसे अच्छी तरह समझा जाता है, इसलिए complexity हटाना आसान होता है; लेकिन बाद में वही complex code ज़रूरी समझ लिया जाता है और उसे बहुत simplify करना और कठिन हो जाता है।
Code maintainers के पास context या background knowledge की कमी होती है, इसलिए उन्हें अक्सर पता ही नहीं चलता कि कोई सरल विकल्प भी संभव था।
- LLM से अनावश्यक complexity से बचने का तरीका सरल है।
  पहला, prompt को स्पष्ट रखें ताकि LLM बेवजह complex output न बनाए।
  दूसरा, rules, training या context के ज़रिए हमेशा यह बताना चाहिए कि समस्या का समाधान जितना संभव हो उतना simple होना चाहिए।
  अंत में, अगर complex solution निकल आए, तो अतिरिक्त prompt देकर complexity कम करने को कहा जा सकता है।
LLM द्वारा बहुत बड़ी मात्रा में ऐसा code बनाना, जिसे debug करना मुश्किल हो, यह समस्या वास्तव में मौजूद है।
सिद्धांत यह है कि quality को महत्व देने वाली टीमों को code को पर्याप्त review करके समझना चाहिए, लेकिन code generation की गति इतनी तेज़ होती है कि review पीछे छूट जाता है और bottleneck बन जाता है, या फिर सिर्फ औपचारिक approval देकर आगे बढ़ा दिया जाता है।
आसपास लोग लगातार review process बढ़ाते जा रहे हैं, लेकिन यह तरीका junior developers पर तो काम करता है, AI पर नहीं, क्योंकि वह सीखता नहीं और वही issues दोहराता है।
LLM को बहुत context चाहिए, लेकिन अधिकतर लोग उसे लगभग कोई जानकारी दिए बिना सिर्फ इतना कहते हैं, "इस समस्या को हल करने वाला function बना दो।"
आखिरकार सभी ऐसे code का पहाड़ जमा कर रहे हैं जिसे कोई ठीक से समझता नहीं—यानी tech debt।
मूल रूप से ज़रूरत ऐसी 'primitive' की है जो LLM को यह context अधिक प्रभावी ढंग से दे सके कि उसे यह चीज़ क्यों, किस background, किस intent और किन prior examples को ध्यान में रखकर बनानी चाहिए।
- अगर code review bottleneck बनता है, तब भी coding और review दोनों एक ही व्यक्ति द्वारा करने से बेहतर है कि bottleneck सिर्फ code review में हो।
  इस प्रक्रिया को support करने वाले tools—lint, fuzzing, tests वगैरह—पहले से मौजूद हैं।
  जिन लोगों में पूरे project की architecture बनाने या code को जल्दी पढ़कर analyze करने की क्षमता कम है, उनके लिए LLM का युग कठिन हो सकता है, लेकिन ये skills सीखी जा सकती हैं और समय के साथ सब adapt कर लेंगे।
  मुझे यह क्षेत्र पसंद है, इसलिए इस नए challenge को सकारात्मक रूप से देखता हूँ।
- अलग-अलग instruction .md files बनाकर agents के लिए coding rules, जिन pitfalls से हर हाल में बचना है, और coding standards docs के links जैसी चीज़ें डालकर उन्हें लगातार update करने का अनुभव रहा है।
  Gemini और Claude जैसे models ऐसे document-based instructions को कुछ हद तक अच्छी तरह follow करते हैं, लेकिन कभी-कभी बार-बार वही गलतियाँ भी करते हैं (e.g., C++ में auto इस्तेमाल न करने का निर्देश देने पर भी उसका उपयोग करना)।
  उम्मीद है कि models बेहतर होंगे तो इस तरह का feedback handling भी और सुधरेगा।
  आखिरकार 'vibe coding' से बाहर निकलकर code structure और units के बीच interaction पर मनुष्य को खुद ध्यान देना चाहिए, जबकि AI को syntax और typing पर केंद्रित रखना productivity और overall direction दोनों के लिए आदर्श समझौता लगता है।
- prompts और context को बनाने के तरीके में बदलाव करने के बाद LLM के उपयोग को लेकर intuition और बेहतर हुई।
  अब prompts और context के माध्यम से output के संभावित probability space को सीमित करने के नज़रिए से काम करता हूँ।
  यह प्रक्रिया code की theory को reusable रूप में inject करने में भी बहुत प्रभावी है।
  हालाँकि, ऐसा context तैयार करने में काफी मेहनत और सोच लगती है, और कहाँ खुद implement करना बेहतर है तथा कहाँ LLM को काम सौंपना बेहतर है, यह सीमा अब भी तय करना आसान नहीं है।
- "primitive अलग है" वाली बात से सहमति है, और लगता है कि असल महत्वपूर्ण unit 'tests' हैं।
  Model से code लिखवाते समय tests भी साथ में बनवाने चाहिए और हमेशा देखना चाहिए कि tests पढ़ने में आसान हैं या नहीं।
  Code तभी merge होना चाहिए जब पूरे tests pass हों।
  Test infrastructure को लगातार बेहतर बनाना चाहिए ताकि पूरा test suite बहुत slow न हो जाए।
  पुराने legacy code की एक पहचान tests का न होना था, और LLM युग में भी वही बात लागू होती है।
- "bottleneck बनता है" वाली बात पर, StackOverflow से code paste करते समय भी हम हमेशा उसे पढ़कर और review करके ही इस्तेमाल करते हैं, इसलिए वैसे भी bottleneck इंसान ही है।
  आखिरकार इस प्रक्रिया के बिना code का इस्तेमाल करना लगभग असंभव है।
हाल ही में Dwarkesh Patel podcast में एक guest ने <A Deepness In The Sky> नाम का उपन्यास सुझाया, और पढ़ते समय यह बात बहुत रोचक लगी कि उसमें हज़ारों साल पुराने computer systems और legacy knowledge अहम भूमिका निभाते हैं।
यह legacy code और organizational knowledge की value को दिलचस्प ढंग से पेश करने वाला शानदार उपन्यास है, इसलिए इसे recommend किया जा सकता है।

podcast: https://www.youtube.com/watch?v=3BBNG0TlVwM
book info: https://amzn.to/42Fki8n
- Vernor Vinge के निधन का अफसोस है, और लगता है कि उनके ideas समय के साथ और भी ज़्यादा वास्तविक प्रेरणा देते हैं।
- दूर भविष्य में programmer बनने की प्रक्रिया का वर्णन बहुत दिलचस्प लगा।
  बेहद बड़ी संख्या में libraries और packages के कारण नया code लिखना मुख्य skill नहीं था, बल्कि मौजूदा modules को ढूँढकर जोड़ना ही प्रमुख क्षमता थी।
  मौजूदा code के सूक्ष्म nuances और उसके interpretation को गहराई से समझना ही असली कौशल के रूप में दिखाया गया।
- "A Deepness In The Sky" श्रृंखला की दूसरी किताब लगती है; क्या पहली किताब पढ़े बिना भी इसे पढ़ना ठीक रहेगा?
  यही सवाल पूछा गया कि क्या इसे सीधे पढ़ा जा सकता है।

अधिकांश developers assembly या machine code स्तर तक नहीं समझते।
High-level languages इंसानों के बीच communication और collaboration की मुख्य layer बन चुकी हैं।
LLM के आने से वह layer अब natural language और spec-based development की ओर धकेली जा रही है।
आखिरकार लगता है कि high-level languages कई दशकों के विकास के बाद program behavior की specification देने का लगभग optimal रूप बन चुकी हैं।
Natural language में और अधिक abstractions ले जाने पर information loss होता है, और lower-level language पर जाने पर चीज़ें बहुत verbose हो जाती हैं।
- Natural language की ओर यह छलांग सिर्फ abstraction layer का बदलाव नहीं, बल्कि मूल रूप से पूरी तरह नया तरीका है।
  पुराने tools—assembler, compiler, framework वगैरह—hardcoded logic पर आधारित थे और उनका mathematical verification संभव था, लेकिन LLM के बाद हम ऐसी दुनिया में प्रवेश कर रहे हैं जहाँ uncertainty, अनुमान, और यहाँ तक कि hallucination भी मिली-जुली रहती हैं।
- बहुत से JavaScript developers high-level concepts (जैसे उपयुक्त data structures, DOM, Node API आदि) तक को गहराई से नहीं समझते।
  Abstraction layers पर अत्यधिक निर्भरता बन जाती है, और अंदरूनी कामकाज जाने बिना ही काम चलता रहता है।
  किसी बाहरी व्यक्ति के लिए यह पूछना स्वाभाविक है, "यहाँ वास्तव में हो क्या रहा है?"
  यह स्थिति पहले ही रोज़मर्रा की सामान्य बात बन चुकी है।
  रूपक के तौर पर कहा गया कि जब कोई भी code के भीतर को सही से नहीं जानता, तो LLM द्वारा code लिखे जाने से भी मूलभूत अंतर नहीं रह जाता।
- Natural language specifications की भूमिका है, लेकिन लगता है कि बीच में एक ऐसी language या layer भी ज़रूरी है जिसकी semantics सख्त हो।
  उदाहरण के तौर पर Rust और LLM के संयोजन में, मजबूत type system invalid states को बंद कर देता है, और compile होने में समय लगे तब भी अंततः desired result प्रायः सही निकलता है।
  Rust community में "अगर compile हो गया तो ज़्यादातर काम करेगा" जैसी संस्कृति है; फिर भी logical bugs आ सकते हैं, लेकिन error space वास्तव में संकरा हो जाता है।
  आदर्श रूप में, ऐसी सख्त programming language हो जिसमें logical meaning कठोर रूप से परिभाषित हो, साथ ही preconditions, postconditions जैसी specifications भी जुड़ें, और LLM natural language को formal specification में बदलने का काम करे।
- Natural language अपने स्वभाव से ही अस्पष्ट और बहुअर्थी होती है।
  Programming language में parsing ambiguity को गंभीर bug माना जाता है, लेकिन natural language में यही अस्पष्टता कविता, nuance, संकेत और संप्रेषण के कई अन्य रूपों का आधार बनती है।
- High-level languages की deterministic (import) प्रकृति ही एकमात्र अंतर नहीं है।
  Programming में determinism ही सब कुछ नहीं, और इंसानी नज़रिए से अर्थहीन लगने वाला code भी पूरी तरह deterministic हो सकता है।
  यानी 'high/low-level abstraction' और 'deterministic/probabilistic' दो बिल्कुल अलग axes हैं।
मुझे और मेरी टीम को यह आने वाले बड़े काम के तूफ़ान जैसा दिखता है।
करीब 8 साल से legacy code को बचाकर business चलाया है, लेकिन हाल में कंपनियाँ coding के लिए LLM पर निर्भर होने लगी हैं, इसलिए demand कुछ कम हुई है।
फिर भी अनुमान है कि अगर अगले लगभग 18 महीने टिके रहे, तो थोड़े समय में जमा हुए LLM-आधारित tech debt को ठीक करने के लिए भारी मात्रा में requests आएँगी, और यह एक बड़ा अवसर बनेगा।
Claude द्वारा "अब code production level का है" कहकर छोड़े गए debt का नुकसान जल्द दिखने लगेगा।
किसी परिचित ने LLM द्वारा बनाए गए PR की review करते समय का एक किस्सा साझा किया।
ऊपर से देखने पर PR पूरी तरह काम करता हुआ लगा, लेकिन अंदर जाकर पता चला कि असल में backend को update किए बिना सिर्फ cache से छेड़छाड़ की गई थी।
यह code merge नहीं होना चाहिए, यह manager को समझाने में काफी मेहनत लगी।
आखिरकार शक होने लगा कि दुनिया में काफी मात्रा में ऐसा 'vibe coded' software मौजूद होगा जो सिर्फ ऊपर-ऊपर काम करता दिखता है।
- ऐसे मामलों में शायद बस merge होने देना और बाद में उसका असर खुद झेलने देना बेहतर हो।
  गलत फैसलों के परिणाम खुद अनुभव करने पर ही लोग सीखते हैं।
  Feedback न मिले तो learning भी नहीं होती, और ऐसे managers अक्सर वास्तविकता से कटकर development team पर अव्यावहारिक उम्मीदें और दबाव बढ़ाते रहते हैं, जिससे लोग थकते हैं और बदल दिए जाते हैं।
- यह सोचकर हैरानी होती है कि कोई non-expert engineering manager इतने लंबे समय तक industry में कैसे बना रहा।
  पिछले 15 सालों में लगभग कोई सचमुच non-technical manager नहीं देखा।
- अगर ऐसा manager समस्या पैदा कर रहा हो, तो बात CTO, CEO, owner या investors तक ले जानी चाहिए।
सिर्फ LLM code ही नहीं, किसी और के लिखे code के साथ भी हर किसी को 'understanding debt' चुकानी पड़ती है।
Google जैसी बड़ी कंपनियों में भी नए engineers को algorithms में बड़े बदलाव जल्दी करने से पहले महीनों तक समझ बनानी पड़ती है।
फिर भी, इंसानों द्वारा अच्छी तरह design किया गया code, LLM outputs की तुलना में कहीं अधिक आसानी से समझ में आता है।
- अच्छी तरह design किए गए human code का फायदा यह है कि उसमें context और organizational knowledge का उपयोग आसानी से किया जा सकता है।
  सीधे लोगों से समझाया जा सकता है, जबकि LLM भी विश्वसनीय लगने वाले जवाब देता है, लेकिन वास्तविक context में फर्क बना रहता है।
मैंने भी काफी 'vibe coding' की है, लेकिन अंततः code का mental model बनता नहीं, इसलिए समय की बचत दिखने पर भी debugging में बाद में कहीं ज़्यादा समय गंवाना पड़ता है।
शुरुआत से ही हर design को पूरी तरह perfect बना देना वास्तविक दुनिया में संभव नहीं है।
और 'accepted lines of code' को productivity या time saving का विश्वसनीय मापदंड मानना भी कठिन लगता है।
- वास्तव में लगातार 'vibe coding' करते रहने वाला कोई मिलना मुश्किल है; स्वाभाविक है कि लोग जल्दी ही इससे पीछे हट जाते हैं।
  LLM-निर्भर code भी सावधानी से review करके और सही shape में ढालते हुए इस्तेमाल करना निश्चित रूप से प्रभावी है।
  यह प्रक्रिया बल्कि 'pair programming' के ज़्यादा करीब लगती है।
  यह ज़ोर देकर कहा गया कि बिना किसी review के सीधे LLM output का उपयोग करना (यानी "vibe coding") वास्तव में efficient हो ही नहीं सकता।
Kernighan's Law का उदाहरण देते हुए कहा गया: "debugging code लिखने से दोगुना कठिन है।"
इसलिए अगर LLM code generate करे, तो शायद उसे debug करने के लिए उससे दोगुना smarter LLM चाहिए होगा।
- मेरा अनुभव हमेशा ऐसा नहीं रहा; मुझे तो हर बार खुद driver seat में रहना पड़ता है।
  मुख्य रूप से Claude Code इस्तेमाल करता हूँ, और जब भी वह गलती करता है, मुझे साफ़-साफ़ बताकर ठीक करवाना पड़ता है या समस्या वाले हिस्से को अलग से दिखाना पड़ता है।
  LLM को अपने आप यह पता नहीं चलता कि उसने क्या गलती की, इसलिए उसके साथ काम करना कुछ-कुछ junior developer के साथ काम करने जैसा लगता है।
  यानी debugging उसी intelligence level पर भी संभव है, लेकिन LLM खुद समस्या को पहचान नहीं पाता।
- "debugging के लिए दोगुनी समझदारी चाहिए" वाली बात शायद LLM के अलग-अलग 'thinking depth' modes के अंतर से भी जुड़ सकती है।
  किसी complex function के लिए पहले code comments लिखवाकर या जोड़कर LLM report में intent और approach को साफ़ समझाने का तरीका इस्तेमाल किया जाता है।

ahwjdekf 2025-10-02

टिप्पणियों में एक लेख है कि जैसे किसी दूसरे डेवलपर द्वारा लिखा हुआ कोड उठाकर इस्तेमाल करने पर भी review की ज़रूरत होती है, वैसे ही LLM के मामले में भी कोई फ़र्क नहीं है, लेकिन मैं इससे सहमत नहीं हूँ। इंसानों के मामले में प्रतिष्ठा, नाम, इनाम और सज़ा जैसी चीज़ें काम करती हैं। शायद अगर कोई अभी LLM की तरह काम करे, तो उसे तुरंत नौकरी से निकाल दिया जाएगा।

bus710 2025-10-01

मैं हमेशा यह सोचता हूँ कि "AI आपकी जगह ज़िम्मेदारी नहीं लेता।"