vibe coding के बग कुछ ही जगहों पर क्यों जमा होते हैं
एजेंट उसी रास्ते के लिए ऑप्टिमाइज़ करता है जो आपने बताया है। आप वही चीज़ बताते हैं जो आप होते हुए देखना चाहते हैं, इसलिए happy path सावधानी से बनता है और उसके आसपास की हर चीज़ बस दिखने भर को ठीक बनती है। "दिखने भर को ठीक" ही यहाँ असली शब्द है: कोड कंपाइल होता है, स्क्रीन रेंडर होती है, और मान्यताओं को हकीकत के सामने कभी परखा ही नहीं गया।
इसीलिए ये गड़बड़ियाँ पहले से भाँपी जा सकती हैं। ये हमेशा आपके दिए गए विवरण के किनारों पर होती हैं।
चार क्लस्टर, उसी क्रम में जिसमें वे नुकसान पहुँचाते हैं
परसिस्टेंस। स्क्रीन अपडेट हो जाती है, डेटाबेस नहीं। एक रीलोड इसे तुरंत सामने ला देता है। कुछ भी मानने से पहले हर राइट के बाद रीलोड कीजिए।
खाली और एरर स्टेट्स। शून्य नतीजे, एक फेल हुई रिक्वेस्ट, एक रिजेक्ट हुआ इनपुट। इनमें से कुछ भी आपके प्रॉम्प्ट में नहीं था। हर एक को जान-बूझकर आज़माइए। ये happy path से ज़्यादा बार टूटते हैं।
दूसरा अकाउंट। ओनरशिप, परमिशन और विज़िबिलिटी — ये सब उसी एक सेशन के हिसाब से मान लिए जाते हैं जिसमें ऐप बना था। किसी और के साइन इन करने से पहले आप खुद किसी दूसरे यूज़र के तौर पर साइन इन कीजिए।
चौथा क्लस्टर ज़्यादा सूक्ष्म है: कल बनाए गए फ़ीचर। हर नया निर्देश चुपचाप किसी ऐसी चीज़ को तोड़ सकता है जो पहले काम कर रही थी, और पुराने व्यवहार की जाँच कोई नहीं कर रहा क्योंकि बातचीत आगे बढ़ चुकी है।
वह जाँच जो प्रॉम्प्टिंग के साथ स्केल करती है
मैन्युअल जाँच एक दोपहर तक चलती है और फिर बिगड़ने लगती है, क्योंकि हर प्रॉम्प्ट के साथ जाँचने लायक सतह बढ़ती जाती है जबकि आपका सब्र नहीं। आपको चाहिए कि जाँचें सरल भाषा में लिखी हों और अपने आप चलें, ताकि कल बनाए गए फ़ीचर बिना आपके तय किए दोबारा परखे जाते रहें।
सेटअप यह काम एजेंट के हाथ में दे देता है, जिससे जाँच अलग से किया जाने वाला बोझ न रहकर बनाने के साथ-साथ चलती रहती है।
इसमें कहीं भी टर्मिनल की ज़रूरत नहीं है। TestSprite डैशबोर्ड में एक प्रोजेक्ट बनाइए, जाँच को सरल भाषा में लिखिए, और उसे अपने ऐप पर लगा दीजिए। आपकी टीम के डेवलपर चाहें तो यही काम कमांड लाइन से भी कर सकते हैं — देखिए CLI रिपॉज़िटरी।
दस मिनट जो इनमें से ज़्यादातर पकड़ लेते हैं
साइन अप कीजिए, साइन आउट कीजिए, फिर से साइन इन कीजिए। सबसे आम पूरी तरह फेल हो जाने वाली चीज़, और असली यूज़र सबसे पहले यही करता है।
कुछ बनाइए, रीलोड कीजिए, पक्का कीजिए कि वह बचा रहा। परसिस्टेंस वाले क्लस्टर को सीधे पकड़ लेता है।
कुछ अमान्य सबमिट कीजिए। आप यह जाँच रहे हैं कि वह साफ़ तौर पर फेल हो, चुपचाप सफल न हो जाए।
पूरा मुख्य फ़्लो एकदम नए अकाउंट से कीजिए। परमिशन वाले क्लस्टर को पकड़ लेता है।
इनमें से किसी के लिए कोड पढ़ने की ज़रूरत नहीं, और मिलकर ये वह ज़्यादातर चीज़ें पकड़ लेते हैं जो वरना कोई अजनबी पकड़ता।
वही बग बार-बार क्यों लौट आता है
इस तरह बनाने को लेकर सबसे आम शिकायत यह नहीं है कि चीज़ें टूटती हैं, बल्कि यह है कि एक चीज़ ठीक करने पर दूसरी टूट जाती है, और बार-बार। यह मॉडल की कमी नहीं है। यह रिकॉर्ड का न होना है।
हर निर्देश को सिर्फ़ कोड की मौजूदा हालत के हिसाब से समझा जाता है, और किसी चीज़ के हिसाब से नहीं। ऐसे व्यवहारों की कोई सूची नहीं होती जिन्हें पहले से काम करते रहना था, इसलिए एजेंट को यह जानने का कोई तरीका नहीं कि आपने जो बदलाव माँगा है वह पिछले मंगलवार तय की गई किसी बात से टकरा रहा है। उसकी नज़र में कोई टकराव है ही नहीं, क्योंकि पिछला मंगलवार वहाँ मौजूद नहीं है।
लिखी हुई जाँचें ही वह रिकॉर्ड हैं। ये एजेंट को ज़्यादा समझदार नहीं बनातीं, ये आपके इरादे को टिकाऊ बनाती हैं। व्यावहारिक असर यह होता है कि बदलावों का तीसरा और चौथा दौर पहले दो दौर के काम को बिगाड़ना बंद कर देता है — और यही वह मोड़ है जहाँ इस तरह बनाना थकाऊ के बजाय भरोसेमंद लगने लगता है।
असली दुनिया में जाने से पहले
जैसे ही ऐप दूसरे लोग इस्तेमाल करने लगें, जाँचें हर बदलाव पर चलनी चाहिए, न कि तब जब आपको याद आए।
GitHub App एक webhook है जिसे आप TestSprite डैशबोर्ड में सेट करते हैं। यह उसी डिप्लॉयमेंट इवेंट को सुनता है जो आपकी पाइपलाइन पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ भी नहीं बदलता।
GitHub Actions इस स्टेप को आपके अपने वर्कफ़्लो के अंदर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।
जाँचों को खुद चलने देना
इस पेज में बताई गई दस मिनट की जाँच को हाथ से करने की ज़रूरत TestSprite खत्म कर देता है। आप हर फ़्लो को एक बार सरल भाषा में लिख देते हैं, और यह हर बदलाव के बाद उन्हें आपके ऐप पर चला देता है।
इससे सीधे वही दिक्कत दूर होती है जो इस तरह बनाने में लोगों को सबसे ज़्यादा खलती है। लिखी हुई जाँचें इस बात का रिकॉर्ड हैं कि पहले से क्या काम करता रहना चाहिए, इसलिए नए निर्देश को अलग-थलग समझने के बजाय उन जाँचों के सामने परखा जाता है। एक चीज़ ठीक करने पर दूसरी टूटने वाला चक्र डिफ़ॉल्ट नहीं रह जाता।
इसमें कहीं भी टर्मिनल या टेस्ट फ़ाइल की ज़रूरत नहीं। डैशबोर्ड में एक प्रोजेक्ट बनाइए, उसे अपने ऐप पर लगाइए, और ऊपर बताई गई चारों जाँचें लिख दीजिए। आपकी टीम के डेवलपर चाहें तो यही काम कमांड लाइन से भी कर सकते हैं।
क्या vibe coding बस ज़्यादा जोखिम भरा है?
यह जोखिम की जगह बदल देता है। टाइपो का जोखिम कम, बिना परखी मान्यता का जोखिम ज़्यादा। इसका जवाब हर लाइन दोबारा पढ़ने पर लौटना नहीं है, बल्कि व्यवहार की व्यवस्थित जाँच करना है।
एक चीज़ ठीक करने पर दूसरी क्यों टूट जाती है?
क्योंकि हर निर्देश को मौजूदा कोड के संदर्भ में समझा जाता है, न कि इस रिकॉर्ड के सामने कि पहले से क्या काम करता रहना चाहिए। लिखी हुई जाँचें वही रिकॉर्ड देती हैं।
क्या मुझे टेस्ट लिखने होंगे?
कोड में नहीं। फ़्लो को सरल भाषा में लिखिए, उसे सहेजकर रखिए, और हर बदलाव के बाद अपने आप चलने दीजिए।
मुझे कैसे पता चलेगा कि जाँच असली है?
जान-बूझकर कुछ तोड़िए और पक्का कीजिए कि जाँच फेल होती है। जो जाँच कभी फेल नहीं होती वह कुछ भी नहीं बचा रही, और इसे परखने में एक मिनट लगता है।
जाँच करना कब शुरू करूँ?
किसी को दिखाने से पहले। अभी लिखी गई जाँच की कीमत कुछ मिनट है; किसी और के बग ढूँढ लेने के बाद यह कीमत कहीं ज़्यादा होती है।
कोड नहीं, उन चार क्लस्टर की जाँच कीजिए।
Vibe coding के बग परसिस्टेंस, खाली स्टेट्स, दूसरे अकाउंट और कल बनाए गए फ़ीचर के आसपास जमा होते हैं। दस मिनट में इनमें से ज़्यादातर पकड़ में आ जाते हैं, और उन जाँचों को लिख लेना ही वह चीज़ है जो प्रॉम्प्ट करते रहने पर भी इन्हें लौटने से रोकती है।