Vibe coding accuracy एक माप है, मॉडल की खूबी नहीं
एक ही मॉडल इस्तेमाल करने वाली दो टीमों को बहुत अलग नतीजे मिलते हैं, क्योंकि जिस स्तर की accuracy आपके लिए मायने रखती है, वह generation के बाद जो होता है उससे तय होती है। किसी ने जाँचा? किसके मुकाबले? गलत नतीजा कितनी जल्दी सुधारे जाने के लिए वापस आया?
इस तरह देखें तो सवाल “कौन-सा मॉडल सबसे सटीक है” नहीं रह जाता, बल्कि “मेरा feedback loop क्या है” बन जाता है — और यह आपके अपने नियंत्रण में है।
मापने लायक क्या है
क्या वर्णित व्यवहार होता है
सही होने की यही एकमात्र परिभाषा है जो यूज़र के सामने टिकती है।
इसे flow चलाकर मापा जाता है, कोड पढ़कर नहीं।
क्या कल वाला अब भी चलता है
पहला हफ़्ता बीत जाने के बाद पहली कोशिश की accuracy से ज़्यादा मायने regression rate रखता है।
करीब हर पाँच में से एक feature बदलाव कुछ ऐसा तोड़ देता है जो पहले चल रहा था।
सही नतीजे तक कितना समय
green तक पहुँचने में लगी कोशिशें, पहली बार में pass या fail से ज़्यादा काम की होती हैं।
यह उस चीज़ को पकड़ता है जो आप असल में महसूस करते हैं — कि loop में कितना समय लगता है।
जाल: एक ही लेखक के लिखे टेस्ट
accuracy मापने का सबसे सीधा तरीका यही लगता है कि agent से टेस्ट लिखवा लो और देख लो कि वे pass होते हैं या नहीं। इससे जो आँकड़ा निकलता है वह लगभग हमेशा ऊँचा होता है और उसका मतलब बहुत कम होता है। जो टेस्ट उन्हीं धारणाओं से बना है जिनसे implementation बना है, वह बनावट से ही उससे सहमत होगा — वहाँ भी, जहाँ दोनों गलत हैं।
accuracy के माप के लिए एक स्वतंत्र जाँच चाहिए। ऐसी कोई चीज़ जो प्रोडक्ट को उसके इच्छित व्यवहार के मुकाबले परखे, न कि कोड की अपने बारे में बनी धारणा के मुकाबले।
माप को सेट करना
अगले दौर के बदलावों से पहले, सादी भाषा में उन flows का वर्णन कर लें जो तय करते हैं कि आपके प्रोडक्ट के लिए सही क्या है। उन्हें deployed ऐप पर चलाएँ। पहला रन आपको baseline देता है, और उसके बाद का हर रन regression का संकेत।
इसके लिए terminal की कोई ज़रूरत नहीं। TestSprite dashboard में एक प्रोजेक्ट बनाएँ, जाँच को सादी भाषा में लिखें, और उसे अपने ऐप की ओर मोड़ दें। आपकी टीम के डेवलपर चाहें तो यही काम command line से भी चला सकते हैं, जिसके लिए देखें CLI repository।
जानने लायक एक आँकड़ा
एक सार्वजनिक leaderboard पर, जहाँ coding agents ने एक ही ऐप बनाया, मुकाबले के सबसे सस्ते मॉडल ने सबसे सही ऐप तैयार किया — जब verification loop मौजूद था, और सबसे महँगी एंट्री की आधी लागत पर। दिलचस्प बात रैंकिंग नहीं है। दिलचस्प यह है कि मॉडल से ज़्यादा फ़र्क loop ने डाला, जो accuracy की आम बातचीत के बिलकुल उलट है।
यह आँकड़ा असल में किस काम का है
accuracy के आँकड़े आम तौर पर ऐसे सवाल का जवाब देने के लिए जुटाए जाते हैं जो किसी ने पूछा ही नहीं — जैसे कि मॉडल अच्छा है या नहीं। काम का सवाल इससे छोटा है: क्या मैं इसे merge कर सकता हूँ।
इससे माप का ढाँचा बदल जाता है। आपको पूरे प्रोडक्ट का स्कोर नहीं चाहिए, आपको यह जानना है कि इस बदलाव ने ऐसा कुछ तोड़ा या नहीं जो इससे पहले चल रहा था। मायने रखने वाले flows को समेटती मुट्ठी भर जाँचें, deployed build पर चलाकर, इसका जवाब मिनटों में दे देती हैं। एक व्यापक benchmark हफ़्ते भर में किसी और ही सवाल का जवाब देता है।
इससे यह भी बदल जाता है कि खराब आँकड़े का मतलब क्या है। किसी benchmark पर गिरता accuracy का आँकड़ा दिलचस्प होता है। लेकिन एक ठोस flow, जो कल चल रहा था और आज नहीं चल रहा, उस पर कार्रवाई की जा सकती है — और दूसरी वाली ही वह चीज़ है जो इन्हें यूज़र तक पहुँचने से रोकती है।
माप को लगातार चलने वाला बनाएँ
एक बार का माप आपको सिर्फ़ एक पल के बारे में बताता है। accuracy एक चलती हुई प्रक्रिया की खूबी है, इसलिए जाँचों की जगह हर बदलाव पर है।
दो रास्ते हैं, और चुनाव असल में इस बात का है कि pipeline किसके ज़िम्मे है। dashboard से जोड़िए GitHub App — इसके लिए आपकी repository में कोई बदलाव करने की ज़रूरत ही नहीं, क्योंकि यह उसी deployment पर प्रतिक्रिया देता है जो आपका build पहले से निकालता है। वहीं एक GitHub Actions step जोड़ने पर जाँच repo में आ जाती है, जहाँ बाकी build की तरह उसका भी review होता है।
accuracy को मापने लायक चीज़ में बदलना
इस माप को जिस स्वतंत्र जाँच की ज़रूरत है, TestSprite वही है। यह आपके deployed प्रोडक्ट को उस व्यवहार के मुकाबले परखता है जो आपने बताया था, न कि कोड की अपने बारे में बनी धारणा के मुकाबले — और यही वजह है कि आँकड़े का मतलब तब भी बनता है जब implementation और उसके टेस्ट, दोनों एक ही agent से आए हों।
व्यवहार में आप एक बार उन flows का वर्णन करते हैं जो तय करते हैं कि आपके प्रोडक्ट के लिए सही क्या है, और वे हर बदलाव पर चलते हैं। पहला रन आपका baseline है। उसके बाद का हर रन उसी सवाल का जवाब देता है जो असल में आपके मन में है — कि इस बदलाव ने ऐसा कुछ तोड़ा या नहीं जो कल चल रहा था।
इससे आपको वे दो आँकड़े मिल जाते हैं जिन्हें ट्रैक करना चाहिए: प्रति बदलाव regression rate, और दोबारा green तक पहुँचने में कितनी कोशिशें लगती हैं। loop कसने पर दोनों हिलते हैं, और ज़्यादा टेस्ट लिखकर इनमें से किसी को फुलाया नहीं जा सकता।
vibe coding के लिए कौन-सा मॉडल सबसे सटीक है?
ज़्यादातर टीमों के लिए यह गलत सवाल है। आप verify करते हैं या नहीं, इससे आने वाला फ़र्क आज के frontier मॉडलों के आपसी फ़र्क से बड़ा है।
क्या मैं टेस्ट लिखे बिना accuracy माप सकता हूँ?
हाँ। flows को सादी भाषा में लिखिए और उन्हें ऐप पर चलवाइए। आप व्यवहार माप रहे हैं, और व्यवहार देखने के लिए टेस्ट कोड ज़रूरी नहीं।
अच्छा accuracy आँकड़ा कौन-सा होता है?
अलग-अलग प्रोडक्ट के बीच कोई काम का benchmark नहीं होता। इसके बजाय अपना ही रुझान ट्रैक करें: प्रति बदलाव regression rate और सही नतीजे तक लगी कोशिशें। loop कसने के साथ दोनों घटने चाहिए।
क्या ज़्यादा coverage का मतलब ज़्यादा accuracy है?
भरोसे के साथ नहीं। coverage यह गिनता है कि क्या-क्या चलाया गया, यह नहीं कि उम्मीदें सही थीं या नहीं। जेनरेट किए गए टेस्ट का बड़ा suite गलत धारणाओं पर भी ऊँचा coverage दिखा सकता है।
मुझे दोबारा कितनी बार मापना चाहिए?
हर बदलाव पर, अपने आप। तय समय-सारिणी पर मापी गई accuracy आपको उस समय-सारिणी के बारे में बताती है, न कि उस बदलाव के बारे में जिसने कुछ तोड़ा।
accuracy आपका loop है, आपका मॉडल नहीं।
Vibe coding accuracy वह चीज़ है जिसे आप अपने ही प्रोडक्ट पर मापते हैं: क्या वर्णित व्यवहार होता है, क्या कल वाला अब भी चलता है, सही नतीजे तक कितना समय लगता है। एक ही लेखक के लिखे टेस्ट के बजाय स्वतंत्र जाँच इस्तेमाल करें, और हर बदलाव पर मापें।