वाइब कोडिंग से प्रोडक्शन तक
AI एक वीकएंड में प्रोडक्ट ड्राफ्ट कर सकता है। प्रोडक्शन को अभी भी ओनरशिप, टेस्ट्स, और done की बेरहम परिभाषा चाहिए। यहाँ ऑपरेटर स्प्लिट है।
← Guides All guides in this topic
वाइब कोडिंग किस चीज़ के लिए अच्छा है
वाइब कोडिंग का मतलब है AI कोडिंग एजेंट को इरादे और टेस्ट के साथ स्टीयर करना, फॉर्मल स्पेक से ज़्यादा: Cursor, Claude Code, Copilot, Windsurf, और दोस्त। यह स्पाइक्स, इंटरनल टूल्स, क्लीयर बिफोर और आफ्टर वाली माइग्रेशन्स, UI स्कैफोल्डिंग, और बोरिंग ग्लू कोड के लिए शानदार है जिसे आप टाइप नहीं करना चाहते।
यह भी है कि कैसे बहुत सारे फाउंडर्स अभी प्रोडक्ट्स शुरू करते हैं। यह ठीक है। फेल्योर मोड है ग्रीन लोकल डेमो को प्रोडक्शन सिस्टम की तरह ट्रीट करना। यूजर्स, पेमेंट्स, ऑथ, SEO, एक्सेसिबिलिटी, और on-call रियलिटी इस बात की परवाह नहीं करते कि एजेंट तेज़ महसूस हुआ।
की टेकअवे: वाइब कोडिंग का इस्तेमाल एक्सप्लोर करने और एक्सेलरेट करने के लिए करें। जनरेशन की स्पीड को कस्टमर्स को सर्व करने की रेडीनेस से न मिलाएँ।
यह प्रोडक्शन में कहाँ ब्रेक करता है
जब AI-built apps को असली ट्रैफ़िक का सामना होता है तो मुझे ये पैटर्न दिखते हैं:
आर्किटेक्चर की कोई जिम्मेदारी नहीं
एजेंट खुशी से डेटा फेचिंग के लिए तीसरा पैटर्न बना देगा क्योंकि प्रॉम्प्ट में इसे मना नहीं किया गया था। छः हफ्ते बाद कोई नहीं जानता कि कौन सा पैटर्न canonical है।
Happy-path auth और payments
लॉगिन demo account पर काम करता है। Edge cases, session expiry, webhook retries, और permission checks तब तक फिक्शन हैं जब तक कोई इंसान इन्हें डॉक्यूमेंट न करे और टेस्ट न करे।
अदृश्य performance और SEO debt
Client-rendered shells, unbounded images, और missing metadata ship होते हैं क्योंकि एजेंट ने "यह Chrome में सही दिखता है" के लिए optimize किया था।
Secret और env sprawl
Chat logs में keys, .env के उदाहरण जो असली हैं, और preview deployments जो production databases से बात करते हैं।
मुख्य बात: vibe coding के बाद production failures आमतौर पर model IQ नहीं, बल्कि ownership और edge cases की वजह से होती हैं।
वो सुरक्षा व्यवस्था जो इसे शिप करने योग्य बनाती हैं
| Guardrail | Why it matters | Minimum bar |
|---|---|---|
| Written definition of done | Stops demo theatre | Auth, payments, empty states, error states listed |
| Thin vertical slice first | Proves the risky path | One real user journey in staging with real data shape |
| Human review on critical paths | Agents miss incentives | Auth, billing, migrations, public SEO routes |
| Automated checks | Catches regressions agents reintroduce | Typecheck, lint, smoke tests, CWV on key templates |
| Observability | You cannot fix what you cannot see | Error tracking + basic product analytics before launch |
| Rollback plan | Fast generation needs fast undo | Migrations reversible, feature flags for risky UI |
Seahawk के अंदर हम agents को आक्रामक जूनियर्स मानते हैं जिनकी टाइपिंग स्पीड अनंत है। वे ड्राफ्ट करते हैं। Architecture, security, और release decision पर अभी भी मनुष्य का मालिकाना हक है। उस लंबे वर्कफ़्लो के लिए जो हम Claude के साथ जानबूझकर बिल्डिंग करते समय इस्तेमाल करते हैं, Claude spec-driven workflow guide और custom software pillar देखें।
मुख्य बात: Agent को खोलने से पहले done list लिख दें। खतरनाक रास्तों का खुद जांच करें।
एक व्यावहारिक लूप जो हम इस्तेमाल करते हैं
1. User job को एक पैराग्राफ में बताएं। 2. Non-negotiables की लिस्ट बनाएं (auth provider, CMS, hosting, accessibility, SEO)। 3. Agent को उस लिस्ट के खिलाफ scaffold करने दें। 4. उसी दिन unhappy paths पर ऐप चलाएं। 5. उन clever abstractions को डिलीट करें जो agent ने बनाए हैं लेकिन आपने मांगे नहीं। 6. Tests सिर्फ वहीं जोड़ें जहां breakage महंगा पड़े। 7. एक narrow slice ship करें। 8. तभी स्कोप बढ़ाएं।
अगर स्टेप 4 लगातार दो बार फेल हो जाए, तो prompting बंद करें और एक short spec लिखें। एक tightening loop के बिना vibe coding prompt churn बन जाता है।
मुख्य बात: Generation को adversarial use के साथ बारी-बारी से करें। अगर आप सिर्फ हमेशा vibe forward ही करते हैं, तो आप सिर्फ हमेशा demo ही करते हैं।
कब core को vibe code न करें
Agent को billing ledger, permission model, या data migrations को freestyle न करने दें अगर सिस्टम के पास पहले से ही customers हैं। Production information architecture के redesign को बिना map के vibe-code न करें। Threat modelling को chat window को आउटसोर्स न करें।
Admin screen CRUD को vibe-code करें, वह script जो assets के folder का नाम बदलती है, first version of an internal dashboard को, और migration PR को एक बार जब इंसान ने schema change को specify कर दिया हो।
मुख्य बात: एजेंट्स को अपरिवर्तनीय पैसे, परमिशन्स और डेटा स्ट्रक्चर से दूर रखें जब तक कोई इंसान नियम सेट न कर दे।
निचली लाइन
Vibe coding एक लीवरेज टूल है, डिलीवरी मेथडोलॉजी नहीं। 2026 में जीतने वाली टीमें एजेंट्स का रोज़ इस्तेमाल करती हैं और स्टैंडअप में फिर भी बोरिंग लगती हैं: definition of done, critical paths पर रिव्यू, फील्ड परफॉर्मेंस, और रोलबैक प्लान।
अगर आप AI-स्पीड प्रोटोटाइप को कुछ ऐसा बनाने में मदद चाहते हैं जिस पर आप कस्टमर्स रख सकें, तो यह अब नॉर्मल एजेंसी का काम है। रेपो और डन लिस्ट लेकर आओ। डेमो कॉन्फिडेंस दरवाज़े पर छोड़ दो।
मुख्य बात: वह स्लाइस शिप करो जिसे तुम ऑपरेट कर सकते हो, वह डेमो नहीं जिसने तुम्हें शुक्रवार की रात को इम्प्रेस किया।
यह spec-driven Claude काम से कैसे अलग है
Spec-driven काम एक लिखित कॉन्ट्रैक्ट से शुरू होता है: entities, routes, acceptance checks, फिर एजेंट गैप्स को भरता है। Vibe coding टेस्ट और एक प्रॉम्प्ट से शुरू होता है और तब तक एक कॉन्ट्रैक्ट में सख़्त होता है जब तक reality वापस न धकेले। दोनों वैलिड हैं। गलती यह है कि vibe coding को किसी ऐसी सतह पर इस्तेमाल करना जिसे पहले से ही कॉन्ट्रैक्ट चाहिए था।
नियम का अंगूठा: greenfield spike या इंटरनल टूल, vibe पहले। Multi-tenant प्रोडक्ट, पेमेंट्स, या मौजूदा ट्रैफिक वाली पब्लिक SEO सतह, spec पहले। हमारी Claude spec-driven workflow गाइड दूसरे रास्ते को विस्तार में कवर करती है। यह गाइड पहले रास्ते का है प्रोडक्शन ब्रेक्स के साथ।
मुख्य बात: डिस्कवर करने के लिए vibe करो। हार्डन करने के लिए spec करो। हैंडऑफ को स्किप मत करो।