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