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

 (blog.katanaquant.com)
25 पॉइंट द्वारा GN⁺ 2026-03-08 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • 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 परिभाषित करें, फिर उसे मापें।

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.