Vibe-coded ऐप का पहला दिन अब तक का सबसे बेहतरीन डेमो होता है। प्रॉम्ट काम कर गया, स्क्रीन साफ हैं, डेटाबेस में डेटा है, और आपने स्क्रीन रिकॉर्डिंग के साथ एक ट्वीट शेयर कर दिया। हमने ऐसे कई दिन देखे हैं। हम इसे आपसे छीनने नहीं आए हैं।
हम दूसरे दिन के बारे में बात करने आए हैं, क्योंकि किसी का भी लॉन्च थ्रेड इस पर चर्चा नहीं करता। दूसरा दिन वह है जब एक वास्तविक उपयोगकर्ता लॉग इन करता है, कुछ ऐसा करता है जिसे आपने टेस्ट करने के बारे में नहीं सोचा था, और आपका ऐप “जनरेटेड” और “इंजीनियर्ड” के बीच के अंतर का सामना करता है।
दूसरा दिन वास्तव में कैसा दिखता है
यह शायद ही कभी क्रैश से शुरू होता है। यह एक अजीब चीज़ से शुरू होता है: एक फॉर्म जो गलत डेटा स्वीकार कर लेता है, एक पेज जो किसी एक विशिष्ट उपयोगकर्ता के लिए टूट जाता है, एक नंबर जो गलत है लेकिन कोई उसे दोबारा पैदा (reproduce) नहीं कर पा रहा। आप एरर को चैट में पेस्ट करते हैं। AI आत्मविश्वास से उसे ठीक करता है। वह फिक्स किसी और चीज़ को तोड़ देता है।
प्रॉम्ट व्हैक-अ-मोल (prompt whack-a-mole) में आपका स्वागत है। क्योंकि AI मूल कारणों के बजाय लक्षणों को ठीक करता है, हर पैच पिछले पैच के ऊपर बैठता है, और कोडबेस चुपचाप वह बन जाता है जिसे बिल्डर्स ‘फ्रेंकेंस्टीन कोड’ कहते हैं: परस्पर विरोधी शैलियों, डुप्लिकेट फंक्शन्स और उलझे हुए लॉजिक का एक मिश्रण जहाँ डेटाबेस क्वेरीज़ इंटरफ़ेस कोड के अंदर रहती हैं। जैसे-जैसे प्रोजेक्ट AI की कॉन्टेक्स्ट विंडो से बड़ा होता जाता है, मॉडल अपने पिछले फैसलों को भूलने लगता है और ऐसा कोड प्रस्तावित करता है जो उनके विपरीत होता है। अब आप एक ऐप को मेंटेन नहीं कर रहे हैं। आप उससे मोलभाव कर रहे हैं।
इसका एक और क्रूर रूप है: साइलेंट डिप्लॉय फेल्योर। आपका होस्टिंग बिल्ड एक मामूली एरर पर फेल हो जाता है, लाइव URL पुराना वर्जन दिखाता रहता है, और आप - कोई बदलाव न देखकर - AI से कहते हैं कि उसका फिक्स “काम नहीं किया।” तो वह एक समस्या के लिए पूरी तरह से अलग और अधिक जटिल समाधान जनरेट करता है जो पहले ही हल हो चुकी थी। कुछ राउंड बाद आपके पास कोड का एक भारी-भरकम v5 होता है जिसका v1 बिल्कुल ठीक था।
वह हिस्सा जो आप देख नहीं सकते
डीबगिंग का ट्रेडमिल तो कम से कम दिखाई देता है। सुरक्षा समस्याएँ नहीं दिखतीं, और यही कारण है कि हम बिजनेस बिल्ड्स के मामले में सख्त हो जाते हैं।
यहाँ का रिसर्च वास्तव में असहज करने वाला है। LLM-जनरेटेड कोड लगभग 90% समय सफलतापूर्वक कंपाइल होता है, लेकिन लगभग 45% कोड में OWASP Top 10 कमजोरियां होती हैं - जैसे बाईपास किए जा सकने वाले लॉगिन चेक और इंजेक्शन खामियाँ। AI टूल्स डेमो के काम करने के लिए ऑप्टिमाइज़ करते हैं, जिससे कुछ अनुमानित शॉर्टकट्स निकलते हैं: एक्सेस कंट्रोल ब्राउज़र में लागू करना जहाँ कोई भी उपयोगकर्ता पेज एडिट करके इसे बाईपास कर सकता है, डेटाबेस अनुमतियों को पूरी तरह खुला रखना ताकि बिल्ड के दौरान कोई एरर न आए, और API कीज़ को फाइलों में हार्डकोड करना क्योंकि बिल्डर को नहीं पता कि एनवायरनमेंट वेरिएबल क्या होता है। फिर वे फाइलें पब्लिक GitHub रेपो में पुश कर दी जाती हैं, जहाँ क्रेडेंशियल स्क्रेपर्स उन्हें समय पर खोज लेते हैं।
यही चीज़ इसे विशेष रूप से ‘डे टू’ समस्या बनाती है: एक असुरक्षित ऐप पूरी तरह से सही चलता है। “क्लाइंट A तकनीकी रूप से क्लाइंट B के रिकॉर्ड पढ़ सकता है” इसके लिए कोई एरर मैसेज नहीं आता। आपको यह किसी उपयोगकर्ता से पता चलता है, यदि आप भाग्यशाली हैं, या उससे भी बदतर यदि आप नहीं हैं। और मानक सलाह (“बस इसे टेस्ट करें!”) वास्तविकता से टकराती है: गैर-तकनीकी बिल्डर्स केवल ‘हैप्पी पाथ’ टेस्ट करते हैं, जबकि विफलता एज केसेस में छिपी होती है - जैसे कॉन्करेंसी बग, या वह भूला हुआ पासवर्ड-रीसेट फ्लो जिसे AI ने कभी जनरेट नहीं किया क्योंकि डेमो को उसकी ज़रूरत नहीं थी।
मेंटेनेंस डेट जिसे कोई आइटमलाइज़ नहीं करता
इन मैकेनिज्म्स को महीनों तक जोड़ें और आपको वह मिलता है जिसे हम तकनीकी ऋण (technical debt) का ‘पे-डे लोन’ मानते हैं: अभी इंस्टेंट सॉफ्टवेयर, बाद में चक्रवृद्धि ब्याज। AI द्वारा लिया गया हर शॉर्टकट भविष्य का एक फिक्स है। हर फिक्स का मतलब कुछ और क्रेडिट्स और थोड़ा और कोड ब्लोट है। प्लेटफॉर्म अपडेट आते हैं और उन चीज़ों को तोड़ देते हैं जिन्हें आपने छुआ तक नहीं - प्रॉम्ट-टू-ऐप प्लेटफॉर्म्स पर लंबे समय तक काम करने वाले बिल्डर्स प्लेटफॉर्म की वजह से होने वाले रिग्रेशन्स को संभालने के लिए क्लाइंट्स से मासिक मेंटेनेंस फीस लेने की बात करते हैं।
यह इस पूरी प्रक्रिया का एक कड़वा मज़ाक है: vibe coding ने सॉफ्टवेयर के लोकतंत्रीकरण का वादा किया था, और प्रोडक्शन ऐप्स के लिए इसने मुख्य रूप से तकनीकी ऋण का लोकतंत्रीकरण किया है। गैर-तकनीकी बिल्डर अंततः उसी चीज़ को पकड़े हुए रह जाता है जिससे बचने के लिए उसने AI का उपयोग किया था - एक ऐसा कोडबेस जिसके लिए डेवलपर के निर्णय (judgment) की आवश्यकता होती है - सिवाय इसके कि अब यह उसके व्यवसाय का आधार है, और वह इसे पढ़ नहीं सकता।
ईमानदार रास्ता
तो आप वास्तव में क्या करें? बहुत सारे बिल्ड्स और कुछ कड़वे अनुभवों के बाद, हमें लगता है कि यह दो ईमानदार रास्तों वाले एक मोड़ (fork) जैसा है, और बीच का बेईमान रास्ता ही एकमात्र गलत जवाब है।
पहला रास्ता: कोड मेंटेन करना सीखें। यदि आप इसे गहराई से जानने के लिए पर्याप्त प्यार करते हैं, तो vibe coding एक जाल के बजाय एक वैध एक्सेलेरेटर बन जाता है। एजेंट जो लिखता है उसे पढ़ें। ऐप शिप करने से पहले सीखें कि RLS का क्या मतलब है। प्रॉम्ट-ओनली टूल्स से Cursor या Replit जैसे टूल्स पर आगे बढ़ें, जहाँ कोड ही इंटरफ़ेस है और आप वास्तविक निर्णय लेने की क्षमता विकसित कर सकते हैं। यह रास्ता वास्तव में महान है - यह बस एक रास्ता है जिसमें महीनों की मेहनत लगती है, और बिना पढ़े कोड को क्लाइंट्स को भेजते समय यह दिखावा करना कि आप इस रास्ते पर हैं, ही असली जाल है।
दूसरा रास्ता: खतरनाक हिस्सों को ऐसे फाउंडेशन पर रखें जो जनरेटेड न हो। ईमानदारी से स्वीकार करें कि आपका ऐप एक बिजनेस टूल है - एक क्लाइंट पोर्टल, एक ट्रैकर, एक इंटरनल CRM - और गौर करें कि इसका 80% हिस्सा वही प्लंबिंग है जिसे AI सबसे खराब तरीके से जनरेट करता है: auth, अनुमतियाँ, पासवर्ड रीसेट, डेटा एक्सेस। इस श्रेणी को Softr जैसे नो-कोड प्लेटफॉर्म पर बनाएँ, जहाँ प्लंबिंग एक टेस्टेड इंफ्रास्ट्रक्चर है जिसे आप विजुअली कॉन्फ़िगर करते हैं, और AI Co-Builder अभी भी आपको पहले दिन की स्पीड देता है। जब आपको कस्टम फ्लेयर चाहिए होता है, तो इसका vibe-coding ब्लॉक जनरेटेड कोड को एक सिंगल कंपोनेंट तक सीमित रखता है, ताकि AI छत को गिराए बिना घर को सजा सके। इस रास्ते पर दूसरा दिन एक एडिट होता है, न कि कोई पुरातत्व खुदाई (archaeology dig) - इसीलिए यह हमारी client portals ranking में शीर्ष पर है।
मज़ेदार चीज़ों के लिए बेझिझक vibe coding करते रहें - प्रोटोटाइप, खिलौने, वीकेंड एक्सपेरिमेंट वही हैं जिनमें ये टूल्स शानदार हैं। बस वास्तविक उपयोगकर्ताओं के आने से पहले तय कर लें कि आप मोड़ के किस तरफ खड़े हैं। दूसरा दिन विनम्रता से नहीं पूछता।