वाइब कोडिंग ने काम करने जैसा दिखने वाला एप्लिकेशन बनाने में सक्षम लोगों का दायरा बदल दिया है। पारंपरिक इंजीनियरिंग टीम की पहली डिज़ाइन समीक्षा पूरी होने से पहले ही एक प्रॉम्प्ट स्क्रीन बना सकता है, API कनेक्ट कर सकता है और एक विश्वसनीय लगने वाला वर्कफ़्लो तैयार कर सकता है।
यह गति भर्ती और डिलीवरी की एक नई समस्या पैदा करती है: अब डेमो इस बात का ठोस प्रमाण नहीं है कि सॉफ़्टवेयर अच्छा है। नियोक्ता तेजी से एक कठिन सवाल पूछेंगे: क्या यह AI-निर्मित सिस्टम तब सही ढंग से व्यवहार कर सकता है जब इनपुट अव्यवस्थित हों, निर्भरताएँ विफल हो जाएँ, उपयोगकर्ता बार-बार कार्रवाइयाँ करें और अंतर्निहित मॉडल बदल जाए?
इसका उत्तर ऐसे गुणवत्ता मानक से मिलेगा जो दृश्य चमक-दमक से कम और अनुशासित सॉफ़्टवेयर सत्यापन से अधिक मिलता-जुलता हो। जो लोग अलग दिखेंगे, वे केवल यह नहीं दिखाएँगे कि AI कोडिंग टूल ने क्या बनाया। वे दिखाएँगे कि उन्होंने उसका परीक्षण कैसे किया, वह सुरक्षित रूप से क्या नहीं कर सकता और उन्हें कैसे पता है कि किसी बदलाव से कोई दूसरी चीज़ खराब नहीं हुई।
बेंचमार्क प्रमाण है, लीडरबोर्ड स्कोर नहीं
ओपन-सोर्स कोडिंग-एजेंट बेंचमार्क उपयोगी शुरुआती बिंदु देते हैं, लेकिन वे अलग-अलग क्षमताओं को मापते हैं। SWE-bench वास्तविक GitHub समस्याओं और रिपॉज़िटरी स्नैपशॉट का उपयोग करता है, जिससे यह रखरखाव के काम के लिए प्रासंगिक बनता है। Terminal-Bench कमांड-लाइन इंटरैक्शन का परीक्षण करता है। सूचीबद्ध अन्य बेंचमार्क, जिनमें SlopCodeBench और ProgramBench शामिल हैं, जेनरेट किए गए कोड और एजेंट के व्यवहार के अलग-अलग पहलुओं को लक्षित करते हैं।
ये बेंचमार्क टूल की तुलना करने या आधाररेखा तय करने में मदद कर सकते हैं, लेकिन नियोक्ताओं को किसी एक स्कोर को प्रोडक्शन-रेडी होने के प्रमाण के रूप में देखने से सावधान रहना चाहिए। रिपॉज़िटरी की समस्याएँ हल करने वाला मॉडल फिर भी असुरक्षित प्राधिकरण लॉजिक बना सकता है। टर्मिनल कार्य पूरे करने वाला एजेंट लंबे वर्कफ़्लो में स्थिति बनाए रखने में विफल हो सकता है। एक सुघड़ वेब एप्लिकेशन सामान्य स्थिति वाले डेमो में सफल हो सकता है, लेकिन रीट्राई या डुप्लिकेट भुगतान को गलत ढंग से संभाल सकता है।
इसलिए किसी विश्वसनीय पोर्टफ़ोलियो या आंतरिक समीक्षा में कार्य-विशिष्ट मूल्यांकन सेट शामिल होना चाहिए। इस सेट में प्रतिनिधि बग रिपोर्ट, सामान्य उपयोगकर्ता यात्राएँ, गलत प्रारूप वाले इनपुट, अनुमति की सीमाएँ, निर्भरता विफलताएँ और पहले ठीक की गई रिग्रेशन समस्याएँ शामिल हो सकती हैं। हर मामले का स्पष्ट अपेक्षित परिणाम होना चाहिए, केवल सही दिखने वाला स्क्रीनशॉट नहीं।
AI-निर्मित सॉफ़्टवेयर के लिए न्यूनतम टेस्ट पैक
एक छोटे एप्लिकेशन के लिए उपयोगी गुणवत्ता पैक बिना किसी जटिल शोध प्रयोगशाला के तैयार किया जा सकता है:
- स्वीकृति परीक्षण: सबसे महत्वपूर्ण वर्कफ़्लो के उपयोगकर्ता को दिखाई देने वाले व्यवहार की जाँच करें, जिसमें सफल और असफल दोनों परिणाम शामिल हों।
- यूनिट और इंटीग्रेशन परीक्षण: व्यावसायिक नियमों को अलग-अलग जाँचें और पुष्टि करें कि डेटाबेस, API, कतारें और प्रमाणीकरण इच्छित रूप से साथ काम कर रहे हैं।
- नकारात्मक परीक्षण: अनुपस्थित, गलत प्रारूप वाले, अत्यधिक बड़े, डुप्लिकेट और अनधिकृत इनपुट भेजें। AI-जनित कोड अक्सर प्रॉम्प्ट में दिखाए गए रास्ते पर सबसे मजबूत दिखता है, इसलिए अनुरोध न किए गए रास्ते महत्वपूर्ण हैं।
- रिग्रेशन परीक्षण: खोजी गई हर खराबी को स्थायी परीक्षण में बदलें। किसी सुधार के बाद हरा डेमो पर्याप्त नहीं है, यदि अगली जेनरेट की गई बदलाव में वही विफलता लौट सकती है।
- सुरक्षा जाँच: एक्सेस कंट्रोल, सीक्रेट हैंडलिंग, इंजेक्शन से बचाव, निर्भरता की कमजोरियों और इस बात का परीक्षण करें कि अविश्वसनीय सामग्री टूल कॉल या विशेषाधिकार प्राप्त कार्रवाइयों को प्रभावित कर सकती है या नहीं।
- ऑपरेशनल जाँच: टाइमआउट, रीट्राई, इडेम्पोटेंसी, लॉगिंग, अलर्ट और किसी निर्भरता के अनुपलब्ध होने पर सुरक्षित व्यवहार की पुष्टि करें।
यह Stack Overflow के एजेंटिक सॉफ़्टवेयर विकास जीवनचक्र के वर्णन में बताए गए QA-इंजीनियरिंग दृष्टिकोण के क़रीब है। महत्वपूर्ण बदलाव सांस्कृतिक है: गुणवत्ता आश्वासन वह अंतिम निरीक्षण नहीं है जो AI के कोड लिखने के बाद किया जाता है। यह वह संरचना है जो तेज़ जेनरेशन को उपयोग के लिए पर्याप्त सुरक्षित बनाती है।
सिर्फ़ आउटपुट का नहीं, ऑर्केस्ट्रेशन का परीक्षण करें
जब सॉफ़्टवेयर में AI एजेंट शामिल हो, तो सामान्य एप्लिकेशन परीक्षण आवश्यक लेकिन अपर्याप्त होते हैं। सिस्टम इसलिए विफल हो सकता है कि मॉडल ने अनुरोध को गलत समझा, लेकिन यह इसलिए भी विफल हो सकता है कि आसपास के ऑर्केस्ट्रेशन ने संदर्भ खो दिया, किसी टूल को दो बार कॉल किया, गलत प्रारूप वाले संरचित आउटपुट को स्वीकार कर लिया या कभी समाप्त ही नहीं हुआ।
डाइजेस्ट में सुझाए गए प्री-डिप्लॉयमेंट रिग्रेशन क्षेत्र एक व्यावहारिक चेकलिस्ट हैं: संदर्भ की क्षति, टूल इडेम्पोटेंसी, प्रॉम्प्ट इंजेक्शन, संरचित आउटपुट, नॉन-टर्मिनेशन, रिट्रीवल ग्राउंडिंग और स्थिति का पुनर्सक्रियण। ये परीक्षण योग्य इंजीनियरिंग गुण हैं।
उदाहरण के लिए, एक परीक्षण वही अनुरोध दो बार चला सकता है और पुष्टि कर सकता है कि दूसरी कोशिश से डुप्लिकेट ऑर्डर न बने। दूसरा परीक्षण किसी वर्कफ़्लो के बीच में एजेंट को रोककर उसे पुनः शुरू कर सकता है और सत्यापित कर सकता है कि वह किसी अपरिवर्तनीय कार्रवाई को दोहराने के बजाय वैध स्थिति से आगे बढ़ता है। रिट्रीवल परीक्षण में सिस्टम से केवल स्वीकृत स्रोतों के सेट की जानकारी उद्धृत करने या लौटाने की अपेक्षा की जा सकती है। संरचित-आउटपुट परीक्षण अमान्य प्रतिक्रिया दे सकता है और पुष्टि कर सकता है कि एप्लिकेशन उसे वैध डेटा मान लेने के बजाय सुरक्षित रूप से अस्वीकार करता है।
लंबे समय तक चलने वाले और मल्टी-एजेंट सिस्टमों के लिए विफलताओं का विशेष रूप से स्पष्ट रिकॉर्ड आवश्यक है। शोधकर्ता स्वचालित विफलता-निर्धारण पर काम कर रहे हैं, क्योंकि यह पहचानना कठिन हो सकता है कि लंबी इंटरैक्शन श्रृंखला में किस एजेंट ने और किस बिंदु पर विफलता पैदा की। व्यावहारिक रूप से, टीमों को टूल कॉल, इनपुट, आउटपुट, मॉडल संस्करण, टाइमस्टैम्प, स्थिति परिवर्तन और अंतिम निर्णयों को गोपनीयता-सचेत ऑडिट ट्रेल में सुरक्षित रखना चाहिए। इस प्रमाण के बिना, लाल परीक्षण आपको बताता है कि कुछ विफल हुआ, लेकिन यह नहीं बताता कि उसे ठीक करना कहाँ से शुरू करें।
पुनरुत्पादनीयता करियर में बढ़त बनेगी
AI-जनित कोड परिवर्तनशील होता है। दोबारा चलाने पर अलग कार्यान्वयन मिल सकता है; मॉडल का अपडेट व्यवहार बदल सकता है; प्रदाता की आउटेज रूटिंग या विलंबता को बदल सकती है। इसलिए नियोक्ता उन उम्मीदवारों को महत्व देंगे जो मूल्यांकन को दोहराने योग्य बना सकते हैं।
इसका अर्थ है कि जहाँ संभव हो मॉडल स्नैपशॉट को पिन करना, प्रॉम्प्ट और कॉन्फ़िगरेशन रिकॉर्ड करना, प्लेटफ़ॉर्म अनुमति दे तो यादृच्छिकता को नियंत्रित करना और जिन कार्यों के परिणाम बदल सकते हैं उनके लिए कई ट्रायल चलाना। डाइजेस्ट विशेष रूप से पिन किए गए स्नैपशॉट, जहाँ उपलब्ध हो वहाँ कम या शून्य तापमान और आत्मविश्वास-सीमित CI/CD गेट को उपयोगी सुरक्षा उपायों के रूप में इंगित करता है।
एक व्यावहारिक रिपोर्ट में कम से कम तीन परिणामों के बीच अंतर स्पष्ट होना चाहिए:
- पास दर: कितने मामले सफल हुए।
- संगति: बार-बार चलाने पर वही मामला कितनी बार सफल होता है।
- गंभीरता: क्या विफलताएँ केवल दिखावटी हैं, असुविधाजनक हैं, डेटा को नुकसान पहुँचाती हैं, सुरक्षा से संबंधित हैं, या असुरक्षित बाहरी कार्रवाई करने में सक्षम हैं।
20 में से 19 कम-जोखिम वाले फ़ॉर्मैटिंग परीक्षण पास करने वाला सिस्टम आवश्यक नहीं कि उस सिस्टम से बेहतर हो जो 20 में से 18 मामले पास करता है, लेकिन कभी भी प्राधिकरण की सीमा पार नहीं करता। गुणवत्ता के मानदंड में विफलताओं का मूल्यांकन उनके परिणामों के अनुसार होना चाहिए।
मानवीय समीक्षा का लक्ष्य जोखिम होना चाहिए, हर पंक्ति नहीं
बेहतर स्वचालन का उद्देश्य यह नहीं है कि AI द्वारा उत्पादित हर टोकन को कोई व्यक्ति दोबारा पढ़े। इसका उद्देश्य मानवीय ध्यान उन निर्णयों पर केंद्रित करना है जिन्हें परीक्षण पूरी तरह तय नहीं कर सकते।
समीक्षकों को प्रमाणीकरण और प्राधिकरण, डेटा प्रतिधारण, वित्तीय या संविदात्मक कार्रवाइयों, गोपनीयता, माइग्रेशन, त्रुटि-पुनर्प्राप्ति, तृतीय-पक्ष अनुमतियों और सिस्टम के मूल्यांकन हार्नेस को स्वयं प्रभावित करने वाले परिवर्तनों पर ध्यान देना चाहिए। किसी एजेंट के मामले में, उन्हें यह भी देखना चाहिए कि वह किन टूल को कॉल कर सकता है, प्रत्येक टूल किन डेटा तक पहुँच सकता है, और क्या अपरिवर्तनीय कार्रवाई से पहले अनुमोदन आवश्यक है।
दिखाई देने वाले डिफ़, अनुमोदन कार्यप्रवाह, संग्रहीत वार्तालाप और ऑडिट लॉग—सहयोगात्मक AI कोडिंग के Slack Code के विवरण में रेखांकित सुविधाएँ—एक व्यापक अपेक्षा की ओर संकेत करते हैं: सॉफ़्टवेयर कैसे बनाया गया, इसका इतिहास महत्वपूर्ण होगा। समीक्षक को अनुरोध समझने, जनरेट किए गए बदलाव का निरीक्षण करने, परीक्षण के प्रमाण देखने और यह पहचानने में सक्षम होना चाहिए कि परिनियोजन को किसने अनुमोदित किया।
यह रिकॉर्ड अपने आप में नौकरशाही नहीं है। यह एक प्रभावशाली डेमो और ऐसे नियंत्रित बदलाव के बीच अंतर स्पष्ट करता है जिसे कोई अन्य व्यक्ति बनाए रख सकता है।
पोर्टफ़ोलियो या साक्षात्कार में क्या शामिल करें
उम्मीदवारों के लिए सबसे प्रभावशाली प्रदर्शन एक ऐसी छोटी प्रणाली है जिसमें गुणवत्ता की कहानी जानबूझकर स्पष्ट रखी गई हो। रिपॉज़िटरी, सेटअप निर्देश, आर्किटेक्चर संबंधी टिप्पणियाँ, परीक्षण कमांड, प्रतिनिधि परीक्षण मामले, ज्ञात सीमाएँ और एक संक्षिप्त विफलता रिपोर्ट शामिल करें। पाए गए एक या दो बग दिखाएँ और बताएँ कि उन्हें रिग्रेशन परीक्षणों में कैसे बदला गया। इस्तेमाल किए गए मॉडल या कोडिंग एजेंट की जानकारी दें, लेकिन टूल को इंजीनियरिंग निर्णयों का लेखक न बताएं।
यदि एप्लिकेशन किसी एजेंट का उपयोग करता है, तो टूल की अनुमतियों, स्टेट मॉडल, पुनःप्रयास नीति, समाप्ति की शर्त और मानवीय अनुमोदन के बिंदुओं का दस्तावेज़ीकरण करें। यदि यह रिट्रीवल का उपयोग करता है, तो दिखाएँ कि स्रोतों का चयन कैसे किया जाता है और प्रमाण उपलब्ध न होने पर क्या होता है। यदि यह बाहरी सेवाओं को कॉल करता है, तो टाइमआउट और डुप्लिकेट अनुरोधों के व्यवहार का प्रदर्शन करें।
एकल सफल रिकॉर्डिंग के आधार पर विश्वसनीयता का दावा न करें। जाँच योग्य दावा कुछ ऐसा होगा: “इन 12 परिदृश्यों के 30 रिकॉर्ड किए गए रन में, सिस्टम ने 28 में स्वीकृति मानदंड पूरे किए; दो विफलताओं में अस्पष्ट तारीख़ इनपुट शामिल था, और दोनों का दस्तावेज़ीकरण किया गया है।” संख्या स्वयं उतनी महत्वपूर्ण नहीं है जितनी विधि, सीमाएँ और जो अभी तक परीक्षण में नहीं आया है उसके बारे में ईमानदारी।
तेज़ी की नई परिभाषा
AI पहला संस्करण तैयार करने की लागत कम करता है। यह जानने की लागत समाप्त नहीं करता कि वह संस्करण भरोसे के योग्य है या नहीं। वास्तव में, तेज़ी से जनरेशन मूल्यांकन को और महत्वपूर्ण बना सकता है, क्योंकि परिनियोजनों के बीच अधिक संख्या में बिना समीक्षा किए गए बदलाव जमा हो सकते हैं।
वाइब-कोडिंग के बाद के पेशेवर का मूल्यांकन इस चक्र से किया जाएगा: व्यवहार परिभाषित करना, कोड जनरेट या संशोधित करना, वास्तविक और प्रतिकूल परिस्थितियों वाले मामलों का परीक्षण करना, उच्च-जोखिम वाले निर्णयों का निरीक्षण करना, विफलताओं को दर्ज करना और प्रमाण खोए बिना सिस्टम में सुधार करना। बेंचमार्क क्षमता की तुलना करने में मदद कर सकते हैं। QA प्रथाएँ तय करती हैं कि वह क्षमता भरोसेमंद सॉफ़्टवेयर बनती है या नहीं।
इसलिए गुणवत्ता का मानदंड यह नहीं है कि “क्या आप AI की मदद से कोई ऐप बना सकते हैं?” बल्कि यह है कि “क्या आप साबित कर सकते हैं कि ऐप क्या करता है, यह पहचान सकते हैं कि वह कब ऐसा करना बंद कर देता है, और ऐसी सीमाएँ बना सकते हैं जो किसी विफलता को घटना बनने से रोकें?”
