Vibe Engineering

• "Vibe Engineering" AI coding tools का उपयोग करने वाली प्रोफेशनल डेवलपमेंट पद्धति का एक नया नाम है। तेज़ और गैर-जिम्मेदाराना 'vibe coding' के विपरीत, इसका मतलब है अनुभवी इंजीनियरों द्वारा LLM का उपयोग करते हुए भी code quality और जवाबदेही बनाए रखने वाला दृष्टिकोण
• Claude Code, OpenAI Codex CLI, Gemini CLI जैसे coding agents के आगमन से वास्तविक प्रोजेक्ट्स में LLM का उपयोग तेज़ी से बढ़ा है, और कुछ इंजीनियर कई agents को एक साथ चलाकर parallel work भी कर रहे हैं
• LLM का प्रभावी उपयोग करने के लिए automated testing, advance planning, comprehensive documentation, version control, code review culture जैसी पहले से स्थापित उच्च-स्तरीय software engineering practices की ज़रूरत होती है
• AI tools मौजूदा विशेषज्ञता को amplify करते हैं, और किसी senior engineer के पास जितनी अधिक skill और experience होगा, LLM का उपयोग करते समय उतने ही तेज़ और बेहतर नतीजे मिल सकते हैं
• यह शब्द 'vibe coding' से स्पष्ट भेद बनाते हुए इस बात पर ज़ोर देता है कि यह production software development के लिए AI के अधिक कठिन और अधिक परिष्कृत उपयोग का तरीका है, और engineering तथा vibe का विरोधाभासी संयोजन इसे उलटे याद रखने में आसान बनाता है (AI tools की प्रगति के साथ development process में बदलाव और विशेषज्ञता के महत्व को उजागर करता है)

---

vibe coding और vibe engineering के बीच अंतर

• vibe coding AI का उपयोग करने वाली तेज़, ढीली और गैर-जिम्मेदार software development शैली है, जो पूरी तरह prompt-driven होती है और code कैसे काम करता है, इस पर ध्यान न देने वाला दृष्टिकोण अपनाती है
• स्पेक्ट्रम के दूसरे छोर पर अनुभवी विशेषज्ञों का वह तरीका मौजूद है जिसमें वे LLM से काम तेज़ करते हैं, लेकिन अपने बनाए software पर गर्व के साथ आत्मविश्वासपूर्वक ज़िम्मेदारी भी लेते हैं; इसे vibe engineering कहा गया है
• toy projects नहीं बल्कि वास्तविक projects में एक software engineer के रूप में LLM के साथ उत्पादक ढंग से काम करना कठिन है — यह कम चर्चित सच्चाई है; इसके लिए tools के उपयोग की गहरी समझ चाहिए और कई pitfalls से बचना पड़ता है

coding agents का आगमन और प्रभाव

• फ़रवरी 2025 में जारी Claude Code, अप्रैल में जारी OpenAI का Codex CLI, और जून में जारी Gemini CLI जैसे coding agent tools आने से वास्तविक coding समस्याओं में LLM की उपयोगिता नाटकीय रूप से बढ़ गई
  • ये tools code को बार-बार संशोधित करते हैं और सक्रिय रूप से test करते हैं, ताकि तय किए गए लक्ष्य तक पहुँचने तक काम जारी रहे
• अनुभवी और विश्वसनीय software engineers कई agents को एक साथ चलाकर कई समस्याओं को parallel में संभाल रहे हैं और अपने काम का दायरा बढ़ा रहे हैं
  • लेखक शुरू में संदेह में था, लेकिन खुद parallel coding agents चलाने के बाद उसने पाया कि यह मानसिक रूप से थकाने वाला, लेकिन आश्चर्यजनक रूप से प्रभावी है
• tools.simonwillison.net collection का बड़ा हिस्सा पारंपरिक vibe coding शैली में बनाया गया था, लेकिन coding agents के साथ iteratively काम करके भविष्य में maintain की जा सकने वाली production-quality code बनाना एक बिल्कुल अलग प्रक्रिया जैसा महसूस होता है

LLM किन मौजूदा software engineering practices को मजबूत करता है

• automated testing: अगर आपके पास मजबूत, व्यापक और भरोसेमंद test suite है, तो agent coding tools तेज़ी से काम कर सकते हैं; test न होने पर agents बिना वास्तव में test किए काम करने का दावा कर सकते हैं, या नए बदलाव असंबंधित features को तोड़ सकते हैं
  • test-first development खास तौर पर उन agents के लिए प्रभावी है जो loop में iterate कर सकते हैं
• advance planning: जब आप कुछ hack करके बनाने बैठते हैं, तो अगर शुरुआत high-level plan से हो, तो काम कहीं बेहतर चलता है; agents के साथ काम करते समय यह और भी महत्वपूर्ण हो जाता है
  • पहले plan पर iterate किया जा सकता है, फिर agent को देकर code लिखवाया जा सकता है
• comprehensive documentation: human programmers की तरह LLM भी एक समय में codebase के केवल कुछ हिस्सों को ही context में रख सकते हैं; संबंधित docs देने पर वे code को पहले पढ़े बिना दूसरे हिस्सों की API का उपयोग कर सकते हैं
  • अगर पहले अच्छे docs लिख दिए जाएँ, तो model केवल उसी input के आधार पर मेल खाती implementation बना सकता है
• अच्छी version control आदतें: अगर coding agent ने बदलाव किए हों, तो गलतियों को rollback करना और यह समझना कि क्या कब और कैसे बदला, और भी ज़रूरी हो जाता है
  • LLM Git में बहुत सक्षम होते हैं; वे bug की जड़ खोजने के लिए history को खुद explore कर सकते हैं और ज़्यादातर developers से बेहतर git bisect का उपयोग कर सकते हैं
• प्रभावी automation: continuous integration, automated formatting और linting, preview environments में continuous deployment जैसी चीज़ें agent coding tools के लिए भी फायदेमंद हैं
  • LLM तेज़ automation scripts लिखना आसान बनाते हैं, जिससे अगली बार काम को सही और consistent तरीके से दोहराया जा सके
• code review culture: अगर आप code review में तेज़ और उत्पादक हैं, तो LLM के साथ काम करते समय आपका अनुभव बहुत बेहतर होगा
  • अगर आप दूसरे व्यक्ति (या किसी और चीज़) द्वारा लिखा वही code review करने के बजाय खुद code लिखना पसंद करते हैं, तो यह मुश्किल होगा
• management technique का एक बेहद अजीब रूप: coding agents से अच्छे नतीजे लेना असहज रूप से वैसा ही है जैसा human collaborators से अच्छे नतीजे लेना
  • आपको स्पष्ट निर्देश देने होंगे, ज़रूरी context सुनिश्चित करना होगा, और output पर actionable feedback देना होगा
  • यह असली लोगों के साथ काम करने से बहुत आसान है, क्योंकि आपको उन्हें अपमानित या हतोत्साहित करने की चिंता नहीं करनी पड़ती; फिर भी पुराना management experience आश्चर्यजनक रूप से उपयोगी साबित होगा
• वास्तव में अच्छी manual QA (quality assurance): automated testing के अलावा, edge cases का अनुमान लगाकर उनमें गहराई से जाने सहित software को manually test करने में वास्तव में निपुण होना चाहिए
• मजबूत research skills: किसी coding problem को हल करने के दर्जनों तरीके हो सकते हैं; सबसे अच्छा विकल्प पहचानना और अपने approach को साबित करना हमेशा महत्वपूर्ण था, और agents को वास्तविक code लिखने के लिए छोड़ देने से पहले यह अब भी एक बड़ी बाधा है
• preview environments में deploy करने की क्षमता: जब agent कोई feature बना दे, तो अगर उसे production में सीधे भेजे बिना सुरक्षित रूप से preview करने का तरीका मौजूद हो, तो review कहीं अधिक उत्पादक हो जाती है और टूटे हुए software को ship करने का जोखिम बहुत कम हो जाता है
• क्या AI को outsource किया जा सकता है और क्या manually करना चाहिए, इसकी instinct: models और tools जैसे-जैसे अधिक प्रभावी होते जा रहे हैं, यह समझ लगातार बदल रही है
  • LLM के साथ प्रभावी ढंग से काम करने का बड़ा हिस्सा यह है कि कब उनका सबसे अच्छा उपयोग हो सकता है, इसकी मजबूत सहज समझ बनाए रखी जाए
• estimation की नई समझ: किसी project में कितना समय लगेगा, इसका अनुमान लगाना हमेशा senior engineer होने का सबसे कठिन लेकिन सबसे महत्वपूर्ण हिस्सा रहा है, खासकर उन संगठनों में जहाँ budget और strategy के फैसले इन्हीं estimates पर आधारित होते हैं
  • AI-assisted coding इसे और कठिन बनाती है; जो चीज़ें पहले बहुत समय लेती थीं वे अब कहीं तेज़ हो गई हैं, लेकिन estimation अब उन नए factors पर निर्भर है जिन्हें हम सब अभी समझने की कोशिश कर रहे हैं

vibe engineering का सार और महत्व

• इन नए tools की क्षमता का वास्तव में लाभ उठाने के लिए game के highest level पर operate करना पड़ता है, और इसमें सिर्फ code लिखने की ज़िम्मेदारी नहीं होती, बल्कि
  • approach पर research,
  • high-level architecture decisions,
  • specs लिखना,
  • success criteria तय करना,
  • agent loops design करना,
  • QA plans बनाना,
  • ऐसे अजीब digital interns की लगातार बढ़ती फौज को manage करना जो मौका मिलने पर cheating करने की कोशिश करते हैं,
  • और code review में बहुत समय लगाना भी शामिल है
• इनमें से लगभग हर चीज़ पहले से ही senior software engineer की विशेषता है
• AI tools मौजूदा विशेषज्ञता को amplify करते हैं; software engineer के रूप में आपके पास जितनी अधिक skill और experience होगा, LLM और coding agents के साथ काम करते हुए उतने ही तेज़ और बेहतर परिणाम मिलेंगे

“Vibe engineering”, really? : शब्द-चयन पर विचार

• क्या "vibe engineering" नाम बेवकूफाना है? शायद हाँ; AI में "vibe" की अवधारणा इस समय थोड़ी थकी हुई लगती है, और "vibe coding" खुद कई developers के बीच तिरस्कारपूर्ण अर्थ में इस्तेमाल होती है
  • फिर भी, लेखक किसी अधिक रचनात्मक चीज़ के लिए vibe शब्द को वापस लेने को तैयार है
• लेखक को कभी भी "coder" और "engineer" के बीच का कृत्रिम अंतर पसंद नहीं आया; यह हमेशा थोड़ा entry barrier जैसा लगा, लेकिन इस मामले में थोड़ा entry barrier ही शायद ठीक वही चीज़ है जिसकी ज़रूरत है
  • vibe engineering, vibe coding से साफ़ अंतर स्थापित करती है और संकेत देती है कि यह production software बनाने के लिए AI tools के साथ काम करने का अलग, अधिक कठिन और अधिक परिष्कृत तरीका है
• लेखक को यह पसंद है कि यह थोड़ा ढीठ और विवादास्पद लग सकता है; यह पूरा क्षेत्र अब भी कई मायनों में बेतुका है
  • इन नए tools को लागू करने के सबसे उत्पादक तरीकों को समझते समय हमें खुद को बहुत ज़्यादा गंभीरता से नहीं लेना चाहिए
• पहले AI-assisted programming जैसे शब्द को स्थापित करने की कोशिश की गई थी, लेकिन लगभग शून्य सफलता मिली; इस बार vibe को रगड़कर देखना कि क्या होता है, बुरा विचार नहीं है
• लेखक को "vibe" और "engineering" के बीच का साफ़ विरोधाभास वास्तव में पसंद है, जो इस संयुक्त शब्द को खेल-खेल में और (उम्मीद है) आसानी से याद रहने वाले आत्म-विरोधाभासी रूप में बदल देता है

[m00nlygreat]

मुझे लगता है कि कुछ समय पहले भी इसे "ये कौन-सी coding है?" जैसा कोई नाम देकर देखने की कोशिश की गई थी और वह विफल रहा था, इसलिए AI pair programming ही सबसे उपयुक्त अभिव्यक्ति लगती है।

नाम तो बस यह दावा करने के लिए रखा जा रहा है कि "यह नाम मैंने बनाया था।"

[m00nlygreat]

किसी ने इसे Augmented Coding कहा था, लेकिन वह शब्द जल्दी ही गायब हो गया।

[GN⁺]

Hacker News राय

• हाल में ऐसे विषय पढ़कर किसी वजह से उदासी महसूस होती है। पहले लगता था कि मेरे पास ऐसी programming skills हैं जिन्हें पाना मुश्किल है, जिनकी मांग बहुत है और जिनका भुगतान भी अच्छा है। भाषा या framework जल्दी बदल जाएँ तब भी मैं इतना स्मार्ट हूँ कि उनके साथ चल सकूँगा। लेकिन जब Simon Willison जैसे लोग कहते हैं कि यह नया agent-based coding तरीका और एक साथ कई कामों वाला workflow ही भविष्य है, तो लगता है इसमें बहुत भारी मेहनत लगेगी और मन बैठ जाता है। मैंने coding agents इस्तेमाल करके देखे हैं, लेकिन उल्टा इंतज़ार का समय बढ़ जाता है, कई tasks को संभालना flow बनाए रखने में मुश्किल करता है, और मज़ा भी कम हो जाता है। इसलिए कभी-कभी लगता है कि sales जैसे किसी बिल्कुल अलग क्षेत्र में चला जाऊँ
  • मैं भी इस भावना से सचमुच सहमत हूँ। दरअसल मेरे लक्ष्यों में से एक यह धारणा खारिज करना था कि "programming skills बेकार हो जाएँगी और कोई भी LLM से code लिख लेगा"। मेरा मानना है कि जिसके पास पहले से development experience है, वह coding agents या LLM के साथ कहीं ज़्यादा मूल्यवान हो जाता है। अब तक जो सीखा है, उसे नए tools के साथ जोड़कर और बड़ा impact पैदा किया जा सकता है। पोस्ट में भी कहा गया है कि AI tools मौजूदा experts की क्षमता को amplify करते हैं। शुरुआती लोग ChatGPT से एक आकर्षक UI बना सकते हैं, लेकिन architecture design, automated tests, CI/CD, Kubernetes deployment, कई agents को साथ चलाना जैसी चीज़ें नहीं कर सकते। इसलिए experienced engineers की भूमिका और भी महत्वपूर्ण हो जाती है
  • मुझे भी "कई बड़े parallel agents को manage करना" बोझिल लगता है। ऊपर से यह बहुत शक्तिशाली दिखता है इसलिए बहुत से developers इसमें रुचि ले रहे होंगे, लेकिन वास्तव में यह बहुत तनावपूर्ण और managerial काम जैसा लगता है। जब मैं पहली बार development में डूबा था, तब coding खुद में मज़ेदार थी, और मैं दिन भर code लिखते हुए बहुत कुछ सीखता था। अब 10 साल से ज़्यादा अनुभव के बाद सोच बदलकर कुछ ऐसी हो गई है: "आख़िर coding करनी ही क्यों है?" मीटिंग में जब अलग-अलग विभाग पूछते हैं, "क्या यह किया जा सकता है?", तो जवाब लगभग हमेशा "YES" होता है। तकनीकी रूप से लगभग सब संभव है। लेकिन असली सवाल है, "यह कितना कठिन है?" या "हमें यह करना ही क्यों है?"। मुझे अब भी लगता है कि सिर्फ़ iteration और तरह-तरह की चीज़ें ship करने की क्षमता नहीं, बल्कि सार को देखना ज़्यादा अहम है
  • आपने मेरे मन की बात कह दी। मुझे भी AI को देखते-देखते manage करने वाला काम बिल्कुल पसंद नहीं है। ऊपर से यह AI-based coding जिस तरह ऐसी दुनिया को सामान्य बना रही है जहाँ बिना किसी अप्रमाणित, रहस्यमय बड़े tech company account के काम ही नहीं हो सकता, वह भी डरावना है
  • चिंता करने की ज़रूरत नहीं है। मैं अभी अपनी टीम के एक junior engineer को mentor कर रहा हूँ। उसे code improve करना बहुत मुश्किल लगता है, क्योंकि अगर चीज़ चल रही है तो वह उसी से संतुष्ट हो जाता है। structure अच्छा नहीं है, और छोटे-छोटे problems या security issues हर कोने में छिपे हैं। सिर्फ़ 3 Python files में भी यह सब हो रहा है। हमारी टीम में 10 developers हैं, और जब सब LLM साथ इस्तेमाल करते हैं तो experience के फ़र्क के हिसाब से code quality का अंतर और बढ़ जाता है। आधिकारिक रूप से LLM अपनाने से पहले के 6 महीनों में मेरा अनुभव यही रहा कि junior, senior और experienced लोगों के बीच का gap वास्तव में और बड़ा हो जाता है। यह Simon की राय से मिलता-जुलता है
  • मूल बात बस इतनी है कि जिसके पास ज्ञान है, वही tools से और अधिक ताकत पाता है — उल्टा नहीं
• GPT-4 के रिलीज़ के आसपास, 2023 की शुरुआत में, translation industry में भी ऐसा ही बदलाव आया था। English-Japanese translation में, जो मेरा कार्यक्षेत्र रहा है, machine translation पहली बार मानव स्तर के काफ़ी करीब पहुँच गई। उस समय मैंने कई professional translators के साथ इस पर बहस की, और यहाँ की तरह बहुत लोगों ने निराशा जताई कि कहीं कठिन translation skills का महत्व ही खत्म न हो जाए। कई लोगों की प्रतिक्रिया यह थी कि अगर LLM को सहायक की तरह इस्तेमाल करें तो प्रक्रिया का चुनौतीपूर्ण आनंद भी खत्म हो जाता है। जिन translators से मैं मिला, वे ज़्यादातर freelancers थे और हर वाक्य को सावधानी से अनुवाद करने वाले लोग थे। वे बड़े translation projects के manager बनना नहीं चाहते थे, और भले ही वे उच्च स्तर की cultural/contextual communication skills इस्तेमाल कर सकते थे, फिर भी उसमें प्रेरणा कम थी। मैं इस समय बहुत translation काम नहीं करता, लेकिन AI की प्रगति को लगातार देखता हूँ और कभी-कभी translation tasks से models की तुलना करके test करता हूँ। आजकल मैं ऐसे multi-LLM based translation system पर प्रयोग कर रहा हूँ जिसमें कई LLM एक-दूसरे के translation को cross-check और improve करते हैं। कुछ documents में परिणाम वास्तव में top-tier human translation के लगभग समान आते हैं। API cost सस्ती नहीं थी, लेकिन महत्वपूर्ण translation के लिए उस पर खर्च करना पूरी तरह सार्थक था। ऐसे "vibe translation" system को design करते समय, translator के रूप में मेरा अनुभव साफ़ तौर पर काम आया। यह Simon के कहे vibe engineering से मिलता-जुलता है। मेरी मौजूदा उम्र (68) में यह मुझे ठीक लगता है, लेकिन अगर LLM वगैरह मेरे करियर के शुरुआती दौर, यानी 5–10 साल के अनुभव के समय आ गए होते, तो शायद मैं translator का पेशा छोड़ देता
  • translation की बात LLM चर्चा के लिए सचमुच अच्छा उदाहरण है, अनुभव साझा करने के लिए धन्यवाद। दूसरी ओर, ज़्यादातर लोग translators को बहुत गहरी क़ीमत नहीं देते। उदाहरण के लिए, किसी किताब का अनुवाद किसने किया, यह लगभग किसी को याद नहीं रहता। आजकल लोग पहले जितनी किताबें पढ़ते भी नहीं, इसलिए यह और अधिक सच हो सकता है। इसी वजह से परंपरागत रूप से translation का contract/payment अक्सर शब्दों या पंक्तियों की संख्या से तय होता रहा है, कुछ-कुछ software security की तरह जिसे अंतिम check की तरह लिया जाता है। translation का जो क्षेत्र सच में भविष्य में प्रतिस्पर्धी बना रह सकता है, वह शायद legal translation है, क्योंकि वहाँ मुक़दमे या liability इंसानों पर आती है, या फिर simultaneous interpretation/on-site interpretation, क्योंकि वहाँ आमने-सामने और वास्तविक मुलाक़ात की ज़रूरत होती है
• आजकल tech community में "coding तेज़ हो रही है और productivity बढ़ रही है" वाले दावे कुछ ज़्यादा ही धकेले जा रहे हैं, जो थोड़ा अजीब लगता है। माहौल ऐसा है मानो बस तेज़ result ही सबसे अहम हो। मेरे अनुभव में LLM अक्सर बिखरा हुआ, दोहराव भरा code निकालते हैं। हाँ, वे मुझसे तेज़ हो सकते हैं, लेकिन फिर भी मुझे लगता है कि मेरा धीरे लिखा code उनसे कहीं बेहतर होता है। आजकल हर चीज़ पर जल्दी chat करके जल्दी result निकालने और जल्दी production तक पहुँचाने का जो माहौल है, वही पहले ढीले-ढाले web products की बाढ़ का कारण था। vibe coding/engineering जैसी चमकदार शब्दावली से आगे बढ़कर हमें गंभीरता से पूछना चाहिए कि आख़िर इतनी low-quality होते हुए भी speed की इतनी ज़रूरत क्यों है, और automation/process खुद और बेहतर क्यों नहीं किए जा सकते। उदाहरण के लिए, unit tests बहुत तेज़ी से बनाए जा सकते हैं, लेकिन पहले यह पूछना चाहिए कि आखिर इतने सारे unit tests की ज़रूरत क्यों पड़ रही है। ज़रूरत तो है, लेकिन ऐसा लगता है कि abstraction यानी ऊपरी दृष्टिकोण आगे बढ़ रहा है, जबकि निचले tools यानी बारीक स्तर के औज़ारों की प्रगति धीमी है
  • software engineering की बहस की मूल समस्या यह है कि tools और languages ऊपर से एक जैसी दिखती हैं, लेकिन वास्तव में tolerance, security, compliance और maintainability standards में बहुत बड़ा फ़र्क होता है। कोई व्यक्ति बस एक simple prototype जल्दी बनाता है, जबकि कोई दूसरा 10 साल की long-term roadmap या sensitive data पर काम करता है। जब ये दोनों दृष्टिकोण आपस में मिल जाते हैं, तो एक तरफ़ "तेज़ बनाना ही क्षमता है" वाला नज़रिया बनता है और दूसरी तरफ़ "इससे बहुत बुरा नतीजा निकलेगा" वाली चिंता भी साथ रहती है। दोनों पक्ष पूरी तरह ग़लत नहीं हैं, लेकिन चर्चा में वास्तविक काम का context और risk level लगभग हर बार अनदेखा रह जाता है
  • व्यावहारिक रूप से देखा जाए तो LLM development speed में बहुत बड़ी मदद करते हैं, यह सच है। मैं पाँचवीं कक्षा से code लिख रहा हूँ और 20 साल से ज़्यादा हो गए, और आसपास के लोग भी मेरी speed मानते हैं, लेकिन LLM अपनाने के बाद मेरा scale बहुत बढ़ गया है। खेल का मैदान पहले ही बदल चुका है; अब सवाल सिर्फ़ यह है कि आप adapt करते हैं या नहीं। भविष्य की अनिश्चितता से मुझे भी बहुत शिकायतें हैं, लेकिन अगर कोई engineer ऐसी ही स्थिति में है, तो मैं उसकी भावना पूरी तरह समझ सकता हूँ
  • मैं यह तर्क रखने की कोशिश करूँगा कि software development में speed इतनी महत्वपूर्ण क्यों है। मेरा दावा ज़रूरी नहीं कि सही हो, और न ही मेरे पास कोई वास्तविक data है। terminology की परिभाषाएँ भी अस्पष्ट हो सकती हैं। फिलहाल "trivial software" से मेरा मतलब ऐसा software है जिसकी value और solution सबको साफ़ पता हो, जिसे automatically verify किया जा सके, या जिसे लागू करने का सिर्फ़ एक ही तरीका हो। लेकिन वास्तविक दुनिया का ज़्यादातर software non-trivial होता है। उसमें हमेशा bugs, missing requirements, leaking abstractions, useless features, integration issues, performance problems, security issues, complexity और maintenance headaches पैदा होते हैं। चाहे developer कितना भी बेहतरीन हो, चाहे code कितना भी अच्छा लिखा गया हो, ये समस्याएँ टलती नहीं हैं। ये समस्याएँ सिर्फ़ बार-बार feedback, वास्तविक उपयोग, maintenance और अनगिनत experiments के दौरान सामने आती हैं और धीरे-धीरे सुधरती हैं। यानी code को एक ही बार में perfect नहीं बनाया जा सकता; कई iterations के बाद उसकी quality बेहतर होती है। पूरे software की quality इस "feedback loop" की मात्रा से नियंत्रित होती है। एक loop पूरा करने में जितना समय लगता है, कुल iterations की संख्या भी उतनी ही सीमित हो जाती है। अंततः, जितनी तेज़ production speed होगी, उतने ज़्यादा feedback loops का अनुभव होगा, और उतना ही बेहतर software विकसित हो सकेगा। धीमा लेकिन high-quality code भी अगर सिर्फ़ एक iteration तक सीमित रहे तो उसकी भी सीमा है; उल्टा, अगर quality कम हो लेकिन iterations अनगिनत हों, तो बेहतर नतीजे तक पहुँचना संभव हो सकता है
  • 5 साल बाद यह दुनिया की सबसे बड़ी sunk cost fallacy का उदाहरण लग सकता है
• मुझे लगता है "vibe coding" की बजाय "agentic coding" या "agentic software engineering" जैसे नाम ज़्यादा उपयुक्त हैं। मेरा development flow Claude के code plan से शुरू होता है, और पहले कदम पर मैं हमेशा साफ़ spec बनाता हूँ। मैं TDD का उपयोग करता हूँ और अपने तय किए हुए छिपे code quality rules को automation tools से enforce कराता हूँ। उदाहरण के लिए, अगर design system से विचलन हो तो code commit नहीं होता, और यह भी automated check है कि HTTP handler को अनिवार्य रूप से service layer से होकर जाना चाहिए। मैं model को समय-समय पर याद दिलाता हूँ कि TDD ठीक से follow करे, और Claude 4.5 यह Claude 4.1 से कहीं बेहतर याद रखता है। TDD की वजह से PR code review भी बहुत आसान हो जाता है। मैंने एक simple tool भी बनाया है जो PR और spec को Gemini को देकर mismatch, omissions और errors को अपने-आप point out कर देता है। यह अच्छा backup tool है। लेकिन अंततः सबसे ज़रूरी क्षमता यह है कि मैं जो result चाहता हूँ, उसे स्पष्ट जानूँ, और agent कहाँ भटक रहा है यह खुद पहचान सकूँ। आखिरकार, "low-quality input से low-quality output, high-quality input से high-quality output" ही सच है
  • आपने कहा कि आप model को TDD याद दिलाते हैं, तो क्या vibe coding में agent सचमुच TDD के red-green-refactor loop को बार-बार execute करता है? या वह एक ही बार में पूरा result निकाल देता है?
  • vibe based जैसे नाम की जगह मुझे "slop-coding" ज़्यादा उपयुक्त लगता है
• मुझे संदेह है कि "vibe engineering" नाम सच में सही है या नहीं। व्यवहार में तो इसका मतलब agents पर automated tests, upfront planning, detailed documentation, code formatting/lint, manual QA जैसी हर तरह की constraints लगाना है। मैंने भी Karpathy की पोस्ट पढ़कर vibe coding शुरू की थी और शुरुआत में यह अनुभव किया कि code रुक जाए तब भी कई बार rerun करके पूरे process पर भरोसा किया जा सकता है। लेकिन अनुभव बढ़ने पर समझ आया कि आखिरकार model को control करना ही पड़ता है। agents चलाना kart racing जैसा है; track के किनारे लगे tires की तरह कई constraints लगाने पड़ते हैं। Constraint Harness ही असली चीज़ है, और code खुद generate/regenerate करना आसान होता जा रहा है। आगे चलकर महत्वपूर्ण काम यह होगा कि AI के output के लिए अच्छे tests और constraints तैयार किए जाएँ
  • "vibe engineering" नाम बहुत हल्का है और गंभीर नहीं लगता। "LLM-assisted programming" जैसा कोई ज़्यादा neutral और वास्तविक कार्य को दर्शाने वाला शब्द बेहतर नहीं होगा? असर भले कम हो
• "upfront planning" को spec-driven development भी कहा जा सकता है। सच तो यह है कि हर development किसी न किसी रूप में पहले से तय specification पर ही आधारित होता है। लेकिन असली बात है "एक बहुत अजीब तरह का management" — यानी स्पष्ट निर्देश, पर्याप्त context, और actionable feedback देना। सिर्फ़ text में देखने पर यह agile की तुलना में waterfall के ज़्यादा क़रीब लगता है
• अब लगता है कि vibe-coding शब्द का अर्थ फैलकर पूरे AI-based coding को ही समेटने लगा है। वास्तव में जब मैं AI के साथ काम करता हूँ तो वह pair programming के ज़्यादा क़रीब लगता है, और सच में "मैं vibe कर रहा हूँ" जैसी भावना आती है। फिर भी, "Take the wheel, LLama of God" जैसी मूल, पूरी तरह छोड़ देने वाली vibe-coding भी अब भी काफ़ी इस्तेमाल होगी, इसलिए उसके लिए अलग शब्द चाहिए। मैं “Yolo-Coding” का प्रस्ताव देना चाहूँगा। यह no-code, low-code, yolo-code वाली धारा से भी मेल खाता है
  • मुझे लगता है कि vibe coder के साथ no-code जैसी नकारात्मक छवि बनी रहना बेहतर है। vibe engineer शब्द मुझे भी पसंद नहीं, लेकिन जैसा भी हो, आगे चलकर engineer/developer नाम का अर्थ ही agent इस्तेमाल करना मान लिया जाएगा, और "हाथ से" development करने वाले लोग अपवाद बन सकते हैं
  • $enterprise में हम "responsible vibing" और "YOLO vibe coding" में अंतर बताने के लिए नया नाम ढूँढ रहे थे, और अंत में "agent assisted coding" शब्द पर पहुँचे, क्योंकि तीन अक्षरों वाला acronym होना ज़रूरी है
  • "vibe coding" का मूल अर्थ Ilya Sutskever की Twitter पोस्ट जैसा है: बस prompt डालो, result को बिना review copy-paste करके चला दो — बिना analysis या verification के
  • मेरे हिसाब से AI-assisted coding ज़्यादा से ज़्यादा autocomplete या खराब documentation पढ़ने में सहायता देने जैसा है, जबकि vibe coding में
  • developer, LLM द्वारा लिखा code बिल्कुल नहीं समझता
  • code review के बिना तुरंत technical debt पैदा होती है
  • और क़ानूनी रूप से copyright protection के लिहाज़ से EU/US में यह पूरी तरह कमज़ोर है मेरा मानना है कि vibe coding की सबसे घातक समस्या यह है कि LLM द्वारा बनाया गया code मूल रूप से protect/register नहीं किया जा सकता। UK जैसे कुछ अपवाद हैं, लेकिन ज़्यादातर देशों में यह लगभग निराशाजनक स्थिति है
  • मैंने भी claude में /yolo जैसा slash command बनाकर बिना किसी खास guidance के बस उसे चलाकर देखा है
• एक प्रयोग है जिसमें कबूतर किसी ऐसी मशीन के साथ interact करते हैं जो random तरीके से खाना देती है, और वे यह मान लेते हैं कि इनाम उनकी अपनी हरकतों की वजह से मिल रहा है, इसलिए तरह-तरह के मज़ेदार dance और movements दोहराते रहते हैं
  • हो सकता है वे मज़ेदार dance वास्तव में "tests लिखने" या "planning करने" जैसी चीज़ों से मिलते-जुलते हों
  • क्या इसके समर्थन में कोई paper वगैरह है? "मज़ेदार कबूतर" खोजने पर सिर्फ़ social media videos मिलते हैं, इसलिए ढूँढना मुश्किल हो रहा है
• "Augmented Engineering" (AE) नाम बेहतर है। AI की ताकत से capabilities बढ़ाई जा सकती हैं और सर्वोत्तम result निकाले जा सकते हैं, इसलिए यह "augmented engineering" है। AE को "Advanced Engineering" भी समझा जा सकता है। AI हमें तुरंत latest technical knowledge तक पहुँचा देता है, इसलिए यह स्वाभाविक रूप से अधिक advanced engineering है। इसके मुकाबले vibe शब्द अच्छा नहीं लगता
  • terminology को लेकर इतना चिंतित होने की ज़रूरत नहीं है। अलग naming करने से उल्टा ऐसा लग सकता है कि AI coding सिर्फ़ कुछ developers की चीज़ है। आगे चलकर पारंपरिक coding अपवादात्मक तरीका बन जाएगी, और आज का vibe जैसा शब्द भी जल्द गायब हो जाएगा
  • आख़िरी वाक्य पर मुझे आपत्ति है। AI सिर्फ़ latest engineering knowledge को समझने का माध्यम नहीं है; उसमें पिछले 1–10 वर्षों की बार-बार दोहराई गई गलतियाँ, errors, misunderstandings और design flaws भी "तुरंत" समा सकते हैं। यानी AI द्वारा दी गई जानकारी पर कभी भी बिना आलोचनात्मक नज़र के भरोसा नहीं करना चाहिए, स्रोत अवश्य जाँचना चाहिए, और यह भी देखना चाहिए कि वह स्रोत खुद AI-generated तो नहीं है। datasets लगातार polluted हो रहे हैं, इसलिए और भी सावधान रहना होगा
  • मैं पूछना चाहता हूँ कि क्या "Augmented Engineering" को सचमुच अलग नाम होना चाहिए? वह बस "engineering" ही तो है। जैसे reference book देखकर काम करने को हम "book-assisted engineering" नहीं कहते, वैसे ही vibe के साथ भी है। चाहें तो मज़ाक में इसे "Yolo engineering" या "Machine Outsourced Irresponsible LMAO Engineering" भी कह सकते हैं। आख़िर में "Advanced Engineering" भी मुझे कुछ बढ़ा-चढ़ाकर कहा गया लगता है
• Simon हमेशा ठीक निशाने पर बात करते हैं, लेकिन असली समस्या "coding" से ज़्यादा "vibe" शब्द है। उसे vibe engineering कह देने पर भी उसमें यह अर्थ बना रहता है कि "बिना यह जाने कि क्या कर रहे हो, बस आगे बढ़ते जाना"। इसकी तुलना में "AI-assisted software engineering" जैसा शब्द बेहतर लगता है, क्योंकि वह दोनों छोरों को अधिक स्पष्ट रूप से अलग करता है

[kimjoin2]

बेमतलब नाम गढ़ना;