आपने अपने एमवीपी को वाइब-कोड किया है। अब आप फंस गए हैं.

आपने कुछ वास्तविक बनाया है। आपने Lovable या Bolt.new खोला, अपने विचार को सादे अंग्रेजी में वर्णित किया, और मिनटों में एक कार्यशील ऐप देखा। आपने स्क्रीन पर क्लिक किया। आपने इसे दोस्तों को दिखाया. आपने इसे एक्स पर पोस्ट किया और अपना पहला उत्तर "यह बीमार है" प्राप्त किया। यह प्रभावशाली है, और आपको इसके बारे में अच्छा महसूस करना चाहिए।

लेकिन अब आप तीन सप्ताह में हैं, और गति रुक ​​गई है। आप नई सुविधाएँ बनाने की तुलना में टूटी हुई सुविधाओं को ठीक करने में अधिक समय व्यतीत कर रहे हैं। आपके सुपाबेस डैशबोर्ड में ऐसी तालिकाएँ हैं जिन्हें आप पूरी तरह से नहीं समझते हैं। आपका प्रमाणीकरण डेस्कटॉप पर काम करता है लेकिन मोबाइल पर टूट जाता है। आपको स्ट्राइप एकीकरण की आवश्यकता है, और आपके द्वारा प्रयास किया जाने वाला प्रत्येक संकेत कोड उत्पन्न करता है जो पहले से मौजूद चीज़ों के साथ टकराव करता है।

आपने दीवार पर प्रहार किया है. और आप अकेले नहीं हैं.

80/20 दीवार: जहां वाइब कोडिंग टूट जाती है

लवएबल, बोल्ट.न्यू, रेप्लिट एजेंट और वी0 जैसे वाइब कोडिंग टूल किसी उत्पाद के पहले 80% में असाधारण हैं। वे यूआई घटक उत्पन्न करते हैं, डेटाबेस को तार-तार करते हैं, प्रमाणीकरण प्रवाह बनाते हैं, और कुछ ऐसा तैयार करते हैं जो वास्तविक ऐप की तरह दिखता और महसूस होता है। प्रोटोटाइपिंग और सत्यापन के लिए, वे विचार से डेमो तक का अब तक का सबसे तेज़ रास्ता हैं।

समस्या आखिरी 20% है। यहीं पर किनारे के मामले रहते हैं। यहीं पर भुगतान प्रसंस्करण को विफल शुल्क, आंशिक धनवापसी और वेबहुक पुनर्प्रयास को संभालने की आवश्यकता होती है। यहीं पर आपके मल्टी-स्टेप फॉर्म को प्रगति को सहेजने, सभी चरणों में सत्यापित करने और ब्राउज़र क्रैश से उबरने की आवश्यकता होती है। जब दो उपयोगकर्ता एक ही समय में एक ही रिकॉर्ड संपादित करते हैं तो आपके ऐप को यहीं काम करने की आवश्यकता होती है।

एआई खुशहाल रास्ते को शानदार ढंग से संभालता है। यह नाखुश रास्तों से संघर्ष करता है, और उत्पादन सॉफ्टवेयर 80% नाखुश रास्ते हैं। क्या होता है जब लेन-देन के बीच में नेटवर्क बंद हो जाता है? जब कोई उपयोगकर्ता एक फॉर्म दो बार सबमिट करता है? जब आपकी डेटाबेस क्वेरी 50 के बजाय 50,000 पंक्तियाँ लौटाती है? ये वे प्रश्न हैं जो डेमो को किसी उत्पाद से अलग करते हैं, और ये वे प्रश्न हैं जिनका उत्तर वाइब कोडिंग टूल एक संकेत से नहीं दे सकते हैं।

डेवलपर्स इसे 80/20 दीवार कहते हैं। पहले 80% में 20% प्रयास लगता है। अंतिम 20% में 80% प्रयास लगता है। वाइब कोडिंग टूल उस पहले 80% को हफ्तों से घंटों तक संपीड़ित करते हैं। लेकिन वे अंतिम 20% को बिल्कुल भी संपीड़ित नहीं करते हैं। वे इसे कठिन बनाते हैं, क्योंकि जो कोड उन्होंने उत्पन्न किया था वह इसे संभालने के लिए डिज़ाइन नहीं किया गया था।

सुरक्षा समस्या के बारे में कोई बात नहीं करता

यहां वह हिस्सा है जो आपको रात में जगाए रखेगा। लवेबल-जनरेटेड एप्लिकेशन के सुरक्षा विश्लेषण से यह पता चला10.3% में गंभीर पंक्ति-स्तरीय सुरक्षा (आरएलएस) खामियां थींउनके सुपाबेस डेटाबेस में। इसका मतलब है कि दस में से एक ऐप में डेटाबेस टेबल थे जहां कोई भी प्रमाणित उपयोगकर्ता अन्य उपयोगकर्ताओं के डेटा को पढ़ सकता था, संशोधित कर सकता था या हटा सकता था। सैद्धांतिक जोखिम नहीं. एक कामकाजी शोषण.

यह लवेबल तक सीमित नहीं है। 470 पुल अनुरोधों के कोडरैबिट विश्लेषण में पाया गया कि एआई-जनरेटेड कोड है2.74 गुना अधिक सुरक्षा भेद्यता दरमानव-लिखित कोड की तुलना में। वैसा ही विश्लेषण पाया गया1.7 गुना अधिक प्रमुख मुद्देकुल मिलाकर। AI कोड लिखता है जो काम करता है। यह ऐसा कोड नहीं लिखता जो सुरक्षित हो।

वास्तविक दुनिया के परिणाम पहले से ही यहाँ हैं। मोल्टबुक, एक एआई-निर्मित सोशल नेटवर्क, अपने सुपाबेस डेटाबेस के साथ सार्वजनिक रूप से सुलभ लॉन्च किया गया। परिणाम:1.5 मिलियन एपीआई कुंजियाँ और 35,000 उपयोगकर्ता ईमेल उजागर. एक स्वतंत्र ऑडिट में यह पाया गया11% इंडी लॉन्च यूआरएल अपने फ्रंटएंड कोड में सुपाबेस क्रेडेंशियल्स को उजागर करते हैं. ये किनारे के मामले नहीं हैं. वे पैटर्न हैं.

वाइब कोडिंग टूल आपको सुरक्षा के बारे में नहीं समझाते क्योंकि आपने सुरक्षा के बारे में नहीं पूछा था। आपने उपयोगकर्ता पंजीकरण फॉर्म मांगा और आपको एक मिल गया। आपने यह नहीं पूछा कि "सुनिश्चित करें कि उपयोगकर्ता सीधे एपीआई कॉल के माध्यम से एक-दूसरे के डेटा तक नहीं पहुंच सकते हैं," इसलिए टूल ने इसे सेट नहीं किया। आरएलएस नीतियां, एपीआई कुंजी स्कोपिंग, इनपुट सैनिटाइजेशन, दर सीमित करना; ये ऐसी चीजें हैं जिन्हें अनुभवी इंजीनियर डिफ़ॉल्ट रूप से जोड़ते हैं क्योंकि उन्होंने देखा है कि जब आप ऐसा नहीं करते हैं तो क्या होता है।

क्रेडिट बर्न जाल

वाइब कोडिंग टूल क्रेडिट, टोकन या गणना समय के आधार पर शुल्क लेते हैं। पिच सरल है: आप जो चाहते हैं उसका वर्णन करें, कार्यशील कोड प्राप्त करें, पुनरावृत्त करें। हकीकत अलग है.

प्यारे उपयोगकर्ताओं की रिपोर्टएक घंटे से भी कम समय में 400 क्रेडिट ख़त्म करनाकिसी जटिल सुविधा को डीबग करते समय। Bolt.new उपयोगकर्ता इसमें फंसने का वर्णन करते हैंअंतहीन त्रुटि चक्रजहां एआई एक चीज को तोड़ता है जबकि दूसरी को ठीक करता है। सभी प्लेटफार्मों पर, उपयोगकर्ता खर्च की रिपोर्ट करते हैंउनके 30-40% संकेत एआई द्वारा खराब की गई चीजों को ठीक करने के लिए दिए गएपिछले संकेतों में.

उस अनुपात के बारे में सोचो. आपके उत्पाद को आगे बढ़ाने वाले प्रत्येक तीन संकेतों में से एक या दो संकेत क्षति को ठीक करने की ओर जाते हैं। आप प्रगति करने के लिए भुगतान कर रहे हैं और गंदगी को साफ़ करने के लिए फिर से भुगतान कर रहे हैं। जो उपकरण आपका पैसा बचाने वाला था, वह अब घटते रिटर्न के साथ आवर्ती लागत बन गया है।

जैसे-जैसे आपका कोडबेस बढ़ता है, क्रेडिट बर्न तेज हो जाता है। एआई के लिए 500-लाइन वाले ऐप के बारे में तर्क करना आसान है। एकाधिक पृष्ठों, साझा स्थिति, एपीआई मार्गों और डेटाबेस माइग्रेशन वाला 5,000-लाइन ऐप नहीं है। एआई संदर्भ खोने लगता है। यह आपके द्वारा पहले से तय किए गए घटकों को फिर से लिखता है। यह उन पैटर्न का परिचय देता है जो तीन संकेत पहले उपयोग किए गए पैटर्न के साथ संघर्ष करते हैं। आप कम प्रगति के लिए अधिक क्रेडिट खर्च करते हैं, और हर सत्र के साथ अंतर बढ़ता जाता है।

कोड गुणवत्ता सर्पिल

एआई-जनरेटेड कोडबेस समस्याओं का एक विशिष्ट सेट साझा करते हैं जो समय के साथ जटिल होते जाते हैं।

कोड दोहराव.वाइब-कोडित परियोजनाओं के विश्लेषण से पता चलता हैकोड दोहराव में 8 गुना वृद्धिमानव-इंजीनियर्ड परियोजनाओं की तुलना में। एआई को यह याद नहीं है कि उसने तीन फ़ाइल पहले ही दिनांक स्वरूपण फ़ंक्शन लिख दिया था। यह एक नया लिखता है. फिर एक और। फिर थोड़ा अलग. अब आपके पास चार दिनांक फ़ॉर्मेटर हैं, जिनमें से प्रत्येक का व्यवहार अलग-अलग है, और आपके ऐप में दिनांक प्रदर्शन बदलने का अर्थ है चारों को ढूंढना और अपडेट करना।

असंगत पैटर्न.प्रॉम्प्ट-दर-प्रॉम्प्ट विकास वास्तुशिल्प स्थिरता के बिना कोड उत्पन्न करता है। एक पेज यूज़इफ़ेक्ट हुक में डेटा लाता है। दूसरा सर्वर-साइड रेंडरिंग का उपयोग करता है। तीसरा व्यक्ति सीधे ऑनक्लिक हैंडलर से एपीआई को कॉल करता है। इनमें से कोई भी दृष्टिकोण अलगाव में गलत नहीं है, लेकिन तीनों को एक ऐप में मिलाने से एक कोडबेस बनता है जिसके बारे में कोई भी तर्क नहीं कर सकता है; एआई नहीं, और कोई मानव डेवलपर नहीं जिसे आप बाद में नियुक्त करते हैं।

त्रुटि प्रबंधन गुम है.एआई-जनरेटेड कोड सफलता के मामले को संभालता है। जब एपीआई 200 लौटाता है तो यह डेटा प्रस्तुत करता है। यह संभाल नहीं पाता है कि जब एपीआई 500 लौटाता है, या समय समाप्त हो जाता है, या विकृत JSON लौटाता है तो क्या होता है। उत्पादन उपयोगकर्ता इन विफलता मोड को प्रतिदिन ट्रिगर करते हैं। त्रुटि प्रबंधन के बिना, आपका ऐप खाली स्क्रीन, अनंत स्पिनर, या गुप्त त्रुटि संदेश दिखाता है जो उपयोगकर्ताओं को सीधे आपके प्रतिस्पर्धी के पास भेजते हैं।

कोई परीक्षण नहीं.जब तक आप विशेष रूप से न पूछें, वाइब कोडिंग टूल शायद ही कभी परीक्षण उत्पन्न करते हैं। और जब आप पूछते हैं, तो परीक्षण व्यावसायिक तर्क और किनारे के मामलों का परीक्षण करने के बजाय यह परीक्षण करते हैं कि कोड वही करता है जो कोड करता है (टॉटोलॉजिकल परीक्षण)। जब आपको बाद में किसी सुविधा को बदलने की आवश्यकता होती है, तो आपके पास कोई सुरक्षा जाल नहीं होता है। हर बदलाव एक जुआ है.

ये समस्याएँ जटिल हो जाती हैं। डुप्लिकेट कोड से बग ढूंढना कठिन हो जाता है। असंगत पैटर्न परिवर्तन को जोखिम भरा बना देते हैं। त्रुटि प्रबंधन का अभाव उपयोगकर्ता-सामना विफलताओं का कारण बनता है। किसी भी परीक्षण का मतलब यह नहीं है कि आप सुरक्षित रूप से रिफैक्टर नहीं कर सकते। प्रत्येक समस्या दूसरों को तब तक बढ़ाती है जब तक कि कोडबेस उस बिंदु तक नहीं पहुंच जाता जहां एजेंसियों को लगता है कि यह आवश्यक हैस्क्रैच से शुरू करने की तुलना में मौजूदा वाइब कोड को ठीक करने में अधिक समय लगता है.

वाइब कोडिंग कब बंद करें और इंजीनियरों को कब नियुक्त करें

प्रत्येक वाइब-कोडित प्रोजेक्ट को बचाव की आवश्यकता नहीं है। कुछ प्रोटोटाइप किसी विचार को मान्य करते हैं और फेंक दिए जाते हैं। वह ठीक है। लेकिन यदि इनमें से तीन या अधिक के लिए आपका उत्तर "हां" है, तो इंजीनियरों को लाने का समय आ गया है:

• आप नई सुविधाएँ बनाने की तुलना में डिबगिंग में अधिक समय व्यतीत कर रहे हैं
• आप वास्तविक उपयोगकर्ता डेटा (ईमेल, भुगतान, व्यक्तिगत जानकारी) संभाल रहे हैं
• आपको भुगतान प्रसंस्करण, सदस्यता बिलिंग, या वित्तीय लेनदेन की आवश्यकता है
• आपके ऐप को 100 से अधिक समवर्ती उपयोगकर्ताओं के लिए विश्वसनीय रूप से काम करने की आवश्यकता है
• आप तृतीय-पक्ष API के साथ एकीकरण कर रहे हैं जिसके लिए वेबहुक या OAuth की आवश्यकता होती है
• आपने अपना क्रेडिट बजट दो बार खर्च कर दिया है और आपकी सुविधा सूची नहीं बदली है
• आप आत्मविश्वास से उत्तर नहीं दे सकते कि "इस डेटा तक कौन पहुंच सकता है?" आपके डेटाबेस में प्रत्येक तालिका के लिए
• आप धन जुटाने की योजना बना रहे हैं, और निवेशक आपकी तकनीकी संरचना के बारे में पूछेंगे
• आपने एक बग का सामना किया है जिसे आप 20+ संकेतों के बाद भी ठीक नहीं कर सकते

संक्रमण बिंदु विफलता के बारे में नहीं है. यह पहचानने के बारे में है कि कहां एआई उपकरण सही उपकरण बनना बंद कर देते हैं और अनुभवी इंजीनियर सही उपकरण बनना शुरू कर देते हैं। एक संस्थापक जिसने एमवीपी को वाइब-कोड किया और मांग को मान्य किया, उसने कुछ ऐसा किया जो अधिकांश स्टार्टअप सलाह आपको करने के लिए कहती है: तेजी से जहाज बनाना, तेजी से सीखना। अगला कदम उस मान्य प्रोटोटाइप को उत्पादन सॉफ़्टवेयर में बदलना है।

एक एजेंसी क्या अलग ढंग से करती है

80/20 दीवार पर एक आम प्रतिक्रिया है "मैं इसे कोड करना और इसे स्वयं ठीक करना सीखूंगा।" उस ऊर्जा का सम्मान करें, लेकिन गणित पर विचार करें। किसी प्रोडक्शन ऐप को पूरा करने के लिए पर्याप्त रिएक्ट, डेटाबेस डिज़ाइन, प्रमाणीकरण और परिनियोजन सीखने में 6-12 महीने का केंद्रित अध्ययन लगता है। इसे पूरा करने के लिए एक वरिष्ठ इंजीनियर को नियुक्त करने में 3-6 सप्ताह लगते हैं। यदि आपके स्टार्टअप के पास बाज़ार विंडो है, तो 6 महीने का सीखने का मार्ग उस विंडो को बंद कर देता है।

सावी में, हमारे वरिष्ठ इंजीनियर भी एआई टूल का उपयोग करते हैं। हम प्रतिदिन कर्सर, क्लाउड और कोपायलट का उपयोग करते हैं। अंतर यह है कि हम उन्हें 5-10 वर्षों के इंजीनियरिंग अनुभव के आधार पर त्वरक के रूप में उपयोग करते हैं, प्रतिस्थापन के रूप में नहीं। हम जानते हैं कि क्या संकेत देना है और इससे भी महत्वपूर्ण बात यह है कि आउटपुट में क्या समीक्षा करनी है। हम आपके उपयोगकर्ताओं तक पहुंचने से पहले आरएलएस गलत कॉन्फ़िगरेशन, लापता त्रुटि सीमाएं, एसक्यूएल इंजेक्शन वैक्टर और दौड़ की स्थितियों को पकड़ लेते हैं।

जब कोई संस्थापक हमारे लिए वाइब-कोडित प्रोटोटाइप लाता है तो प्रक्रिया कैसी दिखती है:

ऑडिट (1-2 दिन)।हम आपके मौजूदा कोडबेस, डेटाबेस स्कीमा और बुनियादी ढांचे की समीक्षा करते हैं। हम सुरक्षा कमजोरियों, वास्तुशिल्प समस्याओं और कोड की पहचान करते हैं जिन्हें बदलने की आवश्यकता है। हम आपको एक ईमानदार मूल्यांकन देते हैं: क्या इसे ठीक किया जा सकता है, या हमें नए सिरे से शुरुआत करनी चाहिए? कभी-कभी वाइब-कोडेड ऐप में ठोस यूआई घटक और एक उचित डेटाबेस स्कीमा होता है, और हम इसके शीर्ष पर निर्माण कर सकते हैं। अन्य समय में, नींव में बहुत अधिक संरचनात्मक समस्याएं होती हैं, और सफाई शुरू करना तेज़ और सस्ता होता है।

वास्तुकला (2-3 दिन)।हम उत्पादन वास्तुकला को डिज़ाइन करते हैं। उचित अनुक्रमणिका, आरएलएस नीतियों और माइग्रेशन रणनीति के साथ डेटाबेस स्कीमा। प्रमाणीकरण, दर सीमित करने और त्रुटि प्रबंधन के साथ एपीआई परत। सुसंगत डेटा प्राप्त करने के पैटर्न, राज्य प्रबंधन और घटक संगठन के साथ फ्रंटएंड संरचना। यह वर्क वाइब कोडिंग टूल्स को पूरी तरह से छोड़ देता है।

निर्माण (2-5 सप्ताह)।हम उत्पादन कोड लिखते हैं। प्रत्येक सुविधा को त्रुटि प्रबंधन, लोडिंग स्थिति और एज केस कवरेज मिलता है। प्रत्येक डेटाबेस तालिका को आरएलएस नीतियां मिलती हैं। प्रत्येक एपीआई रूट को इनपुट सत्यापन मिलता है। हम व्यावसायिक तर्क के लिए परीक्षण लिखते हैं। हम सीआई/सीडी पाइपलाइनें स्थापित करते हैं जो तैनाती से पहले प्रतिगमन पकड़ती हैं। आप अपना उत्पाद बनाने वाले इंजीनियर से सीधे बात करते हैं; कोई परियोजना प्रबंधक संदेश प्रसारित नहीं कर रहा, कोई साप्ताहिक स्थिति कॉल नहीं जो एक स्लैक संदेश हो सकता था।

लॉन्च और हैंडऑफ़.हम उत्पादन में तैनात हैं, मुद्दों के लिए पहले सप्ताह की निगरानी करते हैं, और आपको दस्तावेज़ के साथ एक कोडबेस सौंपते हैं जिसे आप दुनिया के किसी भी इंजीनियर के पास ले जा सकते हैं। कोई विक्रेता लॉक-इन नहीं। कोई मालिकाना ढांचा नहीं. मानक उपकरण, स्वच्छ कोड, आपका भंडार, आपका बुनियादी ढांचा।

हम निश्चित मूल्य उद्धरण प्रदान करते हैं। कोड की एक पंक्ति लिखने से पहले आप लागत जानते हैं। जब डिबगिंग में अपेक्षा से अधिक समय लगता है तो कोई प्रति घंटा बिलिंग नहीं होती है। जब आप निर्माण के मध्य में किसी सुविधा को स्पष्ट करते हैं तो कोई "परिवर्तन अनुरोध" अधिभार नहीं लगता।

प्रोटोटाइप कठिन हिस्सा था. फिनिशिंग स्मार्ट हिस्सा है.

आपने कुछ ऐसा किया जो ज़्यादातर लोग कभी नहीं करते: आपने एक विचार लिया, एक उपकरण खोला, और कुछ ऐसा बनाया जिसे आप वास्तविक लोगों को दिखा सकते थे। उस प्रोटोटाइप ने साबित कर दिया कि आपके विचार के पैर हैं। इससे साबित हुआ कि आपके पास उत्पाद बनाने का स्वाद और जुनून है।

अगला कदम अधिक उत्साहजनक नहीं है. यह इंजीनियरिंग है. यह सुरक्षा को मजबूत करना, एज केस हैंडलिंग, प्रदर्शन अनुकूलन और बुनियादी ढांचे के फैसले हैं जो एक प्रोटोटाइप को सॉफ्टवेयर में बदल देते हैं जिसके लिए लोग भुगतान करते हैं और अपने डेटा पर भरोसा करते हैं।

सॉफ़्टवेयर कंपनी बनाने के लिए आपको इंजीनियर बनने की आवश्यकता नहीं है। आपको ऐसे व्यक्ति को नियुक्त करना होगा जो जानता हो कि एआई का उपयोग कब करना है और कब हाथ से कोड लिखना है। डेमो और उत्पाद के बीच यही अंतर है।

अक्सर पूछे जाने वाले प्रश्नों