nokode - अगर LLM सब कुछ कर सकता है, तो फिर कोड क्यों लिखें? (वेबऐप प्रयोग)

• बिना किसी application logic वाला web server बनाकर यह प्रयोग किया गया कि LLM हर request को संभाले
  • server बस HTTP request लेकर LLM से “क्या करना है?” पूछता है, और बाकी सब LLM करता है
• server database, webResponse, updateMemory इन तीन tools का ही उपयोग करके CRUD फ़ंक्शन करता है
• LLM ने SQL schema design, HTML·JSON generation, feedback लागू करना तक खुद किया और एक बुनियादी contact management app बनाया
• response speed 30~60 सेकंड रही, लागत पारंपरिक webapp की तुलना में 100~1000 गुना अधिक रही, और UI consistency व memory से जुड़ी समस्याएँ थीं
• इसके बावजूद इसने बिना कोड के चलने वाला पूरा CRUD app बन सकने की संभावना दिखाई, जिससे यह संकेत मिलता है कि code स्वयं एक transitional concept हो सकता है

---

पृष्ठभूमि

• इसकी शुरुआत इस कल्पनात्मक विचार (Shower Thought) से हुई कि “एक दिन हमें code लिखने की ज़रूरत नहीं रहेगी”
  • भविष्य में LLM real-time input संभालेंगे और 120fps video output करेंगे, और app या code के बिना सिर्फ़ intent-based computing संभव हो सकती है
• अभी यह वास्तविकता से अधिक science fiction जैसा है, लेकिन सप्ताहांत में प्रयोग के तौर पर यह सीधे परखा गया कि “आज की तकनीक से हम कितनी दूर तक जा सकते हैं”
• प्रयोग की hypothesis शुरू से ही संभावित विफलता मानकर बनाई गई थी
  • जबकि ज़्यादातर AI code generation की दिशा में केंद्रित हैं, जैसे Claude Code, Cursor, Copilot आदि,
    इस project ने एक अलग सवाल जाँचा: “अगर code generation को पूरी तरह छोड़ दें तो?”
• नतीजे में routes, controllers, business logic के बिना एक HTTP server बनाया गया, जो हर request पर LLM से “क्या करना है?” पूछकर काम करता है
• प्रयोग का उद्देश्य यह साबित करना था कि “वह भविष्य वास्तव में कितना दूर है”

project का अवलोकन

• nokode एक ऐसा प्रयोग है जिसमें “application logic के बिना web server” बनाकर यह परखा गया कि हर request को LLM से संभलवाया जा सकता है या नहीं
  • server बस HTTP request लेकर LLM से “क्या करना है?” पूछता है, और बाकी सब LLM करता है
• लक्ष्य यह सत्यापित करना था कि code generation के बिना LLM सीधे application logic चला सकता है या नहीं
• प्रयोग के लिए contact manager app चुना गया, जिसमें बुनियादी CRUD फ़ंक्शन यानी create, read, update, delete शामिल हैं

system संरचना

• backend सिर्फ़ 3 tools से बना है
  • database: SQLite में SQL चलाना; schema LLM खुद design करता है
  • webResponse: HTML, JavaScript, JSON आदि उचित format में response बनाना
  • updateMemory: user feedback को Markdown में सहेजना ताकि अगली request में उसे देखा जा सके
• उदाहरण के लिए /contacts request पर HTML page, और /api/contacts request पर JSON response बनाया जाता है
• हर page में feedback widget शामिल है, जो “button बड़ा कर दो”, “dark theme में बदल दो” जैसी requests को तुरंत लागू करता है

प्रयोग के परिणाम

• फ़ंक्शनल तौर पर यह सफल रहा
  • form submission, data storage, UI display, API response — सब ठीक से काम किया
  • LLM ने बिना किसी उदाहरण के उपयुक्त database schema, सुरक्षित SQL, REST-style API, responsive layout, form validation, error handling तैयार किया
• performance समस्याएँ
  • हर request में 30~60 सेकंड लगे, जो सामान्य webapp (10~100ms) की तुलना में 300~6000 गुना धीमा है
  • हर request पर $0.01~0.05 लागत आई, यानी 100~1000 गुना महँगा
  • UI में रंग और layout की असंगति, पिछली state याद न रख पाना, और गलत SQL बनने पर तुरंत error जैसी समस्याएँ रहीं
  • “⚡ THINK QUICKLY” जैसे prompt optimization प्रयासों से उल्टा गति और कम हुई

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

• LLM में application logic सीधे चलाने की क्षमता मौजूद है
• समस्या speed, cost, consistency, reliability जैसी performance सीमाओं की है
• लेकिन ये सीमाएँ गुणात्मक बाधा से ज़्यादा मात्रात्मक सुधार का क्षेत्र लगती हैं
  • inference speed हर साल लगभग 10 गुना बेहतर हो रही है
  • लागत घट रही है
  • context length बढ़ने से memory में सुधार संभव है
  • error rate कम होने की प्रवृत्ति है
• नतीजतन, “AI code लिखने का युग” से अधिक “AI खुद execute करने का युग” शायद ज़्यादा निकट हो सकता है
• अभी जो code बचता है, वह HTTP setup, tool definition, DB connection जैसे infrastructure-level code तक सीमित है,
  और लंबी अवधि में “सिर्फ़ intent और execution वाली computing” की ओर बदलाव की संभावना दिखती है

चलाने का तरीका

• npm install के बाद .env फ़ाइल में LLM provider और API key सेट करें
• npm start चलाकर http://localhost:3001 खोलें (पहली request में 30~60 सेकंड लग सकते हैं)
• prompt.md बदलकर app का प्रकार या फ़ीचर बदला जा सकता है
  • /game, /dashboard, /api/stats जैसे अलग-अलग routes आज़माए जा सकते हैं
  • “make this purple”, “add a search box” जैसी feedback input देकर तुरंत बदलाव किया जा सकता है
• प्रति request लागत model के अनुसार $0.001~0.05 तक हो सकती है
• MIT license के तहत जारी

[aer0700]

मुद्दा शायद यह है कि computing कहाँ तक तेज़ और सस्ता हो सकता है।
अगर भविष्य में औसत server आज की तुलना में 1 लाख गुना तेज़ हो जाए, और फिर भी operating cost या installation cost वैसी ही रहे, तो वह भी शायद एक सही तरीका होगा।
जैसे computing सस्ता होने के साथ machine language से C पर आए, और C की जगह Node.js या Python पर आए, वैसे ही आगे चलकर शायद LLM की ओर भी बढ़ें।
बहुत कुछ बदलेगा, और अपने तरीके से काफ़ी दिलचस्प भी होगा। कई मौके भी पैदा होंगे।

[GN⁺]

Hacker News राय

• मैं भी कुछ समय से ऐसा ही सोच रहा था

  1. अगर code generation पूरी तरह automated हो जाए और हर Google search real-time में custom page बना दे, तो क्या फिर इंसानों को वेबसाइट बनाने की ज़रूरत ही नहीं रहेगी? उस बिंदु पर ‘web development’ coding से ज़्यादा intent-shaping जैसा हो जाएगा
  2. और मैं इस दावे से सहमत नहीं हूँ कि chat ही user interface का आदर्श रूप है। Natural language लचीली है, लेकिन धीमी, अस्पष्ट और cognitively demanding भी है। शायद LLM-आधारित systems को conversation और structured interaction को मिलाने वाला नया UI model चाहिए होगा

• जब ChatGPT 3.5 आया था, तब मैंने यह बात पहली बार सोची थी
  कभी न कभी AI शायद programs को पूरी तरह replace कर दे, लेकिन असली बात सही abstraction ढूँढने की है
  उदाहरण के लिए, जैसे CVS से Git की तरफ़ बदलाव ने microservices के युग का रास्ता खोला, वैसे ही अच्छी abstraction समस्याओं को जड़ से बदलने की ताकत रखती है
  LLM अगर ऐसी abstraction खुद खोजे, तो उसे लंबे समय तक real world के साथ interact करते हुए सीखना होगा

• अगर LLM को सीधे code files modify करने वाले tools दे दिए जाएँ, तो response speed और consistency काफ़ी बेहतर हो सकती है
  इस तरह code एक तरह के memory store की भूमिका निभाएगा
  LLM को सीधे HTTP request भेजना cache miss जैसा है, और code update trigger करने वाला feedback mechanism भी बनाए रखा जा सकता है

  • यह बस एक simple experiment था, और मकसद यह दिखाना था कि अभी भी कई bottlenecks हैं
    optimization की बहुत गुंजाइश है, लेकिन व्यावहारिक रूप से अभी भी traditional coding ज़्यादा efficient लगती है
  • यह architecture कुछ-कुछ seed बोने जैसा है, जहाँ growth direction और boundaries तय की जाती हैं
  • इसे खुद बनाकर देखना अच्छा रहेगा

• यह कुछ ऐसा सुनाई देता है जैसे पूछा जाए, “अगर non-deterministic behavior संभव है तो फिर deterministic होने की ज़रूरत ही क्यों है?”
  लेकिन ज़्यादातर लोग शायद ऐसा webapp नहीं चाहेंगे जो हर बार अलग तरह से काम करे

  • असल में लोग “webapp” नहीं, बल्कि solution चाहते हैं
    deterministic code की complex problems संभालने में सीमाएँ हैं, और इंसानों जैसी flexible approach शायद ज़्यादा उपयुक्त हो
  • आज के LLM मुख्यतः text output तक सीमित हैं और long-term memory भी लगभग नहीं है
    लेकिन भविष्य में LLM के पास कहीं ज़्यादा समृद्ध output और storage capabilities होंगी
    उदाहरण के लिए, LLM खुद links generate करे, उन पर click होने पर internally फिर से query करे, या temporary database manage करे
  • मेरा मतलब यह नहीं है कि non-deterministic behavior अच्छा है, बल्कि यह दिखाना है कि आज और post-code युग के बीच कितना gap है
  • सच तो यह है कि आज का software भी पूरी तरह deterministic नहीं है
    auto updates, A/B tests, UX changes आदि के कारण user experience लगातार बदलता रहता है
  • temperature को 0 पर रखकर और LLM से settings local file में save करवाकर, deterministic app भी बनाया जा सकता है

• दिलचस्प बात यह है कि यह approach अलग tools के बिना सिर्फ context window से भी काम करती है
  2025 के जुलाई में मैंने एक POC बनाया था

• यह experiment अच्छी तरह दिखाता है कि “boilerplate code” की अवधारणा कैसे बदल सकती है
  अगर कई instances को sandbox में साथ-साथ चलाया जाए और internal evaluation के आधार पर सबसे अच्छा result दिया जाए, तो यह एक तरह का meta reinforcement learning बन जाता है
  लेकिन user intent को deterministic output में translate करना मुश्किल है, और दूसरी ओर traditional apps में flexibility की कमी होती है
  आख़िरकार असली सवाल यह है कि intent evaluation को reliably कैसे implement किया जाए

  • लेकिन यह जोखिम है कि model internal evaluation method पर overfit हो जाए
    अच्छी evaluation method बनाना अपने-आप में AI model बनाने जितना complex है

• traditional तरीक़े से requests process करना, LLM को सीधे इस्तेमाल करने की तुलना में, cost-efficient काफ़ी ज़्यादा है
  मोटे तौर पर 7 अरब parameter वाले model से 10 tokens generate करने में 100 GFLOPs से ज़्यादा लगते हैं
  बिजली की बर्बादी बहुत है

  • लेकिन क्या हमें human labor की energy cost भी calculation में शामिल नहीं करनी चाहिए?
    enterprise IT में काम करते हुए लगता है कि मानवीय inefficiency भी कम नहीं है
  • industry की दिशा हमेशा optimization से मेल नहीं खाती
    inefficiency भी trend बन जाती है, यही हक़ीक़त है
  • फिर भी LLM से जल्दी prototype (V1) बनाकर, product-market fit verify करने के बाद traditional code से optimize करना एक valid approach है

• शायद बस LLM को port 443 पर चढ़ाकर उससे कह देना चाहिए, “तुम एक HTTPS server और app server हो” ;)

• क्या webapp की ज़रूरत भी है? क्यों न बस आवाज़ से कंप्यूटर से बात की जाए?
  “पिछली छुट्टियों की तस्वीरें दिखाओ, बादल हटा दो, और दोस्त को भेज दो”
  “exercise timer set कर दो, jumping jacks हटा दो”
  “Detroit-style techno beat बना दो”
  “आज रात के लिए date ढूँढ दो, काले बाल पसंद हैं”
  मैं ऐसी दुनिया की कल्पना करता हूँ जहाँ सब कुछ बोलकर हो जाए

  • लेकिन ऐसी automation इंसानों की agency को कमज़ोर कर सकती है
    आख़िरकार मानवता शायद इसे अपनाने वालों और ठुकराने वालों में बँट जाएगी
    vinyl records की वापसी जैसे रुझानों में इसकी झलक पहले से दिखती है
  • voice interface हर communication का जवाब नहीं है
    इंसान आपस में भी कई बार text को प्राथमिकता देते हैं
  • मैंने भी इस हफ़्ते WebSpeech के साथ voice input लेकर org-mode और logseq files को पढ़ने और edit करने वाला एक personal knowledge management app बनाया
    उसमें todo, grocery, schedule management सब हो जाता है, और वह पूरी तरह मेरी ज़रूरत के हिसाब से customized है
  • ऐसे भविष्य की कल्पना science fiction में अक्सर की गई है
    complex tasks आवाज़ से अच्छी तरह व्यक्त हो सकते हैं, लेकिन simple repetitive कामों में UI ज़्यादा efficient रहता है
    उदाहरण के लिए, अगर आप कहें “मेरे लिए पैंट खरीदो”, तो 30 results में से एक चुनने के लिए आख़िरकार visual interface चाहिए होगा

• मैंने भी ऐसा ही एक PoC GitHub पर डाला है
  शुरुआत में एक धीमे ‘design model’ से app theme और DB schema बनाया, और उसके बाद एक तेज़ model से responses handle किए
  मैंने PostREST का इस्तेमाल करके logic को DB में डालने की कोशिश की, लेकिन schema generation fail होना या गलत queries बनना काफ़ी आम था
  CSS library से UI consistency बनाए रखी, और system को पिछला page याद रखने दिया
  ऐसी approach शायद App Bench की तरह इस्तेमाल की जा सकती है, यह परखने के लिए कि LLM एक बार में पूरा app बना सकता है या नहीं