"Vibe Coding" बनाम वास्तविकता

• हाल ही में Andrej Karpathy की एक टिप्पणी चर्चा में रही: "Vibe के हवाले हो जाइए, exponential growth को स्वीकार कीजिए, और यह तक भूल जाइए कि code नाम की कोई चीज़ मौजूद है."
• "Vibe Coding" से मतलब उस प्रवृत्ति से है जिसमें बिना स्पष्ट योजना या खुद code लिखे, AI tools को problem-solving सौंप दी जाती है
• LLM (Large Language Model) agents के ज़रिए natural language में निर्देश देने पर code generate और modify किया जा सकता है
  • 2022: ChatGPT में code copy और modify करना संभव हुआ
  • 2023: IDE के साथ integrated Copilot में code review और modification संभव हुआ
  • 2024~2025: project की कई files को modify करना, और self-test व self-fix करना संभव हुआ

"Vibe Coding" कैसे काम करता है

• तकनीकी और गैर-तकनीकी, दोनों तरह के users LLM-आधारित agents के ज़रिए project setup कर सकते हैं
• साधारण निर्देशों से website या app बनाया जा सकता है (उदाहरण: "ski resort website बनाओ")
• शुरुआती setup के बाद automatic fixes और testing संभव है

• उदाहरण:

  • Cursor, GitHub Copilot Agent Mode आदि files edit कर सकते हैं और commands चला सकते हैं
  • auto-fix और testing करते हैं → लेकिन consistency की कमी से errors हो सकते हैं

agent की autonomy की समस्या

• agent अपने-आप काम कर सकते हैं, लेकिन वे पूरी तरह autonomous नहीं हैं
• user approval के बिना execution होने पर जोखिम पैदा हो सकता है (जैसे YOLO mode में command execution)
• code quality और accuracy से जुड़ी समस्याएँ हो सकती हैं

• मुख्य समस्याएँ:

  • existing code reuse करने में विफलता → एक ही component बार-बार बन जाना
  • client side पर server-side logic चलाने की कोशिश
  • गलत code fix करने के बाद errors पैदा होना → बाद में fix करने में विफलता
  • unit tests लिखने में विफलता या code टूट जाना

वास्तविक सीमाएँ

• Claude 3.7 Sonnet जैसे models training data की सीमाओं से बाहर नहीं जा पाते
• codebase में context खो देने पर consistent modifications संभव नहीं रहते
• code का आकार बढ़ने पर performance गिरती है और context बनाए रखना मुश्किल हो जाता है
• LLM की context window size पार होने पर consistency की समस्या आती है

• ठोस समस्या उदाहरण:

  • TypeScript interfaces की duplication
  • client में server logic चलाना
  • duplicate components को fix करने में विफलता
  • unit tests लिखने में विफलता
  • code refactoring के बाद errors fix करने में विफलता

समस्या हल करने के प्रयास

• Claude Plays Pokémon: agent real-time interaction के साथ game खेलता है
• memory बनाए रखने और बार-बार होने वाली errors को ठीक करने में विफलता
• long-term memory बनाने में विफलता → लगातार errors होती रहती हैं

• सुधार की संभावनाएँ:

  • MCP(Model Context Protocol) और memory management में सुधार की ज़रूरत
  • code modify करते समय LLM को अपने पिछले बदलावों को सही तरह reflect करना चाहिए
  • domain-specific memory और work history को सुरक्षित रखना ज़रूरी है

निष्कर्ष

• "Vibe Coding" functional concepts को implement करने में 80% तक पहुँच सकता है, लेकिन भरोसेमंद और सुरक्षित product बनाने के लिए अनुभवी इंसानी मेहनत की ज़रूरत होती है
• AI agents कुशल लोगों को स्वतंत्र रूप से और अधिक चीज़ें बनाने में सक्षम बनाते हैं, लेकिन वे उन लोगों की जगह नहीं ले सकते जो अनुभव और intuition से कठिन समस्याएँ हल करते हैं
• मौजूदा स्तर पर "Vibe Coding" से वास्तव में उपयोगी products तक पहुँचना मुश्किल है, और skilled developers की मदद अनिवार्य है
• "Vibe Coding" code लिखने का केवल एक सहायक साधन है, पूरी तरह का विकल्प नहीं

[nicewook]

"वर्तमान स्तर" वाले हिस्से पर नज़र जाती है। क्या हम LLM को इंसानी समय की अवधारणा से देख रहे हैं?

[ng0301]

AI के साथ coding करते समय मुझे यह महसूस हुआ कि, अगर code का सिर्फ़ एक हिस्सा भी AI को दिया जाए, तो वह context समझ सके—इसके लिए Single Responsibility Principle + TDD जैसी unit-level splitting करते-करते यह ज़रूरी हो जाता है कि उसे इतना अच्छी तरह structured किया जाए कि बड़े context को पढ़ने की ज़रूरत न पड़े, और सिर्फ़ हिस्से के context से भी वह काफ़ी कुछ समझ ले।

[ifmkl]

मैं AI का सबसे ज़्यादा इस्तेमाल अपने शौक के तौर पर web game बनाने में करता हूँ, और मैं इससे सहमत हूँ। जब प्रोजेक्ट एक निश्चित स्तर से बड़ा हो जाता है, तो किसी बिंदु पर AI की, कहें तो, फोकस बनाए रखने की क्षमता काफ़ी कम होती हुई दिखती है। मैं इसका इस्तेमाल इस तरह करता हूँ: गेम के पूरे tree और source code को TOC सहित एक ही फ़ाइल में जोड़ देता हूँ, फिर एक नया thread बनाकर वह फ़ाइल अपलोड करता हूँ और काम आगे बढ़ाता हूँ। और जब भी सवाल पूछता हूँ, तो हमेशा मौजूदा project का नाम साफ़-साफ़ और स्पष्ट रूप से बताकर जवाब माँगता हूँ। इसके बावजूद अब भी कुछ हिस्से असंतोषजनक हैं, लेकिन... अतीत में real life की व्यस्तता के कारण जिन शौकिया कामों की शुरुआत करने की भी हिम्मत नहीं होती थी, उन्हें अब अपेक्षाकृत कम समय में पूरा कर पा रहा हूँ—इस बात से मैं बहुत संतुष्ट हूँ।

[pcj9024]

लगभग बनाकर बाकी details को बाद में ठीक करने वाला पैटर्न मुझे सच में पसंद है।

[psguny9]

कई तरह के प्रयास हो रहे हैं, लेकिन मेमोरी की सीमाएँ साफ़ हैं। PoC स्तर पर यह अच्छा है। तेज़ी से संभावना/उपयोगिता परखने के लिहाज़ से भी अच्छा है.

समस्या यह है कि तब भी, बल्कि और भी ज़्यादा, एक अनुभवी व्यक्ति की ज़रूरत होती है.

[colus001]

अगर मानें कि coding में ज़्यादातर समय debugging और code पढ़ने में जाता है, तो मुझे लगता है कि यह काफी बढ़ा-चढ़ाकर कहा गया है। AI बनाने वाले लोग सब इसी लहजे में बात करते हैं, लेकिन कम-से-कम मौजूदा स्थिति को देखें तो ऐसा नहीं लगता। अगर ऐसी स्थिति आ जाए जहाँ इंसानी हाथ की ज़रूरत ही न रहे, तो क्या सच में coding की ज़रूरत होगी? तब तो API documentation देकर LLM को backend की तरह इस्तेमाल करना ही बेहतर होगा।

[reagea0]

असल में schema सेट करके प्राप्त करके, काफ़ी लोग उसे इसी तरह इस्तेमाल करते हैं।

[nowdoit7]

मैं सहमत हूँ। शुरुआत में यह लगभग जादुई विकास गति दिखाता है, लेकिन जैसे-जैसे स्केल बढ़ता है और फाइलें ज्यादा होती जाती हैं, अगर इसे मैनेज करने वाला जिम्मेदार व्यक्ति (यहाँ इंसान) इसे प्रभावी ढंग से संभाल नहीं पाता, तो आखिर में सिर्फ एक ऐसा परिणाम मिलता है जो आकार में बड़ा है और त्रुटियों से भरा हुआ है। अगर बात पहले ही उस हालत तक पहुँच जाए जहाँ कुछ संभालना मुश्किल हो, तो सिर्फ credits (Windsurf) या requests (Cursor) ही बर्बाद होते हैं। समय के साथ यह बेहतर होता जाएगा, लेकिन अभी AI कोड पर 100% भरोसा नहीं करना चाहिए।

[GN⁺]

Hacker News राय

• "AI हाइप बनाम हक़ीक़त" के बीच बड़ा फ़र्क उन productivity numbers में है जिनकी लोग अक्सर बात करते हैं। उदाहरण के लिए, YC पार्टनर यह कहते हुए एक कंपनी का हवाला देते हैं कि उसकी coding performance में "100x speedup" हुआ है। ऐसे दावे बाहरी पर्यवेक्षकों को साफ़ दिखने चाहिए, इसलिए self-reporting की ज़रूरत नहीं होनी चाहिए।

  • YC summer batch 84 दिनों तक चलता है और Demo Day पर खत्म होता है। 100x speedup का मतलब होगा कि टीम एक दिन से भी कम समय में Demo Day-स्तर के features वाला app बना ले। अगर 100x सच होता, तो पार्टनर कहते कि नई batch "ग्राहकों के साथ नाश्ता करती है, कुछ नया सीखती है, प्रेरित होती है, और उसी दिन app को फिर से लिख देती है, और नतीजे में Demo Day-स्तर की functionality होती है।" लेकिन ऐसी बातें नहीं सुनाई देतीं, इसलिए 100x सटीक नहीं है।
  • 10x improvement भी होता, तो पार्टनर कहते कि "इस batch में लोग पहले हफ़्ते में ही Demo Day-स्तर का app production में डाल रहे हैं।" पार्टनर्स के पास इस बात का बहुत बड़ा sample size है कि टीमें कितने समय में कितना काम पूरा करती हैं। इसलिए 10x भी सच नहीं है।

• अभी हम outsourcing boom जैसी स्थिति का पीछा कर रहे हैं। सारे बढ़ा-चढ़ाकर किए गए दावों के बावजूद, हक़ीक़त अलग है। LLM coding agents पर चर्चा में फर्क कर पाना मुश्किल है।

• यह वैसा ही है जैसे Go community कहती थी कि कंप्यूटर इंसानी Go खिलाड़ियों को कभी नहीं हरा सकते। ऐसे models के उदाहरण पहले से मौजूद हैं जिन्होंने बेहतर sorting भी खोजी है। सही incentives और समय मिलने पर कंप्यूटर हमें हरा देंगे।

  • "Vibe coding" अभी हक़ीक़त नहीं है। गलतियों को ठीक करने और दिशा देने के लिए अनुभव और कौशल चाहिए। लेकिन सुधार की trajectory साफ़ दिख रही है।

• coding LLMs के बारे में एक नई समस्या साझा की गई। offshore developers पूरी तरह team में integrated हैं। लेकिन LLM का इस्तेमाल इतना बेतरतीब और असंगत है कि submit किए गए pull requests किसी nightmare जैसे हो जाते हैं।

  • मैं code लिखने में मदद के लिए LLM का इस्तेमाल करता हूँ, लेकिन बहुत सावधानी से। समय की बचत होती है, पर quality बेहतर नहीं होती। सही तरह से prompt करना सीखने में लगने वाला समय, output verify करने का समय, और छोटे bugs ठीक करने का समय इस फ़ायदे को काफ़ी हद तक खत्म कर देता है।
  • "Vibe coding" मत करो, और नौकरी न खोने के लिए सावधान रहो।

• "Vibe Coding" किसी concept का 80% implement कर सकता है। लेकिन कुछ भरोसेमंद, सुरक्षित और वास्तव में मूल्यवान बनाने के लिए अनुभवी इंसान चाहिए।

  • सबसे अच्छे हाल में भी 80% सिर्फ proof of concept होता है। 80% ऐसा है जैसे QA बस बार के दरवाज़े तक पहुँचा हो।

• हाल ही में Claude और OpenAI o3-mini का इस्तेमाल करके Matlab code को Python में बदलने की कोशिश की गई, लेकिन performance बहुत खराब थी। लगभग हर महत्वपूर्ण line में गलती थी। यह ऐसा काम है जिसे automate किया जाना चाहिए, लेकिन यह असफल रहा।

• "Vibe-TDDing" करना tests न होने से बेहतर है। अगर coding और testing की समझ हो, तो LLM का इस्तेमाल करके नकारात्मक externalities को कम किया जा सकता है।

• SaaS बनाने का तरीका साझा करने के बाद अजीब चीज़ें होने लगीं। API key usage अपनी सीमा तक पहुँच गया, subscriptions को bypass किया गया, और DB में random चीज़ें बन गईं। यह किसी prank की तरह लगता है।

• कई engineers को AI coding tools की क्षमता और productivity को कम आँकते देख कर अपने career को लेकर एक तरह का भरोसा महसूस होता है। मैं Cursor को छोड़ने वाला नहीं हूँ।

  • AI tools जिन चीज़ों में अच्छे हैं: दोहराव वाला code लिखना, जटिल DSA tasks, आसान और उबाऊ काम, सीमित refactoring
  • AI tools जिन चीज़ों में अच्छे नहीं हैं: product/business को code में map करना, large-scale refactoring
  • code quality मुख्य समस्या नहीं है। AI अभी भी productivity बढ़ाने में बहुत मददगार है।