Yuri Gubin, DataArt में CTO – साक्षात्कार श्रृंखला

Yuri Gubin, DataArt में CTO एक अनुभवी प्रौद्योगिकी कार्यकारी और सॉफ़्टवेयर आर्किटेक्ट हैं जिन्होंने DataArt के साथ 18 से अधिक वर्षों तक काम किया है, सॉफ़्टवेयर आर्किटेक्चर, सॉल्यूशंस आर्किटेक्चर, क्लाउड प्रौद्योगिकी, नवाचार और कार्यकारी नेतृत्व सहित विभिन्न भूमिकाओं में प्रगति की, और मार्च 2026 में मुख्य प्रौद्योगिकी अधिकारी (Chief Technology Officer) बनें। उनका कार्य वित्तीय सेवाओं, स्वास्थ्य देखभाल, यात्रा और IoT सहित विभिन्न उद्योगों में जटिल प्रौद्योगिकी चुनौतियों को हल करने पर केंद्रित रहा है, विशेष रूप से क्लाउड कंप्यूटिंग, AI, डेटा प्लेटफ़ॉर्म और एंटरप्राइज़ सॉफ़्टवेयर आर्किटेक्चर में विशेषज्ञता के साथ। CTO बनने से पहले, गुबिन ने DataArt के चीफ़ इनोवेशन ऑफिसर के रूप में पाँच से अधिक वर्षों तक कार्य किया और 2021 से कंपनी के बोर्ड ऑफ़ पार्टनर्स के सदस्य हैं। वह Forbes Technology Council के पेशेवर सदस्य भी हैं, जहाँ वे AI और क्लाउड कंप्यूटिंग विशेषज्ञ समूहों में भाग लेते हैं, और Girls Who Code के लिए टेक्नोलॉजी एडवाइज़र के रूप में सेवा देते हैं, जहाँ वे आर्किटेक्चर, डेटा सुरक्षा, प्लेटफ़ॉर्म गवर्नेंस और प्रौद्योगिकी नीति पर सलाह देते हैं। DataArt वर्तमान में उन्हें न्यूयॉर्क स्थित मुख्य प्रौद्योगिकी अधिकारी के रूप में सूचीबद्ध करता है।

DataArt एक वैश्विक सॉफ़्टवेयर इंजीनियरिंग और डेटा एवं AI परिवर्तन कंपनी है जो 1997 में न्यूयॉर्क में स्थापित हुई थी। कंपनी ने 6,000 से अधिक प्रौद्योगिकी पेशेवरों को 20 से अधिक देशों में विस्तारित किया है और 400 से अधिक ग्राहकों के साथ काम करती है, जिसमें कृत्रिम बुद्धिमत्ता और मशीन लर्निंग, डेटा और विश्लेषण, क्लाउड परिवर्तन, कस्टम सॉफ़्टवेयर इंजीनियरिंग, साइबर सुरक्षा और लेगेसी मॉडर्नाइज़ेशन जैसी सेवाएँ शामिल हैं। DataArt वित्तीय सेवाओं, स्वास्थ्य देखभाल और जीवन विज्ञान, यात्रा, मीडिया और मनोरंजन, तथा रिटेल जैसे क्षेत्रों में कार्य करता है और AWS, Google Cloud, Microsoft Azure, Snowflake, और Databricks जैसे प्लेटफ़ॉर्म के साथ प्रौद्योगिकी साझेदारियाँ बनाए रखता है। 2025 में, कंपनी ने अपने डेटा और AI क्षमताओं में $100 मिलियन का तीन साल का निवेश घोषित किया, और 2026 में Artisyn का लॉन्च किया, जो एक AI-सक्षम ऑपरेटिंग मॉडल है जिसे AI एजेंट, पुन: प्रयोज्य एक्सेलेरेटर, गवर्नेंस, सुरक्षा और अनुपालन को एंटरप्राइज़ सॉफ़्टवेयर विकास में शामिल करने के लिए डिजाइन किया गया है।

आपने DataArt में लगभग दो दशकों तक काम किया है, सॉफ़्टवेयर आर्किटेक्ट और सॉल्यूशंस आर्किटेक्ट से लेकर चीफ़ इनोवेशन ऑफिसर और अब CTO तक की प्रगति की है। यह यात्रा आपको वास्तविक रूप से परिवर्तनकारी प्रौद्योगिकियों को हाइप के चक्रों से कैसे अलग करने में मदद करती है, और आज AI के प्रति आपके “संदेहपूर्ण आशावाद” को कैसे प्रभावित करती है?

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

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

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

यही वह जगह है जहाँ से संदेहपूर्ण आशावाद उत्पन्न होता है। चाहे प्रौद्योगिकी कुछ भी वादा करे, आपको अभी भी यह जानना आवश्यक है कि आप क्या कर रहे हैं, और यह ज्ञान अनुभव, सहयोग और निरंतर सीखने, सुधार करने और हाइप के पीछे किसी प्रकार की प्रणाली बनाने के प्रयास से आता है।

Enterprise AI प्रयोग को प्रोत्साहित करने के चरण से उन प्रयोगों को चुनने के चरण में बदल रहा है जो वास्तव में स्केल करने योग्य हैं। कौन‑से संकेत आपको बताते हैं कि एक AI उपयोग केस व्यापक तैनाती के लिए तैयार है, और कौन‑से चेतावनी संकेत दर्शाते हैं कि कोई कंपनी बहुत जल्दी स्केल कर रही है?

मैं दो तरीकों का उपयोग करता हूँ यह समझने के लिए कि क्या हम किसी चीज़ को स्केल कर सकते हैं या हमें कुछ और करना चाहिए: अपनाने की वक्र (adoption curve) और सीखने की वक्र (learning curve)।

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

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

हर प्रमुख मॉडल रिलीज़ संगठन के भीतर कर्मचारियों को तुरंत नवीनतम क्षमताओं तक पहुँच देने का दबाव बना सकती है। तकनीकी नेताओं को यह कैसे आकलन करना चाहिए कि नया मॉडल केवल प्रयोग और लागत की एक नई लहर उत्पन्न करने के बजाय सार्थक सुधार दर्शाता है या नहीं?

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

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

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

DataArt ने तकनीक, कानूनी, अनुपालन, InfoSec और अन्य टीमों को शामिल करते हुए एक क्रॉस‑फ़ंक्शनल “AI SWAT” बनाया है। यह समूह व्यावहारिक रूप से कैसे काम करता है, और कौन‑से जोखिम या प्रश्न नए AI टूल को व्यापक उपयोग के लिए अनुमोदित करने से पहले हल करने आवश्यक हैं?

शुरुआत से ही, मेरा मानना है कि हम इस समूह के लिए लगभग हर चार‑पाँच महीने में अलग‑अलग लक्ष्य निर्धारित करते आए हैं। हम प्राथमिकता, लक्ष्य और कभी‑कभी मिशन बदलते हैं, और इन लक्ष्यों में से कई AI से संबंधित होते हैं। यह कार्यबल को अपस्किल करना, बाजार‑में‑जाने की रणनीति और नई क्षमताएँ, साझेदारियाँ, या संगठन के भीतर और ADLC में AI को व्यापक रूप से सक्षम करना हो सकता है।

विषय समय के साथ विकसित होते रहते हैं, और यह स्वस्थ है क्योंकि आपको लगातार अपनी रणनीति की पुनः समीक्षा करनी पड़ती है, अपने अनुमान को सत्यापित करना पड़ता है, और यह समझना पड़ता है कि क्या आपको दिशा बदलनी चाहिए और टीम के अगले थीम क्या होने चाहिए।

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

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

कभी‑कभी AI SWAT टीम विशिष्ट कार्यक्रमों पर भी काम करती है, जैसे अपस्किलिंग, जहाँ हम लक्ष्य निर्धारित करते हैं, रोडमैप बनाते हैं और तय करते हैं कि विभिन्न समूह कैसे ऑनबोर्ड होंगे। यही वास्तव में इसका काम है: लोगों को सूचित रखना, विशिष्ट कार्यक्रमों पर साथ मिलकर काम करना, और बोर्ड को कंपनी में AI के साथ क्या हो रहा है, इसकी दृश्यता प्रदान करना।

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

संभवतः जो अंतर पैदा करता है, वह उनके जोखिम सहनशीलता और अनिश्चितता एवं अस्पष्टता के प्रति उनके रवैये में है। दोनों प्रकार के संगठनों को निरंतर शिक्षा, प्रयोग और मूल्यांकन से मदद मिलती है। उन कई संगठनों में भी, जो AI को अपनाते हैं और इसे हर जगह एकीकृत करते हैं, परिणाम और प्रभाव को मापने में अभी भी चुनौतियाँ रहती हैं। ईमानदारी से कहें तो, AI के प्रभाव को कैसे मापें और टीम के प्रदर्शन का मूल्यांकन कैसे करें, यह प्रश्न अक्सर अचानक उभरता है, जैसे किसी ने पहले कभी इस पर विचार नहीं किया हो।

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

एजेंटिक AI व्यक्तिगत टीमों के लिए अपने स्वयं के एजेंट बनाने को लगातार आसान बना रहा है, जिससे कई एजेंट लगभग समान कार्य कर सकते हैं। प्रयोग कब एजेंट स्प्रॉल बन जाता है, और स्वामित्व, अनुमतियों, डुप्लिकेशन और जीवनचक्र प्रबंधन को संभालने के लिए किस प्रकार की गवर्नेंस लेयर आवश्यक है?

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

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

इसलिए मेरा मानना है कि इसे परियोजना स्तर पर, संभवतः कार्यक्रम स्तर पर, और फिर विभाग तथा संगठनात्मक स्तरों पर भी समन्वित प्रयास होना चाहिए।

टोकन उपभोग और इन्फ़रेंस लागत पायलट चरण में अपेक्षाकृत छोटी लग सकती है, लेकिन जब AI सिस्टम हजारों कर्मचारियों या स्वायत्त एजेंटों में तैनात होते हैं तो ये महत्वपूर्ण हो जाती हैं। उद्यमों को AI लागत प्रबंधन के बारे में कैसे सोचना चाहिए, और क्या आप अपेक्षा करते हैं कि AI कार्यभार के लिए विशेष रूप से FinOps जैसा कुछ उभरेगा?

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

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

इसलिए हाँ, मेरा मानना है कि AI FinOps एक अच्छा विषय है जिसे AI SWAT टीम के समकक्ष चर्चा कर सकती है: आप कितना खर्च करते हैं, आपको कितना वापस मिलता है, आप इसे कैसे नियंत्रित करते हैं, और अवसर कहाँ हैं।

कई कंपनियों से AI से ROI प्रदर्शित करने को कहा जा रहा है, जबकि उन्होंने AI के परिचय से पहले अपनी टीमों की उत्पादकता के लिए एक विश्वसनीय बेसलाइन स्थापित नहीं की थी। यदि संगठन यह निर्धारित करना चाहते हैं कि AI सार्थक व्यावसायिक मूल्य बना रहा है या नहीं, तो उन्हें वास्तव में क्या मापना चाहिए?

AI के प्रति आपके रवैये या वर्तमान स्थिति की परवाह किए बिना, शायद आप पहले से ही एजेंटों का व्यापक उपयोग कर रहे हैं या शायद आप सोच रहे हैं कि अगले वर्ष आप AI का उपयोग शुरू करेंगे, इस समय बेसलाइन स्थापित करना बिल्कुल आवश्यक है।

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

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

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

DataArt ने Artisyn जैसी पहलों के माध्यम से सॉफ़्टवेयर डिलीवरी लाइफ़साइकल में AI को एकीकृत किया है। जैसे-जैसे AI अधिक इम्प्लीमेंटेशन, टेस्टिंग और वर्कफ़्लो कार्यों को संभालता है, सॉफ़्टवेयर इंजीनियरिंग के कौन से हिस्से मानवों के लिए अधिक मूल्यवान बनते हैं, और कौन सी क्षमताएँ कम महत्वपूर्ण होने का जोखिम रखती हैं?

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

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

किसी विशेष समाधान के लिए क्या उपयुक्त है, इसका संतुलन ही मानव पहलू है। यह सेवाओं और सॉफ़्टवेयर विकास के पीछे की स्वाद, शिल्पकला है। आपको यह जानना चाहिए कि आप क्या कर रहे हैं, और यह ग्राहक और उद्योग को समझने से भी आता है।

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

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

जैसे ही उद्यम दर्जनों AI पायलट से उन उत्पादन प्रणालियों की ओर बढ़ते हैं जो स्वतंत्र रूप से कार्य कर सकती हैं, जब एक AI एजेंट महंगा गलती करता है तो जवाबदेही अंततः किसके पास होनी चाहिए: डेवलपर, व्यवसाय मालिक, मॉडल प्रदाता, गवर्नेंस टीम, या उनका कोई संयोजन?

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

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

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

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

यदि यूनिट टेस्ट की कमी ने खराब कोड को उत्पादन में धकेलने की अनुमति दी, या निगरानी और समीक्षा की कमी ने इसे संभव बनाया, तो आप उस जवाबदेही को AI को नहीं सौंप सकते। आप हर बग या आउटेज के लिए मॉडल प्रदाता या क्लाउड प्रदाता को भी सरलता से दोषी नहीं ठहरा सकते।

बहुत अच्छा इंटरव्यू के लिए धन्यवाद, पाठकों जिन्हें और अधिक जानना है उन्हें DataArt पर जाना चाहिए।