मैं पहचान सकता हूँ जब आप 'Vibe Coding' कर रहे होते हैं

• हाल ही में टीम के कोड में यह तुरंत पहचान में आ जाता है कि कोई हिस्सा LLM-generated code है।
• ऐसा कोड project conventions को फॉलो नहीं करता, फिर भी साफ़ और अच्छे से टेस्टेड होता है।
• कई बार कई existing patterns और libraries को नज़रअंदाज़ करके सीधे नया implementation लिखा जाता है।
• सॉफ्टवेयर विकास में केवल गति पर ही केंद्रित रहने की प्रवृत्ति के बारे में चिंता बढ़ रही है।
• आखिर में महत्वपूर्ण चीज़ quality और consistency तथा maintainability ही होती है।

---

वाइब कोडिंग के संकेत

• टीम के हालिया कोड में से कुछ ऐसा दिखता है जो बहुत साफ़ और फीचरली परफेक्ट लगता है, लेकिन project-specific conventions न मानने से तुरंत पता चलता है कि यह LLM-generated है।
• उदाहरण के लिए, जब परियोजना में पहले से मौजूद data-fetching library होने के बावजूद सभी exception cases हैंडल करने वाली HTTP request implementation सीधे खुद लिखी जाती है।
• मौजूदा मॉड्यूल के utility functions दोबारा-तिबारा नए सिरे से बनते हैं, या module-level config override mechanism मौजूद होने पर भी global config बदल दिया जाता है।
• फंक्शनल तरीके से कोडिंग की संस्कृति बन जाने के बावजूद नया class-based code लिखा जाता है।
• ऐसा कोड वही शैली है जिसे किसी इंसान ने कई साल पहले शायद ही कभी लिखा होता।

मेंटेनेंस और सॉफ्टवेयर सिद्धांतों का महत्व

• सॉफ्टवेयर डेवलपमेंट में हमने लंबे समय तक लंबे समय तक maintainable patterns और standards बनाने में प्रयास किया है।
• कोई भी ऐसा कोड बना सकता है जो सिर्फ काम करे, लेकिन समय के साथ आसानी से maintain और बदलने में आसान कोड बनाना ही वास्तविक चुनौती है।
• मुद्दा सिर्फ फीचर implement करना नहीं, बल्कि समय के बाद भी संचालित रखा जा सकने वाला codebase होना है।
• “Vibe Coding” इन established philosophy और standards को कमजोर कर सकता है।

क्या गति ही सर्वोच्च प्राथमिकता होनी चाहिए?

• कॉफी शॉप में नया barista जल्दी में काम करते हुए कॉफी गिरा देता है—इस उदाहरण से यह दिखता है कि speed obsession सही परिणाम नहीं देता।
• आजकल development teams भी बहुत जल्दी नए software बनाने के चक्कर में quality गिरावट का सामना कर रही हैं।
• लोग असल में चाहते हैं कि थोड़ा देर से सही, लेकिन सही आउटपुट मिले।
• पहले यह लगता था कि सिर्फ speed पर फोकस करना शायद non-development roles की समस्या है, लेकिन साथ काम करने वाले developers में भी principles छोड़कर सिर्फ speed के पीछे भागने का चलन देखकर निराशा होती है।

सच में क्या चाहिए

• कोड को IDE में कैसे डाला गया यह मायने नहीं रखता।
• महत्त्वपूर्ण यह है कि डेवलपर का quality के प्रति संवेदनशील दृष्टिकोण हो।
• LLM को बड़ा technical innovation मानते हुए भी, असली software बनाना की जिम्मेदारी अभी भी developer पर ही रहती है।
• “बेहतर prompt लिखना”, “सही libraries चुनना”, “examples provide करना”, “छोटे फाइल यूनिट में काम करना” जैसे concrete existing principles को समझकर apply करने की सलाह दी गई।
• code quality और maintainability को केवल मॉडल के ‘weights’ पर छोड़ देने का जोखिम न लें।

[GN⁺]

Hacker News राय

• मैं ऐसी टीम में काम करना चाहूँगा जहाँ कोई भी उस स्थिति में HTTP fetching implementation दोबारा न बनाए जब प्रोजेक्ट में पहले से मौजूद data fetching library सभी edge cases कवर कर रही हो, जहाँ पहले से utility function module होने पर उसे फिर से न लिखा जाए, जहाँ global settings को individual modules में बदला जा सकता हो लेकिन बेवजह न बदला जाए, और जहाँ टीम मुख्य रूप से functional approach इस्तेमाल करती हो तो कोई नई class न बना दे; लेकिन हकीकत में बहुत से developers ऐसी चीज़ें बार-बार करते रहते हैं

  • सच कहूँ तो, बड़े projects में documentation कमज़ोर हो तो ऐसी चीज़ें बहुत आसानी से हो जाती हैं। जिस academic research project पर मैं काम करता हूँ, उसके code docs बस इतना मान लेते हैं कि code खुद ही self-documenting है, और बस CMake setup, build, benchmark करने के तरीके जैसी चीज़ों का छोटा-सा ज़िक्र है। Internal rules या conventions जैसी बातें आपको खुद काम करते-करते समझनी पड़ती हैं। कोई नया व्यक्ति आता है तो अक्सर पहले से बनी functionality फिर से बना देता है या global settings बदल देता है। आख़िरकार codebase को index करके सीधे LLM से पूछना ही सबसे अच्छा उपाय बन जाता है (क्योंकि project के मुख्य लोग या तो जा चुके होते हैं या बहुत देर बाद जवाब देते हैं)

  • मुझे लगता है लोग लेखक का मुख्य point मिस कर रहे हैं। अगर speed ही सबसे बड़ा virtue है, तो ऐसी चीज़ें बार-बार होती रहेंगी। अगर speed ही absolute value है, तो technical debt की भरपाई के लिए output को geometrically बढ़ना होगा। अगर speed के अलावा और चीज़ें भी मायने रखती हैं, तो debt को समझदारी से manage और repay करना होगा। लेकिन आजकल माहौल ऐसा लगता है जैसे बस debt बढ़ाते जाओ और उम्मीद करो कि somehow चल जाएगा। और बहुत से लोग debt manage करने में सचमुच अच्छे नहीं हैं

  • लोग मौका मिलते ही बार-बार wheel reinvent करते हैं, expected conventions को ignore करते हैं, या mixed patterns इस्तेमाल करते हैं। लेखक इसे 'vibe coding' कहेगा, लेकिन असल में यह सिर्फ LLM की समस्या नहीं है; जब कोई भी इंसान जल्दी में सिर्फ result निकालना चाहता है या उसके पास experience कम होता है, तो यही होता है। 'ऐसा code जिसे टीम का कोई भी सदस्य इस तरह नहीं लिखेगा' जैसी बात देखकर लगता है कि शायद यह किसी खास व्यक्ति की तरफ़ इशारा करने वाली शिकायत है। इस नज़रिए को हर जगह लागू करने में सावधानी रखनी चाहिए

  • मैंने ऐसे developers भी देखे हैं जो एक और ORM library जोड़ देते हैं। पहली ORM काफ़ी होती है, लेकिन 'अभी यह hot है' इस वजह से दूसरी डाल दी जाती है। चाहे developer हो या LLM, दोनों के अपने biases होते हैं। Project के rules और patterns को समझना और उसी ढाँचे में काम करना बहुत ज़रूरी है। Context समझे बिना अपने तरीके से चीज़ें बनाना बहुत ख़तरनाक है। इंसानों के मामले में यह code review culture और code पढ़ने की आदत को बढ़ावा देकर सुधारा जा सकता है, लेकिन LLM के मामले में सभी patterns और rules साफ़-साफ़ guide करने पड़ते हैं। नहीं तो project से mismatch करने वाला code बनने का ख़तरा बहुत बढ़ जाता है। अहम बात यह है कि values और clear standards को explicitly सेट किया जाए

  • मुझे ऐसी अच्छी टीम में काम करने का अनुभव रहा है। छोटे scale (2-4 लोग) पर चलने वाले कई high-importance projects थे। ऐसे माहौल में quality और speed के बीच balanced development culture और आपसी agreement बनाना आसान होता है। ऐसी टीमों में चाहे इंसान हो या LLM, ऊपर जैसा code कभी PR approval नहीं पाता

• मेरे हिसाब से LLM एक बहुत junior developer जैसा है। वह काम ठीक से करने की कोशिश करता है और instructions follow करता है, लेकिन codebase और patterns की समझ कम होती है। आपको हर process step-by-step बताना पड़ता है, संभावित errors तक समझाने पड़ते हैं, छोटे और specific tasks देने पड़ते हैं, और code बहुत ध्यान से review करना पड़ता है। मेरी तरह, पहले दिमाग में data model बनाओ और फिर code पर जाओ। Specific explanation बहुत ज़रूरी है। एक मेरा नियम है कि file के top पर हमेशा block comment डालो जो file में क्या है यह समझाए। Session restart होने पर यह दूसरे prompt की तरह काम करता है। यह तरीका बिना किसी 'जादू' वाली feeling के अच्छी तरह चलता है, लेकिन बीच में लगभग 30% समय code cleanup, renaming, और refactoring में देना पड़ता है ताकि चीज़ें ठीक दिखें। फिर भी LLM होने से पूरा हाथ से लिखने की तुलना में काम बहुत तेज़ हो जाता है

  • 'junior developer' या 'copilot' जैसी terms कभी-कभी LLM की strengths और weaknesses दोनों को ठीक से नहीं पकड़ पातीं। आम इंसान से अलग, यह चीज़ें आसानी से भूल जाता है और बहुत बुनियादी गलतियाँ भी कर सकता है, लेकिन कुछ मामलों में मुझसे बेहतर भी है (जैसे arrays में off-by-one issues)। और यह इंटरनेट की लगभग हर चीज़ encyclopedic तरीके से जानता है। इस्तेमाल करने के बाद मुझे लगता है LLM कुछ हद तक hunting dog जैसा है। शिकार को lead मालिक करता है और आख़िरी काम भी वही पूरा करता है

  • LLM और junior developer में फ़र्क सीखने की क्षमता का है। Junior धीरे-धीरे सीखकर बढ़ सकता है, लेकिन LLM ऐसा नहीं करता। Prompt में जितनी ज़्यादा instructions डालो, उतनी ही संभावना बढ़ती है कि वह और ज़्यादा भूल जाएगा और generic जवाबों पर लौट जाएगा। हर नए prompt की शुरुआत में आपको फिर से शुरुआत से समझाना पड़ता है

  • मुझे LLM और इंटरनेट से code ढूँढकर copy-paste करने में बहुत बड़ा अंतर नहीं लगता। आख़िर में developer को खुद code जाँचना ही पड़ता है कि वह सही चल रहा है या नहीं। हाल में आँखों की सेहत की वजह से मुझे 20 मिनट काम करके ब्रेक लेना पड़ता है, इसलिए efficiency और अहम हो गई है। LLM इंसान से कहीं तेज़ code generate करता है, इसलिए अगर उससे सिर्फ basic हिस्से भी करवा लो तो भी बड़ा फ़ायदा है। मैं अभी Unity C# और LINQ के साथ SIMD के लिए structs बना रहा हूँ, और सिर्फ LLM को अपनी शर्तें बता देने भर से मुझे copy-paste करने की तुलना में बहुत तेज़ी से मनचाहा code या strings मिल जाते हैं। AI को HUD की तरह इस्तेमाल करने वाला विचार काफ़ी वास्तविक लगता है। मुझे पूरा program बनाने वाली AI से ज़्यादा, छोटे units में काम करने वाला एक ताकतवर development assist tool चाहिए

  • मेरे लिए LLM, StackOverflow की तुलना में कहीं बेहतर substitute है। मैं जो पूछना चाहता हूँ, सीधे पूछता हूँ और यह सटीक जवाब देता है। फिर उन जवाबों को देखकर मैं अपनी code style में दोबारा लिखता हूँ या सिर्फ function generate करवाता हूँ। Copy करने से पहले मैं हमेशा code को पूरी तरह समझने की कोशिश करता हूँ। कभी-कभी मैंने सोचा है कि कहीं 400k-line PR किसी open source project में ऐसी भाषा में डाल देना जिसे मैं ठीक से नहीं जानता, ईमानदारी और quality-focused तरीके से काम करने की तुलना में career के लिए ज़्यादा फ़ायदेमंद तो नहीं। असल वजह यह है कि वास्तविक दुनिया में अक्सर Years of Experience को skills से ज़्यादा महत्व दिया जाता है

  • LLM से सफलतापूर्वक काम करवाने के लिए मुझे यह सबसे अच्छा लगा कि उसे सोचने के बजाय सिर्फ actual coding step तक सीमित रखा जाए। Task को छोटे हिस्सों में बाँटो, और specific spec, किन files को बदलना है, reference examples कहाँ हैं—ऐसी ज़्यादा से ज़्यादा details दो, तो success rate बढ़ता है। बहुत सूक्ष्म होने की ज़रूरत नहीं, लेकिन जितने ज़्यादा clues हों, उतनी सफलता की संभावना बढ़ती है। जो code बनता है, उसे भी मैं git add -p से chunk-by-chunk खुद verify करता हूँ। तैयारी और review में समय लगता है, लेकिन सब कुछ अकेले लिखने या ख़राब code वैसे ही छोड़ देने की तुलना में यह निश्चित रूप से समय और energy बचाता है

• Vibe coding का सबसे बड़ा जोखिम यह है कि अच्छे developers बस थोड़ा तेज़ हो जाते हैं, लेकिन कमज़ोर developers बहुत ज़्यादा तेज़ी से बहुत सारा ख़राब code बना देते हैं। सवाल यह है कि क्या ऐसे developers vibe coding के ज़रिए बेहतर बन सकते हैं, या बस वहीं अटक जाते हैं

  • मेरे अनुभव में mediocore(औसत) developer भी बहुत तेज़ी से ख़राब developer बन सकता है। वजह है झूठा आत्मविश्वास और code output में अचानक बढ़ोतरी। AI से बना code overall architecture, information flow, और single responsibility principle जैसी बातों पर लगभग ध्यान नहीं देता। Safe code बनाने के नाम पर exceptions की जगह placeholder return कर देता है। फिर calling code को हर बार जाँचना पड़ता है कि result placeholder है या नहीं। अगर input parameters अच्छे न हों, तो AI खुद उन्हें 'ठीक' करने की कोशिश करता है और gather_parameters → call → process_results structure को ignore कर देता है। और testing तक पहुँचते-पहुँचते समस्या और भी बड़ी हो जाती है

  • अब बहुत से developers शायद net-negative programmer की अवधारणा को फिर से खोजेंगे—ऐसा developer जिसकी मौजूदगी ही project quality को नीचे ले जाए

• मेरे हिसाब से यहाँ सबसे कम उपलब्ध resource है caring। Vibe coding खुद care की कमी की वजह नहीं है; AI तो बस एक tool है। लेखक जिन सभी issues की बात कर रहा है, वे human junior developers पर भी वैसे ही लागू होते हैं, और बेहतर guidance या communication से सुधारे जा सकते हैं। मुझे नहीं लगता कि AI की वजह से quality की परवाह कम होती है (जिन्हें परवाह नहीं थी, वे पहले भी वैसे ही थे)। अक्सर जवाब में कहा जाता है कि 'इससे juniors को train करने के मौके छिन जाते हैं', लेकिन कई बार लोगों के पास capacity नहीं होती, इसलिए वे AI को temporary workaround की तरह इस्तेमाल करते हैं (मेरे startup में भी यही है, जहाँ hiring आसान नहीं है)। AI tools की वजह से software quality standards बदल सकते हैं, और मुझे लगता है इस हिस्से में आगे और बदलाव आने की गुंजाइश है

• LLM को सिर्फ current state नहीं, बल्कि पुराने commit history को भी context के रूप में इस्तेमाल करना चाहिए। बहुत से codebases pattern A से pattern B की तरफ़ धीरे-धीरे migrate कर रहे होते हैं, और कई patterns साथ-साथ मौजूद होते हैं। Migration एक बार में नहीं हो पाती, इसलिए पुराना और नया लंबे समय तक साथ चलता रहता है। HTTP वाले उदाहरण की तरह, LLM अगर patterns पहचान भी ले, तब भी किसे follow करना है यह काफ़ी हद तक किस्मत पर निर्भर हो जाता है

  • मैंने 20 साल से ज़्यादा mergers, renaming, acquisitions वगैरह झेल चुके एक बड़े codebase पर काम किया है। उसमें बहुत पुराने API call examples अब भी पड़े हैं, जबकि व्यवहार में नए code paths भी मौजूद हैं, लेकिन कई चीज़ें खास customers के लिए छोड़ दी गई हैं। बहुत से ऐसे similar APIs भी हैं जिनकी documentation बिल्कुल नहीं है, इसलिए मनचाहा data पाने के लिए कौन-सा use करना चाहिए यह खुद खोजते रहना पड़ता है

  • CLAUDE.md जैसी file से साफ़-साफ़ बताना कि "इस pattern को follow करो, उस pattern से बचो" एक तरीका हो सकता है

  • उससे भी ज़्यादा असरदार है कि हर हिस्से के काम करने का तरीका और examples बहुत specific तरीके से दिए जाएँ

  • समस्या यह है कि इस तरह की context-reading क्षमता vibe coding करने वाले लोगों में ही अक्सर कम होती है। बहुत से लोगों के पास LLM आने से पहले भी coding experience कम था

  • यह तभी संभव है जब commit messages ठीक से लिखे गए हों। हक़ीक़त में ज़्यादातर messages बस "इस file में बदलाव", "bug fix" जैसे होते हैं

• LLM का इस्तेमाल करते समय linters, formatters, और strict type checks जैसे automation tools बहुत मददगार होते हैं। खासकर जब code contribution ऐसे लोगों (या LLM agents) से आए जिन्हें code style या implicit rules का पता न हो, तो automated तरीक़े से code inspect किया जा सकता है, और जो चीज़ें अपने-आप सुधर सकती हों उन्हें तुरंत ठीक भी किया जा सकता है। Testing के साथ भी यही बात है। Automated validation systems, इंसान हों या agents, दोनों के लिए quality बनाए रखने में बहुत उपयोगी हैं

  • मुझे नहीं लगता कि ऐसे tools वास्तव में article में बताए गए vibe coding के ज़्यादातर उदाहरणों को रोक पाएँगे

  • कई बार ये tools असली समस्या छिपाकर सिर्फ सतह को साफ़-सुथरा बना देते हैं

• सभी प्रमुख AI assistants के पास पहले से ही ऐसे issues को कम करने के built-in तरीके हैं, जैसे Claude Code का /init, Cursor का /Generate Cursor Rules वगैरह। ये सिर्फ context engineering से आगे जाकर ज़्यादा automated तरीके से पूरी organization पर लागू किए जा सकते हैं। आख़िरकार यह भी दिलचस्प सवाल है कि ऐसे tools developer community को कैसे बाँट रहे हैं

  • हक़ीक़त में CLAUDE.md में चाहे जितना साफ़ लिख दो, CC(Claude Code) कई बार उसे ignore कर देता है। Conversation आगे बढ़ने पर वही समस्याएँ दोहरती लगती हैं, और अभी तक मुझे पूरी तरह संतोषजनक समाधान नहीं मिला है। इसलिए मुझे नहीं लगता कि इस article को बस AI-विरोधी तर्क कहकर ख़ारिज कर देना सही होगा

  • मैं Cursor को फिर से evaluate कर रहा हूँ। यह उम्मीद के मुताबिक़ speed क्यों नहीं दे पा रहा, इसकी वजह सिर्फ छोटी errors नहीं हैं (जैसे LM का : को , में बदल देना), बल्कि यह भी है कि codebase बहुत बड़ा, बहुत पुराना, और quality में बहुत uneven है। LLM आख़िरकार उन्हीं patterns को ज़्यादा उठाता है जो सबसे आम हैं (= अक्सर ख़राब patterns)। भले ही साफ़ कहा जाए कि "इस हिस्से को refer करो", फिर भी वह पूरे codebase के असर में रहता है। Rule के रूप में define कर दो, तब भी लगता है कि यह prompt में सीधे लिख देने से बहुत अलग नहीं है। क्या इसका कोई समाधान है, यह जानने की उत्सुकता है

  • समस्या का मूल tool नहीं, बल्कि वह 'coder' है जो vibe को ज़्यादा अहमियत देता है। उसमें न care है, न code लिखने में कसाव

• मेरे अनुभव में लगभग सभी issues सीमित context window और suboptimal 'context engineering' का परिणाम हैं। अगर LLM तक global functions जैसी अहम context सही तरह पहुँचा दी जाए तो वह अपेक्षाकृत अच्छा इस्तेमाल करता है। असली समस्या यह है कि कौन-सा context बिना टूटे लगातार बनाए रखकर दिया जाए। मुझे उम्मीद है कि आगे sub-agent जैसी चीज़ों के साथ इस क्षेत्र में काफ़ी प्रगति होगी

  • आपने कहा कि "अगर agent को global functions की explanation पता हो तो वह अच्छा इस्तेमाल करता है", लेकिन सच यह है कि 'agent' जैसी कोई चीज़ है ही नहीं। वह बस input और output को जोड़ने वाला एक mathematical function है। LLM की तुलना इंसान से करना सटीक नहीं है; इंसान और मशीन पूरी तरह अलग हैं

• मुझे लगता है यह सब सही है। LLM का सबसे अच्छा उपयोग तब है जब वह compiler की तरह assembly से एक स्तर ऊपर abstraction देने के बजाय, requirements और input-output को साफ़-साफ़ समझकर logical translation के रूप में code बना दे। इसलिए input में confusion (entropy) को कम से कम रखना चाहिए। LLM मूलतः एक translation engine है। इसे 'generation' नहीं बल्कि 'translation' के लिए इस्तेमाल करना ज़्यादा प्रभावी है। फिर भी समय-समय पर और ज़्यादा smart और intuitive models आते जा रहे हैं, और उतनी ही कम मेहनत में बेहतर results मिल रहे हैं। आख़िरकार एक समय ऐसा आएगा जब LLM किसी भी task में human developers से बेहतर नतीजे देगा, और इंसानों की दूसरी भूमिकाओं में भी ऐसा ही होगा

  • यह ग़लत analogy है। LLM natural language को high-level code में 'compile' करने वाला engine नहीं है। Programming languages और machine language में साफ़ और consistent semantics चाहिए होती हैं, जबकि natural language की abstraction layer ही अलग है। वही LLM नए seed value या version पर अलग output दे सकता है, जबकि compiler को हमेशा एक ही input पर वही output देना चाहिए

  • मैं इस बात से सहमत नहीं हूँ कि LLM compiler जैसा कोई abstraction layer है। असल में LLM तो बस एक arbitrary token generator है। LLM से बने results में मैंने कभी कुछ ऐसा नहीं देखा जिसे सचमुच उपयोगी कहा जा सके। Singularity या infinite data availability जैसी techno-optimism वाली बातें वास्तविक आधार से खाली लगती हैं। आख़िरकार high-quality data जुटाना बहुत महँगा काम है। फिलहाल ऐसे hopeful predictions बेकार हैं

• मैंने लेखक से भी देर से यह समझा कि "बहुत से लोग अच्छी coffee से ज़्यादा तेज़ और सस्ती coffee चाहते हैं"। वास्तविक दुनिया में ज़्यादातर लोग quality से ज़्यादा speed और price को महत्व देते हैं

  • Keurig coffee machine की लोकप्रियता ही उस रुझान को समझाने के लिए काफ़ी है

[dkmin]

मुख्य लेख से ज़्यादा HN की पोस्ट ही ज़्यादा मज़ेदार है