8 साल की चाह, 3 महीने में पूरा — AI ने साइड प्रोजेक्ट का फ़ॉर्मूला कैसे बदल दिया

 (lalitm.com)
27 पॉइंट द्वारा GN⁺ 2026-04-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लंबे समय से कमी महसूस हो रही SQLite के लिए high-quality development tools को AI की मदद से कम समय में पूरा किया गया
  • आधिकारिक grammar spec की अनुपस्थिति और जटिल C codebase के कारण parser बनाना सबसे बड़ी चुनौती थी
  • Claude Code जैसे AI coding agents का उपयोग कर शुरुआती implementation तेज़ी से आगे बढ़ी, लेकिन spaghetti code की समस्या के कारण Rust-आधारित rewrite करना पड़ा
  • AI ने code generation·refactoring·learning support·UX improvement में बड़ी दक्षता दिखाई, लेकिन design delay·code disconnect·dependency addiction जैसे दुष्प्रभाव भी सामने आए
  • निष्कर्षतः AI केवल implementation speed बढ़ाने का tool है, design और software की direction की ज़िम्मेदारी इंसान को ही लेनी चाहिए

AI के साथ SQLite development tool बनाने के 3 महीनों का रिकॉर्ड

  • लंबे समय से SQLite के लिए high-quality development tools की इच्छा थी, लेकिन मौजूदा open source tools reliability, speed और flexibility के मामले में कमज़ोर थे
    • PerfettoSQL को maintain करते समय formatter, linter, editor extension जैसी सुविधाओं की ज़रूरत थी, लेकिन उपयुक्त tools नहीं थे
    • निजी प्रोजेक्ट के रूप में नया tool बनाना चाहते थे, लेकिन कठिनाई और दोहराए जाने वाले काम के बोझ के कारण यह कई वर्षों तक टलता रहा

प्रोजेक्ट की कठिनाइयाँ

  • SQLite में आधिकारिक grammar spec या स्थिर parser API नहीं है
    • यह अंदरूनी तौर पर parse tree नहीं बनाता, इसलिए source code से सीधे parser logic निकालना पड़ा
    • 400 से अधिक grammar rules को एक-एक करके map करना पड़ता है, और test लिखना व debugging बहुत दोहरावदार और थकाऊ काम है
  • SQLite का C codebase जटिल और अत्यंत सघन है, इसलिए उसे समझना कठिन है
    • virtual table API और implementation को समझने में ही कई दिन लग गए; इसकी संरचना काफ़ी दुरूह थी

AI के साथ development process

  • 2025 के अंत से Claude Code जैसे AI coding agents का गंभीरता से उपयोग शुरू किया गया
    • शुरुआत में AI को ज़्यादातर design और implementation सौंपकर “vibe-coding” शैली में काम किया गया
    • नतीजा काम तो करता था, लेकिन codebase spaghetti जैसी संरचना में उलझ गई और maintain करना लगभग असंभव हो गया
  • इसके बाद पूरे सिस्टम को Rust में rewrite करते हुए संरचना को फिर से बनाया गया
    • C की जगह Rust का उपयोग कर ऊपरी स्तर के components, जैसे validator और language server, बनाना आसान हुआ
    • AI को “autocomplete को मज़बूत करने वाले tool” तक सीमित किया गया, और design, review व testing को सीधे खुद lead किया गया
    • linting, validation, test automation आदि जैसे AI output को verify करने के लिए scaffolding तैयार की गई

AI ने क्या संभव बनाया

  • जड़ता पर काबू

    • AI ने काम को ठोस problem units में तोड़कर शुरुआत आसान बना दी
    • “SQLite parsing को समझना है” से “AI द्वारा सुझाए गए approach की review करनी है” में बदलाव आया, जिससे execution speed बढ़ी

  • code generation और refactoring की गति

    • जब requirements स्पष्ट हों, तो AI standard और consistent code बहुत तेज़ी से लिख देता है
    • लेकिन non-standard design, जैसे parser structure, में यह उल्टा बाधा बन सकता है, इसलिए वहाँ सीधे खुद लिखना ज़रूरी था
    • बड़े पैमाने पर code generation के बाद लगातार refactoring अनिवार्य है, और इसी से quality बनी रहती है

  • learning assistant की भूमिका

    • AI ने Wadler-Lindig formatting algorithm जैसे नए concepts को real time में समझाया
    • Rust, VS Code extensions जैसे कम परिचित क्षेत्रों में भी तेज़ी से entry मिल सकी
    • जब project context खो जाता था, तब “इस component को समझाओ” जैसे सवालों से तुरंत context restore हो जाता था

  • पूर्णता में सुधार

    • editor extension, Python bindings, WASM playground, documentation site जैसी अतिरिक्त सुविधाओं की development cost कम हुई
    • implementation का बोझ घटने से UX improvement पर अधिक ध्यान दिया जा सका, जैसे error messages और CLI design के ज़रिए user experience को बेहतर बनाना

AI उपयोग के दुष्प्रभाव

  • लत जैसी प्रवृत्ति

    • “बस एक prompt और” को दोहराने वाली slot machine जैसी reward structure
    • जितनी अधिक थकान, उतनी ही prompt quality गिरती है, नतीजे और खराब होते हैं, और एक दुष्चक्र बन जाता है

  • codebase से disconnect

    • AI द्वारा generated code जितना बढ़ता है, बारीक संरचना की समझ उतनी कम होती जाती है
    • context खोने पर AI के साथ बातचीत भी लंबी और कम प्रभावी हो जाती है
    • समाधान के तौर पर generated code बनने के तुरंत बाद उसे खुद पढ़ने और “मैं इसे कहाँ अलग तरह से लिखता” यह जाँचने की आदत डाली गई

  • design delay और क्षरण

    • refactoring आसान होने से core design decisions को टालने की प्रवृत्ति पैदा हुई
    • tests बहुत हों तब भी मूलभूत design errors को छिपाना मुश्किल होता है, और अंततः पूरे rewrite की ज़रूरत पड़ सकती है

  • समय-बोध का अभाव

    • AI code के temporal context या evolution process को नहीं समझता
    • इससे पुरानी गलतियाँ दोहराने या पहले से सुलझी समस्याओं को फिर से खंगालने जैसी अक्षमताएँ पैदा होती हैं
    • documentation से कुछ हद तक इसकी भरपाई हो सकती है, लेकिन design intent को पूरी तरह रिकॉर्ड करना कठिन है

AI उपयोग की सापेक्षता

  • जिन क्षेत्रों को गहराई से समझा गया हो, वहाँ AI शानदार साबित होता है; तेज़ review और iteration संभव होते हैं
    • उदाहरण: parser rules generation, जहाँ अपेक्षाकृत स्पष्ट सही उत्तर होता है
  • आंशिक रूप से परिचित क्षेत्रों में यह learning tool के रूप में उपयोगी है, लेकिन लगातार सतर्कता ज़रूरी है
    • उदाहरण: formatter algorithm सीखना
  • जब यह भी स्पष्ट न हो कि क्या बनाना है, तब AI उल्टा नुकसानदेह हो सकता है
    • उदाहरण: architecture design phase में unproductive loops बनना
  • verifiable problems जैसे compile होना या tests pass करना, इनमें AI मज़बूत है, लेकिन
    design और API quality जैसे बिना निश्चित उत्तर वाले सवालों में यह कमज़ोर पड़ता है

निष्कर्ष

  • 8 साल से सोचे जा रहे SQLite tool को सिर्फ 3 महीनों में साकार किया जा सका, और इसका बड़ा कारण AI था
    • लेकिन यह सफ़र कोई साधारण success story नहीं था; इसके साथ AI पर निर्भरता की सीमाएँ और उसकी कीमत भी जुड़ी हुई थीं
  • AI implementation को तेज़ करने वाला accelerator है, लेकिन design का विकल्प नहीं
    • यह technical questions के जवाब सटीक दे सकता है, लेकिन इतिहास, रुचि और user intuition की उसमें कमी होती है
  • असली सबक यह है कि AI की मदद से भले ही हम दीवार से जल्दी टकराएँ,
    design की दिशा और ‘software की आत्मा’ की ज़िम्मेदारी इंसान को ही लेनी होगी
  • आगे ज़रूरत है ऐसे प्रोजेक्ट अनुभव साझा करने की जो असली users और maintenance की कसौटी पर टिकें
    • यानी केवल experiments नहीं, बल्कि व्यावहारिक और टिकाऊ AI-collaborative development अनुभवों का संचय

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

1 टिप्पणियां

 
GN⁺ 2026-04-06
Hacker News की राय

  • AI coding पर संतुलित नज़रिया देखना ताज़गीभरा लगा
    ज़्यादातर गंभीर developers के लिए यह बहुत relatable अनुभव है — शुरुआत में AI के code अच्छी तरह लिख देने पर हैरानी होती है, लेकिन बाद में पता चलता है कि codebase spaghetti code बनकर बिखर गया है
    कुछ लोग code review किए बिना ही कहते हैं कि “अब manual coding खत्म हो गई”, और कुछ दूसरे सीधे मान लेते हैं कि “AI coding बेकार है”
    लेकिन हक़ीक़त इन दोनों के बीच कहीं है। AI एक बड़ा productivity accelerator बन सकता है, लेकिन उसे workflow में सही तरह से शामिल करना होगा और इंसानों की लगातार भागीदारी ज़रूरी है

    • मैं भी पिछले 3 महीनों से Claude को अपने मुख्य coding interface के रूप में इस्तेमाल कर रहा हूँ
      शुरुआत में यह एक prototype था, लेकिन जल्दी ही असली service में बदल गया। बाद में refactoring करते समय बेकार code हटाने में काफ़ी मेहनत लगी
      फिर भी उसी तेज़ prototype की वजह से आज का product मौजूद है। Claude code साफ़ करने में मानो chainsaw जैसा उपयोगी रहा
      हाल ही में मैंने pre-commit hook के साथ type checker जोड़ा और 90 errors को सिर्फ़ 2 घंटे में ठीक किया।
      AI coding कमाल की है, लेकिन production code में अब भी इंसानी review और judgment अनिवार्य हैं
    • यह लेख ख़ास तौर पर इसलिए अच्छा लगा क्योंकि इसमें संतुलित दृष्टिकोण है
      हालांकि यह case एक व्यक्ति का greenfield project है, इसलिए इसे सामान्य team development पर सीधे लागू करना मुश्किल है
      फिर भी अगर prototype को ‘फेंक देने’ की सोच के साथ बनाया जाए, तो spaghetti code भी स्वीकार्य हो सकता है।
      समस्या यह थी कि लेखक ने शायद समझ लिया कि इसे सीधे असली product में बदला जा सकता है।
      लेकिन संभव है कि उसी असफलता से उसने बेहतर design सीखा हो
    • सच कहूँ तो ऐसी अतिवादी प्रतिक्रियाएँ AI coding से पहली बार गुजरने वाले हर व्यक्ति का एक चरण लगती हैं
      पहले हैरानी, फिर निराशा, और अंत में संतुलन।
      यह कुछ-कुछ AI version of the Kübler-Ross model जैसा लगता है
    • उल्टा, मुझे लगता है कि code quality के प्रति अत्यधिक जुनून AI युग का blind spot है
      गुणवत्ता ज़रूरी है, लेकिन अब code quality अपने आप में कुछ कम महत्वपूर्ण होती जा रही है
      personal apps जैसे ऐसे code बढ़ रहे हैं जिन्हें maintenance की ज़रूरत नहीं होती, और AI की design क्षमता भी तेज़ी से बेहतर हो रही है
      आखिरकार “AI coding की सच्चाई” लगातार बदल रही है, और यह प्रवाह रुकने वाला नहीं है
    • मुझे लगता है कि इस तरह के यथार्थवादी लेख कम दिखने के दो कारण हैं
      पहला, ज़्यादातर developers चुपचाप 2~50% productivity increase का फ़ायदा ले रहे हैं और उसे लेकर शोर नहीं मचाते
      दूसरा, असली AI coding उबाऊ होती है और visually प्रभावशाली नहीं दिखती।
      आखिर LLM बस ऐसा tool है जिससे ‘boilerplate याद रखने की ज़रूरत नहीं पड़ती’, coding का मूल स्वभाव वही रहता है

  • AI से test generation में मुझे भी वही समस्या हुई
    tests ज़्यादा होने पर भरोसा बढ़ता है, लेकिन असल में वे edge cases को संभाल नहीं पाते
    खासकर बिना tests वाले legacy code को refactor करते समय AI द्वारा बनाए गए tests सिर्फ़ इतना देखते हैं कि चीज़ें चल रही हैं या नहीं, लेकिन behavioral consistency की गारंटी नहीं देते
    React app में यह समस्या बहुत गंभीर थी। इसलिए मैं BDD + specification-driven development को AI के साथ जोड़ने के तरीके पर विचार कर रहा हूँ

    • अच्छा test लिखना, असली coding से भी 10 गुना कठिन लगता है
      unit tests में creative mock design, integration tests में data manipulation, और e2e tests में selector stability सबसे अहम है
      इस तरह के रचनात्मक फैसलों तक पहुँचना अभी AI के लिए आसान नहीं है
    • coverage के आँकड़ों से धोखा नहीं खाना चाहिए
      97% coverage होने पर भी logical input space में बहुत से छेद थे।
      हाल में मैंने equivalence partitioning जैसी पारंपरिक तकनीकों को AI agent के ज़रिए automate करके 60 models पर लागू किया
    • TLA+ से system behavior को specify करने, और code को spec से जोड़ने वाला approach recommend करता हूँ
      मुख्य बात यह है कि pure functions को जितना हो सके अलग किया जाए और input-output mapping को पूरी तरह test किया जाए

  • लंबी अवधि में मुझे लगता है कि AI की असली value समझ बढ़ाने वाले tool के रूप में है
    उदाहरण के लिए, जटिल C code के नियमों का विश्लेषण करके उसकी संरचना को document करना
    अगर इस तरह का knowledge extraction संभव हो जाए, तो API docs, rule mapping, bug analysis, और architecture optimization तक automate किए जा सकते हैं
    आखिर code generate करने से भी ज़्यादा महत्वपूर्ण context को संरचित करने की क्षमता हो जाएगी

    • हर व्यक्ति AI का उपयोग बिल्कुल अलग तरीके से करता है
      ① सिर्फ़ requirements देकर पूरा app बनवा लेने वाला सर्वज्ञ oracle मॉडल
      ② IDE के अंदर हर लाइन देखते हुए इस्तेमाल करने वाला assistant tool मॉडल
      टिकाऊ service बनानी हो तो ② वाला तरीका कहीं ज़्यादा व्यावहारिक है

  • “Architecture तब बनती है जब local pieces एक-दूसरे के साथ interact करते हैं” यह बात बहुत प्रभावशाली लगी
    AI local execution में मज़बूत है, लेकिन ambiguous design phase में कमज़ोर
    दरअसल इंसानी developers के साथ भी यही सच है। Design लगातार trade-offs की ऐसी श्रृंखला है जिसमें एक ही सही जवाब नहीं होता

    • मैं भी AI के साथ लंबी बातचीत के बाद design निष्कर्ष तक पहुँचा हूँ
      खास तौर पर ClickHouse SQL design में बहुत मदद मिली
      AI द्वारा सुझाए गए template-based SQL inclusion approach की वजह से duplication कम हुआ और performance भी बेहतर हुई
      यह approach शायद पहले से मौजूद रही हो, लेकिन AI के बिना इसे ढूँढना कठिन होता

  • यह लेख भरोसेमंद इसलिए लगता है क्योंकि इसमें 250 घंटे की वास्तविक मेहनत लगी है
    मुझे लगता है कि इस पैमाने का project ही असली AI-assisted systems programming का व्यावहारिक मॉडल है

  • “AI coding slot machine जैसी है” यह बात बेहद relatable लगी
    मुझे भी कंपनी में unlimited AI agent access मिला हुआ है, और “बस एक prompt और” करते-करते
    पता ही नहीं चलता कि 12 घंटे निकल गए। इसमें गहरे डूब जाने वाली लत है

  • शायद अभी का समय AI coding के लिए सबसे कठिन दौर है
    6 महीने पहले जिन चीज़ों की कल्पना भी नहीं थी, वे अब संभव हो चुकी हैं
    मैं कई भाषाओं में projects चला रहा हूँ, और AI code इतनी तेज़ी से बना देता है
    कि अब review speed ही bottleneck बन गई है
    कुछ tests pass हो जाने के बाद सवाल उठता है, “क्या यह काफ़ी है?”
    मैं prompts में SOLID principles, coupling, cohesion जैसी quality attributes को साफ़ लिखता हूँ
    AI से refactoring ideas पूछता हूँ, और अगर ठीक लगे तो कह देता हूँ, “ठीक है, इसे लागू करो”
    आखिरकार सबसे महत्वपूर्ण चीज़ prompt design की कला है
    लेकिन मुझे लगता है कि बहुत जल्द AI ऐसे quality guardrails को default रूप से संभालने लगेगा

    • यह सवाल भी आया कि कई भाषाओं में project क्यों कर रहा हूँ
      भाषा अपने आप में performance bottleneck नहीं है, लेकिन नई languages के साथ प्रयोग सीखने में मदद करते हैं

  • Fred Brooks का “एक को फेंक दो” दर्शन याद आ गया
    AI उस पहले version यानी throwaway को तेज़ी से बनाने के लिए सबसे उपयुक्त है
    सीधे production quality की उम्मीद करना मूर्खतापूर्ण approach है
    जल्दी बनाओ, सीखो, फिर refactor करो — यही सही तरीका है
    थकान होने पर prompts अस्पष्ट हो जाते हैं और नतीजे भी खराब आते हैं, इस बात से भी सहमति है

    • लेकिन यह भी दिलचस्प है कि बाद में Brooks ने iterative refinement की ओर अपना रुख बदल लिया था

  • यह जानकर हैरानी हुई कि SQLite का SQL parser lemon से generate नहीं किया गया था
    जब मैंने pikchr को Go में port किया था, तो पहले lemon को port किया, लेकिन SQLite parser tree तक नहीं बनाता
    lemon dastavez ko dekhne par, yah design charan mein samasya ki paribhasha ki kami jaisa lagta hai

  • मैं भी इस लेख के निष्कर्ष से पूरी तरह सहमत हूँ
    यह AI coding की वास्तविकता को बिना बढ़ा-चढ़ाकर, ईमानदारी से दिखाने वाला अच्छा उदाहरण है