आपको वास्तव में कैसे पता चलेगा कि आपका vibe-coded ऐप काम करता है?

आपने वह चीज़ बना ली। आपने उसमें क्लिक करके देखा। बटन ने काम किया, record सेव हुआ, dashboard अपडेट हुआ। आप इसे लेकर अच्छा महसूस करते हैं।

लेकिन वह कोड आपने नहीं लिखा, और अगर आप ईमानदार हों, तो शायद आपने उसे पढ़ा भी नहीं है। तो असल में आप जो जानते हैं वह यह है: यह एक बार, आपके लिए, आपने जो एक चीज़ आज़माई उसे करते हुए काम कर गया। बाकी सब यह “काम करता है” या नहीं, यह सिर्फ भरोसा है।

Happy path ही वह एकमात्र रास्ता है जिसे ज़्यादातर लोग टेस्ट करते हैं

किसी vibe-coded ऐप को टेस्ट करना आमतौर पर ऐसा दिखता है: आप एक फ़ाइल अपलोड करते हैं और वह प्रोसेस हो जाती है। आप एक फ़ॉर्म सबमिट करते हैं और record दिखने लगता है। आप एक बटन क्लिक करते हैं और workflow चल जाता है। बस इतना ही। यही टेस्ट है।

यह आलस नहीं है। यह उस मैनुअल टेस्टिंग की स्वाभाविक सीमा है जो उस इंसान द्वारा की जाती है जिसने underlying logic नहीं लिखी। आप सिर्फ वही टेस्ट करने के बारे में सोच सकते हैं जो आप कल्पना कर सकते हैं कि गलत हो सकता है, और अगर आप कोड नहीं पढ़ सकते, तो आप demo को टेस्ट कर रहे हैं, सिस्टम को नहीं। Happy path ही वह एकमात्र रास्ता है जिसके लिए AI निश्चित रूप से optimize कर रहा था, क्योंकि यही वह scenario था जो prompt में था और जिसने शुरुआत में ऐप बनाया।

समस्या यह है कि असली उपयोग happy path पर नहीं रुकता। असली users डबल-क्लिक करते हैं। वे दो tabs खोलते हैं। वे back दबाकर फिर से submit करते हैं। इनमें से कुछ भी सामने नहीं आता जब आप, builder, अपने ही ऐप में एक बार, ध्यान से, उस क्रम में क्लिक करते हैं जिसकी आप उम्मीद करते हैं।

Concurrency ही वह जगह है जहाँ असल में सब टूटता है

सबसे स्पष्ट उदाहरण concurrency है, और यह हाथ से टेस्ट करना वास्तव में मुश्किल है, भले ही आपको ठीक-ठीक पता हो कि क्या देखना है।

एक credit-आधारित feature की कल्पना करें: एक user कोई process शुरू करता है, इसमें credits खर्च होते हैं, और एक balance check को credits खत्म होने पर उसे रोक देना चाहिए। अब कल्पना करें कि वही user पाँच tabs खोलता है और उसी सेकंड के भीतर पाँच processes शुरू कर देता है, इससे पहले कि पहला billing check पूरा हो। अगर ‘check-then-deduct’ logic इस overlap को संभालने के लिए नहीं बनाई गई, तो सभी पाँच processes किसी एक के भी deduction रजिस्टर करने से पहले balance check पास कर सकते हैं। नतीजा यह होता है कि user ऐसे processes चला रहा है जिन्हें वह afford नहीं कर सकता, credit balance negative हो जाता है, और account की स्थिति अब उस तरह गलत है जिसकी किसी ने योजना नहीं बनाई थी।

आप इसे एक बार बटन क्लिक करके नहीं पकड़ेंगे। आपको पाँच tabs खोलने के बारे में सोचना होगा, क्लिक्स को इस तरह टाइम करना होगा कि वे एक ही सेकंड के अंश में पड़ें, और यह जानना होगा कि ‘balance check करना’ और ‘balance deduct करना’ दो अलग steps हैं जो एक-दूसरे से race कर सकते हैं। यह टेस्टिंग की चूक नहीं है। यह उन बग्स की एक category है जिन्हें मैनुअल, एक-एक करके किया गया क्लिकिंग संरचनात्मक रूप से ढूँढ ही नहीं सकता, क्योंकि यह बग केवल तब मौजूद होता है जब कई चीज़ें एक साथ होती हैं, और अकेले टेस्ट कर रहा एक व्यक्ति जान-बूझकर वह स्थिति आसानी से नहीं बना सकता, उसे दोहराना तो और मुश्किल है।

यह ठीक वही edge case है जिसे AI-generated ऐप्स पर research उस failure mode के रूप में चिन्हित करता है जिसका कोई हिसाब नहीं रखता: AI उस specific success scenario के लिए paths बनाता है जिसके बारे में उससे पूछा गया था, concurrent edits, duplicate clicks, या steps के बीच timing gaps के लिए नहीं। और क्योंकि इससे होने वाला corruption कोई error नहीं देता, यह चुपचाप वहीं पड़ा रहता है जब तक हफ्तों बाद कोई report या balance गलत न दिखे।

लगभग कोई भी वे टेस्ट क्यों नहीं लिखता जो इसे पकड़ सकें

इस तरह की बग के लिए ईमानदार समाधान automated testing है: unit tests, integration tests, कुछ ऐसा जो पाँच simultaneous requests को simulate करके नतीजे को मशीनी तरीके से जांच सके, बजाय इंसान की कल्पना और patience पर निर्भर रहने के। Automated tests थकते नहीं, कोई edge case नहीं भूलते, और हर बदलाव के बाद फिर से चलाए जा सकते हैं यह सुनिश्चित करने के लिए कि सोमवार को ठीक की गई कोई चीज़ मंगलवार को न टूट जाए।

व्यवहार में, vibe coders के पास यह लगभग कभी नहीं होता। एक test suite लिखना अपने आप में एक तकनीकी skill है, यह कहना गलत नहीं होगा कि ऐप खुद लिखने से भी कठिन है, क्योंकि इसमें सिर्फ feature के काम करने के बारे में नहीं बल्कि failure modes के बारे में सोचना पड़ता है। एक AI agent अगर आप कहें तो tests लिख सकता है, लेकिन किसी को यह पता तो होना चाहिए कि पूछना है, यह समझना चाहिए कि tests असल में क्या जांचते हैं, और ऐप के नीचे बदलते रहने पर उन्हें अपडेट रखना चाहिए। किसी non-technical builder के लिए जो मंगलवार दोपहर को एक client portal shipping कर रहा है, यह बहुत आगे की बात है, और तेज़ी से vibe coding करने वाले technical builders भी शायद ही कभी उस कोड के लिए test coverage लिखने के लिए रुकते हैं जिसे वे वैसे भी अगले prompt से बदलने वाले हैं।

तो ज़्यादातर vibe-coded ऐप्स पर टेस्टिंग की असली स्थिति यह है: एक बार का happy-path click-through, एक बार किया गया, उस व्यक्ति द्वारा जो यह अंदाज़ा लगाने के लिए सबसे कम तैयार है कि क्या गलत हो सकता है। यही वह trust gap है। आप यह verify नहीं कर रहे कि ऐप काम करता है। आप उम्मीद कर रहे हैं कि वह काम करता है, उस एक चीज़ के आधार पर जो आपने आज़माई।

‘Visual certainty’ का असल मतलब क्या है

उम्मीद करने का एक असली विकल्प है, और यह “test suites लिखना सीखो” नहीं है। यह जोखिम भरे हिस्सों को ऐसी बुनियाद पर बनाना है जहाँ logic शुरू से ही छिपी नहीं होती।

Visual certainty का मतलब है कि आप एक settings panel खोल सकते हैं और ठीक-ठीक देख सकते हैं कि कौन सा user group किसी record को देख सकता है, कोई block किसी data source पर ठीक कौन सा filter लगाता है, और कोई workflow step by step, क्रम में, बिल्कुल क्या करता है, generated कोड की एक भी line पढ़े बिना। आप behavior को test करके उसके पीछे का rule अंदाज़ा नहीं लगा रहे। आप rule को सीधे पढ़ रहे हैं।

यह उन categories के लिए सबसे ज़्यादा मायने रखता है जहाँ trust gap सबसे महंगा है: billing logic, permissions, और concurrent users से जुड़ी कोई भी चीज़। Softr जैसा platform permissions, data restrictions और workflow steps को visual, inspectable configuration के रूप में रखकर इसे संभालता है, न कि AI-generated कोड के रूप में जिसे भरोसा करने के लिए आपको line by line audit करना पड़े। अगर आप जानना चाहते हैं कि क्या कोई client किसी दूसरे client के records देख सकता है, तो आप data restriction rule खोलकर उसे पढ़ते हैं। आपको पाँच simultaneous logins simulate करने और यह उम्मीद करने की ज़रूरत नहीं कि AI ने race condition सही ढंग से संभाला, क्योंकि यह rule platform का अपना, टेस्टेड infrastructure लागू कर रहा है, न कि कोई custom check जो AI ने आपके specific prompt के लिए लिखा।

इसका मतलब यह नहीं कि हर custom feature किसी settings panel में गायब हो जाता है। genuinely custom UI के लिए, एक vibe-coding block जो एक component तक सीमित है और platform की मौजूदा permission और data layer के ज़रिए जुड़ता है, पूरे ऐप जितने generated business logic से बहुत अलग तरह का जोखिम है, क्योंकि ‘AI ने यह एक हिस्सा गलत किया’ का असर सिर्फ एक block तक होता है, billing system तक नहीं।

वह दोराहा जिस पर आप असल में पहुँचते हैं

अगर आपका ऐप एक weekend project है या ऐसा prototype है जिसके लिए कोई पैसे नहीं दे रहा, तो उसे ship कर दें, happy path पर एक बार क्लिक करके देख लें, और आगे बढ़ जाएं। यहाँ जो दांव पर है वह ठीक वही है जो आपके चलाए गए manual test में दांव पर था।

अगर यह कोई client portal है, booking system है, ऐसा कुछ है जिसमें credits, balances या roles शामिल हैं, तो ईमानदार सवाल यह नहीं है कि “क्या मैंने इसे टेस्ट किया?” सवाल यह है कि “क्या मैं वास्तव में उन हिस्सों को verify कर सकता हूँ जो गलत होने पर नुकसान पहुँचाएंगे, या मैं सिर्फ AI की बात पर भरोसा कर रहा हूँ?” अगर जवाब भरोसा है, तो यह वही दोराहा है जिसके बारे में हमने पहले the Day Two problem में लिखा था, और दोनों रास्ते आप कौन हैं इस पर निर्भर करते हुए जायज़ हैं।

अगर आप कोड पढ़ सकते हैं, या सीखने को तैयार हैं, तो इस gap को किसी अलग builder से नहीं बल्कि असली tooling से बंद करें। Cursor एक वास्तविक codebase के भीतर काम करता है जहाँ आप concurrency tests माँग सकते हैं और फिर जो नतीजा आए उसे पढ़ सकते हैं, और Replit आपको एक cloud environment देता है जहाँ test suite चलाना loop का एक सामान्य हिस्सा है, बाद में सोचा गया कोई काम नहीं। दोनों ही मामलों में gap AI की क्षमता नहीं है, बल्कि यह है कि क्या आपको पता है कि test माँगना है और क्या आप बता सकते हैं कि वह अच्छा है या नहीं।

अगर आप ऐसा नहीं कर सकते, और आप उस तरह का ऐप बना रहे हैं जिसमें गलत permission या negative balance एक असली समस्या है, तो जोखिम भरे हिस्सों को ऐसी बुनियाद पर ले जाएं जहाँ आप rule को पढ़ते हैं, अंदाज़ा नहीं लगाते। अगर यही वह ऐप है जो आप असल में बना रहे हैं, तो हमारी client portals ranking देखें, क्योंकि वहीं गलत अंदाज़े की कीमत सबसे ज़्यादा होती है।