प्रिंस कोहली, सॉस लैब्स के अध्यक्ष और सीईओ – इंटरव्यू श्रृंखला

Prince Kohli, Sauce Labs के अध्यक्ष और सीईओ, एक अनुभवी प्रौद्योगिकी कार्यकारी हैं जिनका अनुभव कृत्रिम बुद्धिमत्ता, एंटरप्राइज़ सॉफ़्टवेयर, क्लाउड कंप्यूटिंग, ऑटोमेशन, नेटवर्किंग और साइबर सुरक्षा तक विस्तृत है। Sauce Labs में फरवरी 2025 में शामिल होने से पहले, उन्होंने Automation Anywhere में मुख्य प्रौद्योगिकी अधिकारी के रूप में छह से अधिक वर्षों तक कार्य किया, जहाँ उन्होंने बड़े उद्यमों के लिए एआई‑आधारित ऑटोमेशन तकनीकों को आगे बढ़ाया। इससे पहले, कोहली ThoughtSpot में वरिष्ठ उपाध्यक्ष (इंजीनियरिंग) के रूप में कार्यरत थे और Ericsson में वरिष्ठ नेतृत्व भूमिकाएँ निभाते हुए 10,000 से अधिक इंजीनियरों वाली वैश्विक अनुसंधान एवं विकास टीमों की देखरेख की। उन्होंने Citrix में लगभग एक दशक तक प्लेटफ़ॉर्म, क्लाउड नेटवर्किंग, इंजीनियरिंग और संचालन पहलों का नेतृत्व किया। अपने करियर की शुरुआत में, उन्होंने एप्लिकेशन सुरक्षा कंपनी Teros की सह‑स्थापना की और SGI में तकनीकी लीड के रूप में काम किया। कार्यकारी भूमिकाओं के साथ-साथ, कोहली ने Ethical AI Governance Group के माध्यम से प्रौद्योगिकी शासन पहलों में योगदान दिया और पहले World Economic Forum के Safe Systems and Technologies कार्य समूह में भाग लिया।

Sauce Labs एक सॉफ़्टवेयर गुणवत्ता और निरंतर परीक्षण कंपनी है जो उद्यमों को ब्राउज़र, ऑपरेटिंग सिस्टम, वर्चुअल वातावरण और वास्तविक डिवाइसों पर वेब और मोबाइल एप्लिकेशन परीक्षण के लिए इन्फ्रास्ट्रक्चर और टूल्स प्रदान करती है। इसका प्लेटफ़ॉर्म स्वचालित और मैनुअल परीक्षण, विज़ुअल टेस्टिंग, मोबाइल ऐप वितरण, त्रुटि रिपोर्टिंग और एआई‑संचालित टेस्ट लेखन एवं विश्लेषण जैसी क्षमताओं को समर्थन देता है, साथ ही सामान्य निरंतर एकीकरण और डिलीवरी वर्कफ़्लो के साथ एकीकृत होता है। Sauce Labs अपनी तकनीक को AURA, यानी AI‑Unified Release Assurance प्लेटफ़ॉर्म के आसपास अधिकाधिक स्थापित कर रहा है, जो एआई एजेंटों का उपयोग करके परीक्षणों को उत्पन्न, निष्पादित और विश्लेषित करता है, जबकि सॉफ़्टवेयर रिलीज़ प्रक्रिया के दौरान मानवीय निगरानी बनाए रखता है। कंपनी के अनुसार, इसका इन्फ्रास्ट्रक्चर अब तक 8.7 बिलियन से अधिक परीक्षण निष्पादन और 300,000 से अधिक उद्यम उपयोगकर्ताओं का समर्थन कर चुका है, जो लगभग दो दशकों के क्रॉस‑प्लेटफ़ॉर्म परीक्षण डेटा पर आधारित है।

Sauce Labs में शामिल होने से पहले, आप Automation Anywhere में एआई‑आधारित ऑटोमेशन का नेतृत्व कर रहे थे और Ericsson तथा Citrix सहित कई कंपनियों में प्रमुख क्लाउड और इंजीनियरिंग संगठनों का प्रबंधन कर रहे थे। इन अनुभवों ने सॉफ़्टवेयर‑गुणवत्ता समस्या के प्रति आपके दृष्टिकोण को कैसे आकार दिया, और क्या कारण था जिससे आपने Sauce Labs में एआई‑नेटिव रिलीज़ आश्वासन को मुख्य प्राथमिकता बना दिया?

Ericsson और Citrix में मैंने देखा कि एक सॉफ़्टवेयर दोष कितनी जल्दी फैल सकता है और वैश्विक इन्फ्रास्ट्रक्चर को प्रभावित कर सकता है, जिससे सुरक्षा, ग्राहक संचालन, भरोसा और राजस्व पर बड़े प्रभाव पड़ते हैं। Automation Anywhere ने मुझे दिखाया कि एआई कैसे कार्य की गति और संरचना को बदल देता है, और यह स्पष्ट हो गया कि परीक्षण को एआई‑जनित सॉफ़्टवेयर की गति के अनुरूप पुनः निर्मित करना आवश्यक है। Sauce Labs ने परीक्षण ऑटोमेशन में अग्रणी भूमिका निभाई है, इसलिए एआई‑नेटिव रिलीज़ आश्वासन अगली बड़ी समस्या है जिसे हम हल करने के लिए बने हैं।

Sauce Labs की शोध ने पाया कि 80 % संगठनों ने उत्पादन में एक घटना, आउटेज या ग्राहक‑प्रभावित दोष को एआई‑जनित कोड से जोड़ा है। क्या यह मुख्यतः एआई द्वारा उत्पन्न कोड की कमजोरियों की ओर इशारा करता है, या एआई कोडिंग टूल्स अपनाने वाले उद्यमों की परीक्षण और शासन प्रक्रियाओं को अद्यतन न करने की ओर?

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

एआई‑जनित कोड सूक्ष्म बग और सुरक्षा मुद्दे पेश कर सकता है और उद्यमों को यह कोड उन परीक्षण और शासन प्रक्रियाओं के माध्यम से ले जाना पड़ता है जो पहले से ही गति के साथ तालमेल बिठाने में संघर्ष कर रही थीं। यह एक ट्रिलियन‑डॉलर का निष्पादन समस्या बन जाता है: एआई सॉफ़्टवेयर निर्माण को तेज़ कर सकता है, लेकिन आधुनिक रिलीज़ आश्वासन के बिना यह बगों को भी तेज़ी से बढ़ाता है। हर बग अंततः पकड़ा जाएगा, इसलिए कंपनियों को यह सुनिश्चित करना चाहिए कि ग्राहक या हमलावर से पहले बग का पता चल जाए।

रिपोर्ट बताती है कि डेवलपर्स 741 % अधिक कोड उत्पन्न कर रहे हैं, जबकि रिलीज़ गति केवल 20 % से कम बढ़ी है। वैधता प्रणालियों को गति से तालमेल रखने से क्या रोक रहा है, और सॉफ़्टवेयर विकास जीवन‑चक्र में सबसे बड़ा बाधा आमतौर पर कहाँ उत्पन्न होती है?

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

सर्वेक्षण किए गए उद्यमों में से आधे से अधिक ने जानबूझकर महत्वपूर्ण दोषों के साथ सॉफ़्टवेयर जारी किया, जबकि 66 % ने कहा कि उन्होंने समयसीमा पूरी करने के लिए गुणवत्ता या परीक्षण मानकों से समझौता किया। संगठन इस स्तर के जोखिम को क्यों स्वीकार कर रहे हैं, और सॉफ़्टवेयर गुणवत्ता को व्यावसायिक स्तर की प्राथमिकता बनाने के लिए क्या बदलाव आवश्यक हैं, न कि केवल अंतिम इंजीनियरिंग चेकपॉइंट?

संगठन जोखिम स्वीकार करते हैं क्योंकि रिलीज़ लक्ष्य सीधे ग्राहक, राजस्व और उत्पाद प्रतिबद्धताओं से जुड़े होते हैं, और दोषों की लागत अक्सर कई टीमों में बाद में प्रकट होती है। गुणवत्ता तभी व्यावसायिक प्राथमिकता बनती है जब नेता उत्पादन घटनाओं, ग्राहक प्रभाव, सुरक्षा जोखिम, पुनः कार्य लागत और विलंबित राजस्व को रिलीज़ गति के साथ मापते हैं।

Sauce Labs AURA को एक बंद‑लूप प्लेटफ़ॉर्म के रूप में पेश कर रहा है जो टेस्ट लिखता, चलाता और विश्लेषण करता है, जबकि प्रत्येक रिलीज़ से सीखता है। यह तकनीकी और परिचालन रूप से AI‑सहायता प्राप्त टेस्ट जनरेशन, स्वयं‑मरम्मत टेस्ट स्क्रिप्ट्स या अन्य ऑटोमेशन टूल्स से कैसे अलग है जो इंजीनियरिंग टीमों द्वारा पहले से उपयोग किए जा रहे हैं?

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

AURA को “व्यवसायिक इरादा” के विरुद्ध सॉफ़्टवेयर को सत्यापित करने के लिए डिज़ाइन किया गया है। वह इरादा कैसे परिभाषित और टेस्ट योग्य आवश्यकताओं में अनुवादित किया जाता है, इसे मंजूरी देने की जिम्मेदारी किसकी है, और प्लेटफ़ॉर्म अस्पष्ट, अपूर्ण या व्याख्या योग्य आवश्यकताओं को कैसे संभालता है?

व्यवसायिक इरादा उत्पाद आवश्यकताओं, स्वीकृति मानदंडों, व्यावसायिक नियमों, उपयोगकर्ता यात्राओं और ग्राहकों द्वारा वास्तविक उपयोग से आता है। उत्पाद नेता अपेक्षित परिणाम को परिभाषित करते हैं, और इंजीनियरिंग एवं क्वालिटी टीमें उस परिणाम को सिस्टम के व्यवहार में अनुवादित करती हैं जिसे सिस्टम सत्यापित कर सकता है। जब आवश्यकताएँ अपूर्ण या अस्पष्ट होती हैं, तो AURA अनिश्चितता को उजागर करता है और अपेक्षित परिणाम बदलने से पहले मानवीय अनुमोदन मांगता है।

Sauce Labs रिपोर्ट करता है कि AURA उपयोग करने वाले उद्यमों ने उत्पादन घटनाओं में 90 % कमी, रिलीज़ चक्र में 47 % तेज़ी, और इंजीनियरिंग क्षमता में 38 % पुनः प्राप्ति देखी है। ये परिणाम किस प्रकार मापे गए, किस अवधि में, और AURA के प्रभाव को अन्य संगठनात्मक या इंजीनियरिंग बदलावों से अलग करने के लिए कौन सा स्वतंत्र सत्यापन उपयोग किया गया?

एंटरप्राइज़ डिप्लॉयमेंट में, हमने AURA लागू करने के बाद उत्पादन घटनाओं, रिलीज़‑साइकल गति और इंजीनियरिंग क्षमता में बदलाव मापा। इन डिप्लॉयमेंट ने 90 % से अधिक उत्पादन घटनाओं में कमी, 47 % तेज़ रिलीज़ चक्र और 38 % इंजीनियरिंग क्षमता की पुनः प्राप्ति देखी, और परिणाम स्वतंत्र रूप से सत्यापित किए गए। Walmart और Keller Williams जैसे ग्राहक भी रिलीज़ आवृत्ति, टेस्ट कवरेज और साइकल टाइम में उल्लेखनीय सुधार की रिपोर्ट कर चुके हैं।

शोध ने पाया कि 64 % संगठनों ने गुणवत्ता आश्वासन कर्मियों की संख्या बढ़ा दी, जबकि घटनाएँ बढ़ती रही। क्यों उद्यम केवल अधिक टेस्टर्स को नियुक्त करके सत्यापन अंतर को नहीं भर सकते, और जैसे-जैसे परीक्षण अधिक स्वायत्त होता जाएगा, डेवलपर्स, क्वालिटी इंजीनियर्स और साइट रिलेबिलिटी टीमों की जिम्मेदारियों में क्या परिवर्तन की उम्मीद है?

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

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

मानव को रिलीज़ निर्णयों पर अंतिम अधिकार रखना चाहिए, विशेषकर जब निर्णय, ग्राहक प्रभाव या व्यावसायिक जोखिम शामिल हो। एआई एजेंट्स दोहराव वाले, स्पष्ट‑परिभाषित परीक्षण कार्यों को स्वचालित कर सकते हैं, लेकिन जब कोड या टेस्ट परिणाम पूरी तरह समझे, समझाए या पुनः उत्पन्न नहीं किए जा सकते, तो मानव को उत्पादन रिलीज़ को अनुमोदित करना चाहिए। समीक्षा तब भी अनिवार्य होनी चाहिए जब आवश्यकताएँ अस्पष्ट हों, सुरक्षा कमजोरियों की संभावना हो, तृतीय‑पक्ष घटकों का पर्याप्त सत्यापन न हुआ हो, या विफलताएँ राजस्व, संवेदनशील डेटा, ग्राहक अनुभव या मिशन‑क्रिटिकल ऑपरेशन्स को प्रभावित कर सकती हों।

ऐसे मामलों में, अनिर्दिष्ट व्यवहार, असंगत टेस्ट परिणाम या रिलीज़ तत्परता के अपर्याप्त प्रमाण स्वचालित रूप से रिलीज़ को रोक देना चाहिए।

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

आप Ethical AI Governance Group और World Economic Forum के Safe Systems and Technologies कार्य समूह के साथ भी काम कर चुके हैं। जैसे-जैसे एआई‑जनित कोड और स्वायत्त परीक्षण गहराई से जुड़ते जा रहे हैं, कौन‑से शासन मानक उद्यमों को अपनाने चाहिए ताकि तेज़ सॉफ़्टवेयर निर्माण नई प्रणालीगत, सुरक्षा या जवाबदेही जोखिम न लाए?

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

बहुत‑बहुत धन्यवाद इस शानदार इंटरव्यू के लिए, अधिक जानने के इच्छुक पाठकों को Sauce Labs पर जाना चाहिए।