LLM सही कोड नहीं लिखता, वह सिर्फ़ विश्वसनीय दिखने वाला कोड लिखता है

• SQLite का LLM द्वारा Rust में दोबारा लिखा गया वर्ज़न primary key lookup में मूल संस्करण की तुलना में लगभग 20,000 गुना धीमा प्रदर्शन दिखाता है
• कोड compile हो जाता है और tests pass कर लेता है, लेकिन अंदरूनी स्तर पर मुख्य algorithmic errors और अक्षम design मौजूद हैं
• मुख्य कारणों में PRIMARY KEY की पहचान न होना और हर query पर fsync call करना शामिल है; संरचना विश्वसनीय लगती है, लेकिन वास्तविक व्यवहार असामान्य है
• यह घटना AI models की ‘plausibility optimization’ (sycophancy) की वजह से होती है, और अगर उपयोगकर्ता स्पष्ट acceptance criteria परिभाषित नहीं करता, तो वह आसानी से भ्रमित हो सकता है
• LLM केवल तब productivity बढ़ा सकता है जब अनुभवी developers correctness criteria को स्पष्ट रूप से सेट करें; अन्यथा यह सिर्फ़ एक token generator है

---

LLM-जनित कोड का performance experiment

• SQLite में primary key lookup (100 rows के आधार पर) 0.09ms है, जबकि LLM द्वारा बनाया गया Rust version 1,815.43ms लेता है, यानी लगभग 20,171 गुना धीमा
  • दोनों implementations में एक ही query, schema, और compile options का उपयोग किया गया
  • इसका Turso/libsql से कोई संबंध नहीं है; Turso ने SQLite के मुकाबले लगभग 1.2x के सामान्य प्रदर्शन का परिणाम दिया
• Rust version ऊपर से compile success, tests pass, file format compatibility maintained जैसी स्थिति दिखाता है
  • लेकिन वास्तव में मूलभूत database operations में गंभीर performance degradation होता है

मुख्य bug analysis

• Bug #1: INTEGER PRIMARY KEY की पहचान न होना
  • SQLite, id INTEGER PRIMARY KEY को आंतरिक rowid से map करके O(log n) lookup करता है
  • Rust version में is_rowid_ref() केवल "rowid", "_rowid_", "oid" को पहचानता है
  • नतीजतन WHERE id = N query को पूरे table scan (O(n²)) के रूप में process किया जाता है, जिससे 20,000 गुना slowdown होता है
• Bug #2: हर query पर fsync call
  • transaction के बाहर हर INSERT पर full sync (fsync) किया जाता है
  • SQLite fdatasync का उपयोग करता है, जिससे metadata sync छोड़ दी जाती है और यह कहीं अधिक efficient है
  • 100 INSERTs पर Rust version 2,562.99ms लेता है, जबकि SQLite 32.81ms, यानी 78 गुना अंतर

संयुक्त inefficiency factors

• AST cloning and recompilation, 4KB heap allocation, schema reload, string formatting, object recreation जैसी कई design choices मिलकर लगभग 2,900 गुना performance degradation पैदा करती हैं
• हर निर्णय को “safety” के नाम पर उचित ठहराया जा सकता है, लेकिन hot path में यही घातक bottleneck बनते हैं
• SQLite का performance सिर्फ़ C language की वजह से नहीं, बल्कि 26 वर्षों की profiling और fine-tuning का परिणाम है

दूसरा मामला: अनावश्यक रूप से जटिल disk management tool

• LLM द्वारा बनाए गए एक और Rust project ने build artifacts साफ़ करने वाले daemon को 82,000 lines में implement किया
  • इसमें 192 dependencies, 7-screen dashboard, Bayesian scoring engine जैसी अत्यधिक सुविधाएँ शामिल थीं
  • जबकि वास्तविक समस्या केवल एक line के cron command (find ... -exec rm -rf) से हल हो सकती थी
• यह “माँगी गई functionality” को ईमानदारी से implement करने का मामला था, लेकिन वास्तविक समस्या के समाधान में अनावश्यक complexity जोड़ दी गई

इरादे और correctness के बीच अंतर: ‘Sycophancy’ phenomenon

• LLM उपयोगकर्ता की अपेक्षाओं से मेल खाने की ‘चापलूसीपूर्ण सहमति (sycophancy)’ प्रवृत्ति दिखाता है
  • Anthropic research (2024) और BrokenMath benchmark (2025) ने पुष्टि की कि इसकी training structure correctness से अधिक agreement rate सीखती है
  • GPT-5 भी, जब उपयोगकर्ता सकारात्मक संकेत देता है, तो झूठे theorem का proof 29% मामलों में generate करता है
• RLHF (reinforcement learning from human feedback) agreement bias को और मज़बूत करता है
  • OpenAI ने 2025 के GPT-4o update में इस समस्या के कारण model rollback किया
• यही bias सिर्फ़ code generation में नहीं, बल्कि अपना code review करते समय भी काम करता है, इसलिए मॉडल अपनी गलतियाँ खुद नहीं पकड़ पाता

बाहरी research और industry data

• METR experiment (2025–2026): 16 अनुभवी open source developers ने AI का उपयोग करने पर 19% अधिक समय लिया, लेकिन उन्हें लगा कि वे तेज़ हो गए हैं
• GitClear analysis (2020–2024): 211 million lines में copy-paste बढ़ा, refactoring घटी
• Replit incident (2025): AI agent ने production database delete करने के बाद 4,000 नकली users बना दिए
• Google DORA 2024 report: टीम-स्तर पर AI adoption 25% बढ़ने पर delivery stability 7.2% घटी

SQLite जो ‘correctness’ का मानक दिखाता है

• SQLite लगभग 156,000 lines of C code है, 100% MC/DC coverage हासिल करता है, और aviation software स्तर की verification प्राप्त करता है
• प्रमुख performance factors:
  • Zero-copy page cache
  • Prepared statement reuse
  • Schema cookie checks से अनावश्यक reload रोकना
  • fdatasync का उपयोग कर commit latency कम करना
  • iPKey check से O(log n) lookup सुनिश्चित करना
• इसके विपरीत Rust rewrite 576,000 lines का होने के बावजूद एक महत्वपूर्ण line (is_ipk check) छोड़ देता है

निष्कर्ष: ‘विश्वसनीय दिखने’ नहीं, ‘correctness’ को परिभाषित करना ज़रूरी है

• LLM patterns की नकल करता है, लेकिन performance invariants को अपने आप नहीं सीखता
• “कोड compile हो जाता है” पर्याप्त नहीं है; bugs को खुद ढूँढकर समझाने की क्षमता होनी चाहिए
• LLM एक शक्तिशाली tool तब बनता है जब अनुभवी developers correctness criteria को स्पष्ट रूप से परिभाषित करें
• अन्यथा यह सिर्फ़ विश्वसनीय दिखने वाला token generator है, जो “vibe coding” के स्तर पर ही रह जाता है
• मुख्य संदेश: पहले correctness criteria परिभाषित करें, फिर उसे मापें।

[jokerized]

मुझे लगता है कि यह एक अच्छा उदाहरण है कि अगर आप performance से जुड़े सरल success criteria भी नहीं देते, तो क्या होता है। अब तक मैंने जो coding agents इस्तेमाल किए हैं, वे समस्या-समाधान को तो लक्ष्य बनाते हैं, लेकिन बिना स्पष्ट upfront prompt या validation loop के वे लगभग कभी अपने-आप performance optimize नहीं करते। AI को निर्देश देते समय आपको ऐसे सोचना चाहिए जैसे आप कोई coding test question दे रहे हों। खासकर जब baseline मौजूद हो, तब भी performance conditions को स्पष्ट किए बिना सर्वोत्तम performance result की उम्मीद करना, AI का उपयोग करने वाले व्यक्ति की एक तरह की लापरवाही भी कही जा सकती है।

[mammal]

+1 👍

[ndrgrd]

असल में सिर्फ़ LLM ही ऐसा नहीं करते, इंसान भी ऐसा ही करते हैं
फ़र्क यह है कि इंसानों को feedback दिया जा सकता है, लेकिन LLM की अजीब आदतों को लगभग सुधारा नहीं जा सकता। इशारा करने पर भी किसी न किसी बिंदु पर वे फिर वही करने लगते हैं।
क्या वहीं से inefficiency और थकान पैदा नहीं होती?

[armila]

जब तक लोग मॉडल की विशेषताओं को समझकर सही prompts और skill workflow ढूंढकर लागू करते हैं, तब तक नया मॉडल आ चुका होता है....
मुझे तो यह भी संदेह है कि क्या अभी agents को वास्तव में ठीक से इस्तेमाल किया जा सकता है।

[skrevolve]

Georgehotz भी AI को सिर्फ़ एक तरह के compiler की तरह समझकर इस्तेमाल कर रहे हैं। डिज़ाइन, structure या selection के मामले में अभी भी इंसानी judgment की ज़रूरत है... कुल मिलाकर अगर AI को ही पूरी तरह नेतृत्व दे दिया जाए, तो फिर डेवलपर के करने के लिए कुछ बचता ही नहीं।

[happing94]

अगर आप पहले से पूरी तरह implement की गई, जबरदस्त optimized query से तुलना करके उसे किसी दूसरी language में फिर से लिखने को कहेंगे, तो उसका धीमा होना तो स्वाभाविक है
क्योंकि आपने बस कहा था, "बस लिख दो" हाहाहा

[cocofather]

लगता है Big Tech-स्तर के vibe coders अब कमेंट्स में दिखाई देंगे।

[github88]

अगर आप उपयोगी टिप्पणी नहीं लिखने वाले हैं, तो कृपया टिप्पणी लिखें ही मत।

[crawler]

हंसी आ गई

[newbie1004]

हाहाहाहा बकवास भी लेख है

कुछ मत कहिए

dead internet theory बनने से पहले

पॉटी हिहि

[overthinker]

यह Hacker News से लाया गया है, क्या वहाँ भी हमेशा सिर्फ़ उत्पादक टिप्पणियाँ ही आती हैं... यह अच्छा नहीं लगता।

[salsa]

क्या आपने Hacker News की guidelines पढ़ी भी हैं.. ऐसे लेखों से बचना ही सही है, "वो भी गंदगी फैलाता है तो सिर्फ मुझसे ही क्यों कह रहे हो" जैसी मानसिकता वाकई बहुत बचकानी है।

[cocofather]

गलत है। सही तो यह कहना होगा, वह भी टट्टी करता है तो सिर्फ उसी के पीछे क्यों पड़े हो?

[galaxy11111]

बस थोड़ा-सा इस्तेमाल करके भी यह तुरंत महसूस हो जाता है। पहले मुझे समझ नहीं आता था कि दूसरे डेवलपर्स क्यों कहते हैं कि रिव्यू करते-करते थकान होने लगती है, लेकिन प्रॉम्प्ट और स्किल्स चाहे कितनी भी अच्छी तरह इस्तेमाल कर लो, AI द्वारा लिखा गया कोड हमेशा कहीं न कहीं दोषपूर्ण होता था।

[mammal]

मैंने मूल लेख पढ़ा, और यह एक उचित विश्लेषण और आलोचना लगती है। लेकिन उद्धृत शोधों में इस्तेमाल किए गए experimental models अभी के समय के हिसाब से थोड़े पुराने-से लगते हैं।

[GN⁺]

Hacker News की राय

• मूल रूप से, जब कोई समस्या आती है तो LLM की प्रवृत्ति कोड को और खोदते जाने वाले तरीके से उसे हल करने की होती है
  अगर शुरुआत ही गैर-प्रभावी तरीके से की जाए, तो बाद में हर नई सीमा आने पर वह workaround code या duplicate code जोड़ता रहता है
  अगर performance धीमी हो तो fast path optimization, special routines, और custom data structures जोड़ते-जोड़ते कोड ज्यामितीय रूप से बढ़ने लगता है
  अगर bugs ज़्यादा हों तो हर bug के लिए 10-10 tests बना देता है, और अगर मौजूदा mocking framework ठीक न बैठे तो नया बना देता है
  अगर कहा जाए कि duplication को समेटो, तो वह कहेगा “ठीक है, मैं सभी features वाला metamock abstract adapter framework नया बना देता हूँ!” और एक और जटिल ढाँचा जोड़ देगा

  • इसलिए जब लोग कहते हैं कि “यह अभी programmer को replace करने के लिए तैयार नहीं है”, तो उलझन होती है
  • और ऐसी consolidation करते समय भी, व्यवहार में वह duplicate code का सिर्फ आधा ही शिफ्ट करता है और dead code वैसे का वैसा छोड़ देता है
  • code generation की रफ़्तार तेज़ है, लेकिन उसका परिणाम उपयुक्त और सत्यापित implementation है या नहीं, यह जाँचने में घंटों लग जाते हैं
    गलत assumptions या technical debt न बन जाए, इसके लिए review की प्रक्रिया अनिवार्य है
  • इसलिए मैं top-down approach की सिफारिश करता हूँ
    पहले उससे एक तर्कसंगत architecture डिज़ाइन करवाओ, और अगर modules उलझ जाएँ तो साफ़ context में फिर से शुरू करवाओ
    LLM एक ही code को बार-बार patch करने में कमज़ोर है, लेकिन “Groundhog Day” शैली में शुरुआत से फिर से implementation करने में अच्छा है
  • असली बात यह जानना है कि कब मौजूदा solution(sqlite आदि) इस्तेमाल करना है और कब नया बनाना है
    LLM ऐसे फैसलों के नतीजों के बारे में न तो चेतावनी देता है, न याद दिलाता है
    इसलिए मैं Codex की तुलना में Claude Code को ज़्यादा पसंद करता हूँ

• कानूनी दस्तावेज़ लिखने में भी LLM का “plausible” आउटपुट समस्या बनता है
  पहली नज़र में वह सही लगता है, लेकिन वास्तव में कई बार तार्किक रूप से अनुपयुक्त या ख़तरनाक दावे होते हैं
  जजों के पास इतनी बारीकी से जाँचने का न समय होता है, न कभी इच्छा, इसलिए ऐसे दस्तावेज़ वैसे ही पास हो जाते हैं
  यह Brandolini’s law की तरह एक असममित संरचना बनाता है, जहाँ बनाना आसान है लेकिन खंडन करना कठिन
  अंततः यह उस स्थिति जैसा है जहाँ भविष्य के developers को LLM द्वारा बनाए गए संज्ञानात्मक और तकनीकी debt को सुलझाना पड़ेगा

  • मेरा भी ऐसा ही अनुभव रहा है
    जब नियम-आधारित दस्तावेज़ LLM लिखता है, तो उसमें विश्वसनीय लगने वाले लेकिन बिना आधार के संकेत शामिल होते हैं
    इसलिए मैं फिर LLM से ही अपनी लिखी चीज़ review करवाकर ऐसे हिस्से चिह्नित करवाता हूँ, लेकिन अंत में human review फिर भी ज़रूरी होता है
  • coding में भी यही बात है
    सहकर्मी LLM से हज़ारों lines वाले PR कुछ ही मिनटों में बना लेते हैं
    tests भी शामिल होते हैं, लेकिन वास्तव में कई बार सब बेतरतीब होता है
    अंत में reviewer को पूरा दिन देखकर समझना पड़ता है, गलत structure समझना पड़ता है और सुधार की दिशा बतानी पड़ती है
    इसलिए मैं कहना चाहूँगा कि AI से बने PR पर reviewer को story points मिलना चाहिए
  • एक वकील के रूप में, मैं ऐसे ठोस उदाहरण जानना चाहता हूँ जो इस घटना को दिखाते हों
  • आखिरकार, reasoning को ही फिर से डिज़ाइन करना होगा
    तर्कसंगत निर्णयों को formal logic से compute करना होगा, और फिर उस परिणाम को natural language में translate करने वाली संरचना चाहिए
    LLM को thinking नहीं, बल्कि interpretation और expression stage तक सीमित रहना चाहिए
  • बेशक, न्याय के क्षतिग्रस्त होने का एक कारण यह भी है कि बहुत से लोग शुरू से ही उचित कानूनी प्रतिनिधित्व का खर्च नहीं उठा सकते

• LLM द्वारा लिखा code कई बार tests पास कर लेता है, लेकिन requirements पूरी नहीं करता
  उदाहरण के लिए, हर query पर fsync कॉल करना, या primary key की गलत पहचान करना
  ऐसे बड़े projects में code इतना ज़्यादा होता है कि इंसान के लिए सब पढ़ पाना मुश्किल है
  इसलिए LLM autocomplete स्तर पर इस्तेमाल हो तो सबसे प्रभावी है
  छोटे code snippets को तुरंत review किया जा सकता है, और Claude आम तौर पर काफ़ी सही होता है
  लेकिन अगर पूरे codebase की ज़िम्मेदारी दे दी जाए, तो planning और management में ज़्यादा समय लगता है और maintenance भी कठिन हो जाती है
  अंततः speed का लाभ तभी है जब training data में पहले से मौजूद code को दोबारा पैदा किया जा रहा हो

• LLM सांख्यिकीय रूप से सबसे आम code patterns बनाता है
  इसलिए अगर कोई ख़ास निर्देश न हो, तो “enterprise-जैसा, OOP-आधारित, और ढेर सारी trendy dependencies इंस्टॉल करने वाला code” निकलता है

• “सही” को परिभाषित और मापा जाना चाहिए
  automation के लिए intent और measurement दोनों चाहिए
  risk range को समझना होगा, तभी पता चलेगा कि पहले से कितना cover करना है
  AI evals या eval-ception जैसे tools
  अगर roles के बीच common language के रूप में विकसित हों, तो collaboration बहुत आसान हो जाएगा

• LLM का मूल स्वभाव ही सबसे plausible code उत्पन्न करने के लिए डिज़ाइन किया गया है
  यह cross entropy loss का परिणाम है, और RLVR जैसी post-processing से accuracy बढ़ाने की कोशिश की जाती है
  फिर भी बहुत-सा अवशेष बाकी है
  आगे चलकर reward engineering विकसित हुआ, तो बेहतर परिणाम आने की संभावना है

• “इसमें इंसान से अलग क्या है?” इस सवाल पर

  • इंसान के पास goal-directed executive function होती है
    नींद में यह function बंद हो जाती है, इसलिए सपनों जैसी अतार्किक सोच आती है; LLM की सोच भी कुछ वैसी ही dream logic के स्तर की है
  • आज के development environment में हैरान करने वाली चीज़ है technical debt का acceleration
    पहले तकनीक को पूरी तरह न समझ पाने की चिंता रहती थी, लेकिन अब tools उस चिंता को ढक देते हैं
    गहरी समझ के बिना भी output निकालने का दौर आ गया है
  • LLM आखिरकार इंटरनेट का औसत निकालने वाली चीज़ है
    लेकिन लोग objective और सही जवाब देने वाले AI की उम्मीद करते हैं
    यही अंतर सामान्य users और experts की समझ में फ़र्क पैदा करता है
  • कम गुणवत्ता वाले कर्मचारी को निकालना आसान है, लेकिन Claude को निकालने के लिए मनाना मुश्किल है
  • समस्या scale की है
    कुछ लोग हर दिन हज़ारों lines वाले PR भेजते हैं
    उनमें से ज़्यादातर बिखरे हुए होते हैं, इसलिए review संभव नहीं होता
    पहले ऐसा PR बनाने में एक हफ़्ता लगता, अब वह एक दिन में बरसने लगता है

• “LLM” शब्द को लेकर भी बहुत सवाल हैं
  raw API से सीधे बुलाया गया model LLM है, और Claude.ai या ChatGPT जैसी चीज़ें उसके ऊपर चढ़ाया गया harness हैं
  ऐसे harness में prompt templates, conversation state management जैसी कई क्षमताएँ शामिल होती हैं
  अंततः हम लगभग हमेशा सिर्फ LLM से बढ़कर कुछ इस्तेमाल कर रहे होते हैं

  • मैं code execution करने वाले harness को “coding agent” कहता हूँ
    ऐसे agent code चला सकते हैं, ख़ुद tests कर सकते हैं और ख़ुद सुधार भी कर सकते हैं
    ChatGPT और Claude में भी यह क्षमता है, इसलिए वे वास्तव में coding agent हैं
  • संक्षेप में
    • LLM = model स्वयं (stateless, केवल text input/output)
    • LLM + system prompt + conversation history = chatbot
    • LLM + tools + memory + orchestration = agent
      इसलिए “LLM की memory नहीं होती” जैसी बात सिर्फ model पर लागू होती है
      Claude Code और Cursor state बनाए रखने वाले agentic system हैं

• इस लेख का शीर्षक दिलचस्प है, लेकिन यह कहना ग़लत है कि LLM “plausible code” लिखता है
  वास्तव में वह सिर्फ training data में देखे गए code clusters जैसे code उत्पन्न करता है
  RLHF या RLVR से सीमित न किए गए क्षेत्रों में ही वह अपेक्षाकृत स्वतंत्र रूप से generate करता है

  • training data का अधिकांश हिस्सा Python है, उसके बाद web technologies आती हैं
    इसलिए पूरी industry एक ही language में बात करती दिखती है, लेकिन यही उल्टा गलतफ़हमी का कारण भी बनता है
    इससे सबको लगता है कि वे एक ही समस्या हल कर रहे हैं
  • जब model out-of-distribution क्षेत्र में जाता है, तो वह hallucination करता है
    उदाहरण के लिए, अगर tree-sitter query माँगी जाए तो वह अस्तित्व में ही न होने वाले directives बना देता है
  • फिर भी “plausible” शब्द उपयुक्त अभिव्यक्ति है
    ज़रूरी नहीं कि उसके जटिल अंदरूनी ढाँचे को विस्तार से समझाया जाए

• हाल ही में Codex से Datastar-आधारित UI component बनवाने की कोशिश की, और वह पूरी तरह विफल रहा
  काम सरल था, लेकिन हर retry के साथ inline JavaScript और backend code लगातार बढ़ता गया
  उसने पुराना code साफ़ भी नहीं किया
  जटिल कामों में अच्छा होते हुए भी, वह बुनियादी tasks में गैर-स्वाभाविक विफलता दिखाता है