एजेंटिक एआई को कम नहीं, ज़्यादा परीक्षकों की ज़रूरत है

एजेंटिक एआई सॉफ्टवेयर बनाने और जारी करने के तौर-तरीके बदल रहा है। सहायक पुल रिक्वेस्ट के मसौदे तैयार करते हैं, एजेंट माइग्रेशन शुरू करते हैं और समीक्षा करने वाले बॉट दावा करते हैं कि कोई बदलाव सुरक्षित है—इससे पहले कि इंसान अपनी कॉफी खत्म कर पाए। उद्योग अक्सर इसे गुणवत्ता के काम में कम लोगों की ज़रूरत पड़ने की राह के रूप में पेश करता है। यह सोच उलटी है। जब मशीनें कोडबेस का ज़्यादा हिस्सा लिखती हैं, तो सबसे दुर्लभ कौशल कोड बनाना नहीं रह जाता। वह है स्वतंत्र रूप से उसकी पुष्टि करना।

2025 के Stack Overflow डेवलपर सर्वेक्षण में पाया गया कि 84% उत्तरदाता विकास कार्यों में एआई टूल इस्तेमाल कर रहे हैं या करने की योजना बना रहे हैं, और 51% पेशेवर डेवलपर इनका रोज़ाना इस्तेमाल करते हैं। एआई के प्रति सकारात्मक रुझान घटकर 60% रह गया, और एआई की सटीकता पर भरोसा करने वालों (33%) की तुलना में उस पर सक्रिय रूप से अविश्वास करने वाले डेवलपर अधिक थे (46%)। 66% लोगों ने जिस सबसे बड़ी निराशा का ज़िक्र किया, वह थे ऐसे समाधान जो लगभग सही होते हैं, मगर पूरी तरह नहीं। Google Cloud के 2025 के DORA शोध में बताया गया कि सॉफ्टवेयर विकास पेशेवरों में एआई को अपनाने की दर 90% थी और 80% से अधिक लोगों का कहना था कि एआई ने उत्पादकता बढ़ाई है; फिर भी केवल 24% ने एआई पर बहुत अधिक या काफ़ी भरोसा होने की बात कही। भरोसे के बिना उपयोगिता ही वह स्थिति है जो परीक्षक के काम को घटाने के बजाय बढ़ाती है।

तेज़ी सबूत नहीं होती

मैं सॉफ्टवेयर गुणवत्ता इंजीनियर के रूप में काम करता हूँ और मेरा ध्यान एजेंटिक परीक्षण तथा एआई द्वारा लिखे गए कोड के लिए सीआई गेट पर है। हमने अपनी टीम में पुल रिक्वेस्ट की समीक्षा करने वाला टूल और टेस्ट केस बनाने वाला टूल जारी किया। दोनों ही मसौदे तैयार करने के औज़ार हैं। इनमें से कोई भी अपने ही काम को अंक नहीं देता। यह नियम अहम है, क्योंकि एजेंट पूरे यक़ीन से बात करते हैं। यक़ीन का मतलब सही होना नहीं है।

यह बात हमें महँगी कीमत चुकाकर समझ आई। एआई से बने पुल रिक्वेस्ट समीक्षक के एक प्रायोगिक परीक्षण में, एक बदलाव 4 मिनट से भी कम समय में सीआई से पास हो गया। दो दिन बाद, उससे जुड़े अगले डैशबोर्ड पर असंभव तापमान दिखाई दिए। सेल्सियस से फ़ारेनहाइट में रूपांतरण का पैमाना उलटने की गड़बड़ी कोड के ऐसे रास्ते में थी जिसे टेस्ट सूट ने कभी जाँचा ही नहीं था। पाइपलाइन की स्थिति हरी थी। उत्पाद गलत था। कठिन सवाल पूछे बिना ही सफल दिखने वाला सीआई महज़ दिखावा है।

यह घटना एक व्यापक रुझान का हिस्सा है। CodeRabbit की एआई बनाम मानव कोड निर्माण की स्थिति पर रिपोर्ट में GitHub की 470 ओपन-सोर्स पुल रिक्वेस्ट का विश्लेषण किया गया (320 एआई की सह-लेखक वाली और 150 केवल मनुष्यों की लिखी हुई)। एआई द्वारा लिखे गए बदलावों में कुल मिलाकर लगभग 1.7 गुना अधिक समस्याएँ मिलीं; तर्क और शुद्धता से जुड़ी समस्याएँ 75% अधिक आम थीं और सुरक्षा संबंधी निष्कर्ष 2.74 गुना तक अधिक थे। Veracode की 2026 की जनरेटिव एआई कोड सुरक्षा रिपोर्ट में अलग-अलग सुरक्षा कार्यों के लिए मॉडलों का परीक्षण किया गया। इसमें सुरक्षा परीक्षणों में पास होने की औसत दर 56% पाई गई—जो पिछली रिपोर्ट के 55% से मुश्किल से ही बदली थी—जबकि एआई कोड निर्माण के लगभग 44% कार्यों में एक ज्ञात कमज़ोरी आ गई। सिंटैक्स की समस्या लगभग हल हो चुकी है। सुरक्षित और सही ढंग से काम करने वाला व्यवहार अब भी हल नहीं हुआ है। परीक्षक वे लोग हैं जो इन दोनों को एक समझने से इनकार करते हैं।

काल्पनिक निर्भरताएँ परीक्षण की समस्या हैं

कोड बनाने की प्रक्रिया में ऐसे पैकेज भी गढ़े जाते हैं जो मौजूद ही नहीं होते। USENIX Security 2025 के शोध आपके लिए एक पैकेज है! में कोड बनाने वाले 16 बड़े भाषा मॉडल और 576,000 नमूनों के आधार पर काल्पनिक पैकेजों का मूल्यांकन किया गया। व्यावसायिक मॉडलों ने औसतन कम-से-कम 5.2% मामलों में पैकेज गढ़े; ओपन-सोर्स मॉडलों में यह औसत 21.7% था और उन्होंने 205,474 अलग-अलग काल्पनिक नाम बनाए। ऐसे काल्पनिक पैकेज लगातार बने रहें, तो स्लॉप-स्क्वैटिंग के लिए आसान निशाना तैयार हो जाता है: हमलावर गढ़ा हुआ नाम पंजीकृत करते हैं और किसी डेवलपर या एजेंट के उसे इंस्टॉल करने का इंतज़ार करते हैं।

निर्भरता के स्रोत की जाँच को कार्यक्षमता संबंधी परीक्षणों के समान ही अहम स्तर पर होना चाहिए। अगर कोई एजेंट NuGet या npm का ऐसा पैकेज गढ़ता है जो मौजूद नहीं है, तो यूनिट टेस्ट कितने गहन थे, इस पर चर्चा शुरू होने से पहले ही मर्ज रुक जाना चाहिए। स्रोत की पुष्टि करना कोई वैकल्पिक सफ़ाई-काम नहीं है। एआई द्वारा लिखे गए बदलावों के लिए यह गुणवत्ता जाँच का एक अनिवार्य पड़ाव है।

एजेंटों के साथ बढ़ने वाली जाँचें

जब हमने एआई-सहायता वाली स्वचालित प्रक्रिया से लगभग दो हफ़्तों में पूरे संगठन को .NET 8 से .NET 10 पर अपग्रेड किया, तो गुणवत्ता जाँच की ज़िम्मेदारी मेरी थी। काम की रफ़्तार सचमुच बढ़ी। लेकिन ऐसी जाँचों की ज़रूरत भी उतनी ही वास्तविक थी जो एजेंट के सारांश पर आँख मूँदकर भरोसा न करें। बदले गए कोड पर मैं ये जाँचें करता हूँ:

• बदले गए लॉजिक के लिए म्यूटेशन स्कोर का लक्ष्य 60% से 70% के दायरे में रखना, ताकि टेस्ट सूट वास्तविक म्यूटेंट को पकड़ने में सफल हो, न कि केवल कोड की पंक्तियों को कवर करे
• ज़्यादा जोखिम वाले लॉजिक पर प्रॉपर्टी-आधारित परीक्षण करना, जहाँ केवल उदाहरणों से व्यवहार की पूरी जानकारी नहीं मिलती
• स्लॉप-स्क्वैटिंग और काल्पनिक पैकेजों से बचाव के लिए निर्भरता के स्रोत की जाँच करना
• ऐसे दोहराव और बार-बार बदलाव के संकेतों पर नज़र रखना जो एजेंटों की कॉपी-पेस्ट की हड़बड़ी को उजागर करें
• एजेंट के दावों की स्वतंत्र रूप से पुष्टि करना—जैसे “माइग्रेशन पूरा हुआ”—क्योंकि सबूत मिलने तक कोई भी दावा महज़ एक परिकल्पना होता है

म्यूटेशन स्कोर दिखावे के लिए रखा गया आँकड़ा नहीं है। यह जाँचता है कि आपके टेस्ट जानबूझकर डाली गई किसी गड़बड़ी को पकड़ते हैं या नहीं। कोड कवरेज बढ़ सकता है, जबकि टेस्ट सूट फिर भी सेल्सियस वाले रास्ते की गड़बड़ी चूक जाए। प्रॉपर्टी-आधारित जाँच यह सुनिश्चित करती है कि सिस्टम का मॉडल अलग-अलग दायरों में सही रहे, न कि केवल एक अनुकूल स्थिति में। स्रोत की पुष्टि से पैकेजों का भंडार सुरक्षित रहता है। बार-बार बदलाव और दोहराव से एजेंट की एक ही विचार को तीन तरीकों से फिर लिखने की आदत पकड़ में आती है। ये सब मिलकर एक कार्यशैली बनाते हैं: जब तक टेस्ट सूट कुछ और साबित न करे, मानकर चलें कि एजेंट गलत है। समीक्षा के दौरान मैं इसी कसौटी को बनाए रखता हूँ।

इनमें से कोई भी एपीआई परीक्षण, प्रमाणीकरण परीक्षण, स्मोक परीक्षण या यूआई स्वचालन की जगह नहीं लेता। FlaUI और PowerShell अब भी उन समस्याओं को पकड़ते हैं जो एपीआई की नज़र से छूट जाती हैं। NuGet, MSI और MSM के ज़रिए पैकेज तैयार करने में अब भी इंस्टॉल की जाँच और बिना किसी संवाद के चलने वाले तरीके का सत्यापन ज़रूरी है। एजेंटिक कार्यप्रवाह काम की मात्रा बढ़ाते हैं। वे इन अनुशासनों को अप्रासंगिक नहीं बनाते।

ज़्यादा परीक्षक, काम का अलग स्वरूप

डर यह है कि एजेंट परीक्षण लिखेंगे और इंसानों की ज़रूरत ही नहीं रहेगी। एजेंट परीक्षण-मामलों के मसौदे बना सकते हैं। उन्हें अपने ही मसौदों को प्रमाणित नहीं करना चाहिए। भविष्य में परीक्षण के लिए एआई का इस्तेमाल करने की योजना बना रहे Stack Overflow के उत्तरदाताओं के लिए भी इंसानों का अविश्वास अहम था: जब वे मदद के लिए किसी दूसरे व्यक्ति से पूछते, तो इसकी सबसे बड़ी वजह यह थी कि उन्हें एआई के जवाबों पर भरोसा नहीं था। यही सहज समझ इस पेशे की ताकत है।

यहाँ उन लोगों को काम पर रखना और आगे बढ़ने में मदद देना अहम है, जिन्होंने गैर-पारंपरिक रास्तों से यहाँ तक का सफ़र तय किया है। मानव संसाधन संचालन और डेटा के क्षेत्र में काम करने के बाद मैंने गुणवत्ता के क्षेत्र में कदम रखा, मई 2024 में UMBC से सूचना प्रणालियों में मास्टर ऑफ़ साइंस की डिग्री पूरी की, और अब अपना दिन एजेंटिक गेट्स को व्यावहारिक बनाने में बिताता हूँ। एजेंटिक एआई किसी एक ही तरह की शैक्षिक या पेशेवर पृष्ठभूमि वाले लोगों का इंतज़ार नहीं करेगा। इसे ऐसे और लोगों की ज़रूरत है जो साक्ष्य तैयार कर सकें, न कि ऐसे कम लोग जो बिना जाँच किए सफल बिल्ड को मंज़ूरी दे दें।

उत्पाद से जुड़ा सवाल सीधा है। अगर एजेंट आपकी सत्यापन प्रक्रिया के सोच पाने से तेज़ी से उत्पाद जारी करते हैं, तो यह उत्पादकता में बढ़त नहीं है। यह एक ऐसी घटना है जिसे टालकर आगे के लिए छोड़ दिया गया है। ऐसे परीक्षकों में निवेश करें जो एजेंट के हर दावे को संदेह की नज़र से देखते हैं, CI में म्यूटेशन और उद्गम-सूचना जोड़ते हैं, और जहाँ मॉडल सबसे अधिक धाराप्रवाह, लेकिन सबसे कम विश्वसनीय होता है, वहाँ स्वतंत्र निर्णय बनाए रखते हैं। एजेंटिक एआई को कम नहीं, बल्कि ज़्यादा परीक्षकों की ज़रूरत है।