जेरेमी फ्रीमैन, ऑलस्टैक्स के सह-संस्थापक और सीटीओ – साक्षात्कार श्रृंखला

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

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

आपके पास मशीन लर्निंग को सॉफ़्टवेयर विकास डेटा में लागू करने वाली अनुसंधान और इंजीनियरिंग टीमों का नेतृत्व करने से लेकर 2017 में ऑलस्टैक्स की सह-स्थापना तक एक अनोखा सफर रहा है। आपने जो विशिष्ट अंतराल या बार-बार आने वाली समस्याएं देखीं जिन्होंने अंततः आपको कंपनी बनाने के लिए प्रेरित किया?

जब हमने ऑलस्टैक्स शुरू किया, तो हमने शुरुआत में बहुत समय ग्राहक खोज में बिताया, और जो पैटर्न सामने आया वह लगातार था: कंपनी के बाद कंपनी के पास बहुत सारा डेटा था और फिर भी उन्हें यह नहीं पता था कि वास्तव में क्या हो रहा है। सॉफ़्टवेयर की डिलीवरी अप्रत्याशित थी,尽管 उनमें कमरे में सबसे चतुर लोग थे। उस समस्या का समाधान नहीं किया गया था।

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

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

ऑलस्टैक्स सॉफ़्टवेयर विकास जीवन चक्र में डेटा का विश्लेषण करता है। डिलीवरी जोखिम को जल्दी से पहचानने के लिए किस प्रकार के संकेत या पैटर्न सबसे अधिक प्रेडिक्टिव हैं?

मुझे लगता है कि एक ही सेट ऑफ मेट्रिक्स नहीं है जो अच्छा और बुरा बताता है, बल्कि विभिन्न चरणों और प्रकार के संगठनों के लिए पैटर्न हैं। मैंने जो अधिक उपयोगी पाया है वह यह है कि इंजीनियरिंग संगठन सुधार के मौसम से गुजरते हैं। इस महीने, यह डेटाबेस प्रदर्शन है। अगले महीने, यह क्रॉस-टीम संचार है। फिर यह “क्यों हम कोई पीआर बंद नहीं कर सकते?” फिर यह पर्यवेक्षणीयता है। एक इंजीनियरिंग नेता के रूप में, आप संकेतों में तैर रहे हैं: कुछ निदान, कुछ निगरानी, और बहुत कुछ जो केवल शोर है।

जो मदद करता है वह यह है कि आप जिस समस्या का सामना कर रहे हैं उससे शुरू करें, न कि किसी ऐसे मेट्रिक में सुधार करने की कोशिश करें जिसे आप सुधारना चाहते हैं। यदि आप “क्यों लगता है कि हम पिछले साल की तुलना में कम डिलीवर कर रहे हैं” पूछ रहे हैं, तो यह सही शुरुआती बिंदु है। वहाँ से, मुझे लगता है कि आपको तीन प्रकार के मेट्रिक्स की आवश्यकता है: पहला, समस्या वास्तविक है या नहीं (शायद प्रति डेवलपर पीआर गणना); दूसरा, आप क्या परिवर्तन कर रहे हैं और आप उन्हें कैसे ट्रैक कर रहे हैं; और तीसरा, यह समस्या व्यवसाय के लिए कितनी महत्वपूर्ण है। आपकी प्रवृत्ति यह हो सकती है कि आप सही हैं कि आप 20 प्रतिशत कम कोड शिपिंग कर रहे हैं, लेकिन वास्तविक कहानी यह हो सकती है कि क्यूए अब तीन गुना अधिक समय ले रहा है। आपको तीनों लेंस की आवश्यकता है ताकि आप यह जान सकें कि क्या आप सही चीज़ का समाधान कर रहे हैं।

आपने स्वास्थ्य सेवा, ऊर्जा और प्रौद्योगिकी जैसे उद्योगों में काम किया है। सॉफ़्टवेयर डिलीवरी में चुनौतियाँ इन क्षेत्रों में कैसे भिन्न हैं, और इससे ऑलस्टैक्स प्लेटफ़ॉर्म कैसे आकार दिया गया है?

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

यह दृष्टिकोण वास्तव में उपयोगी है। यह उद्योग में हमारे द्वारा की जाने वाली हर चीज़ को संदर्भ में रखता है, और यह कई प्रौद्योगिकी बहसों को उनकी जगह पर रखता है। व्यवसाय को परवाह नहीं है कि आप पाइथन या गो का उपयोग करते हैं या नहीं। उस रीव्राइट पर चक्र बिताना शायद वास्तविक रिटर्न नहीं है।

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

एक बढ़ती हुई कथा है कि एआई कोडिंग को तेज़ करते हुए दूसरी जगह कमजोरियों को उजागर कर रहा है। आवश्यकताओं, योजना, और विनिर्देश तैयारी वास्तविक बोतलनेक क्यों बन रहे हैं?

हम इसे दैनिक रूप से देख रहे हैं। एक अच्छे एजेंट और एक ठोस हार्नेस के साथ, आप वास्तव में एक ग्राहक के मुंह से एक विचार से उत्पादन में सीधे घंटों में जा सकते हैं।

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

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

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

बहुत से संगठन अभी भी उत्पादकता को पुराने मेट्रिक्स का उपयोग करके मापते हैं। एआई-चालित विकास वातावरण में उत्पादकता के बारे में नेताओं को क्या मूलभूत रूप से गलत हो रहा है?

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

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

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

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

आपका प्लेटफ़ॉर्म परियोजना प्रबंधन प्रणाली और कोड रिपॉजिटरी जैसे उपकरणों से डेटा को जोड़ती है। डेटा के इन खंडित स्रोतों को एकजुट करना कितना महत्वपूर्ण है, और जब संगठन ऐसा करने में विफल रहते हैं तो क्या होता है?

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

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

वह कनेक्शन आधार है। यही हमें बाजार में पहले क्षमताओं के साथ आने में सक्षम बनाया जो अभी तक प्रतिकृत नहीं हुए हैं।

जैसे ही एआई एजेंट विकास कार्य प्रवाह में अधिक एकीकृत हो जाते हैं, तो एक अच्छी तरह से तैयार इंजीनियरिंग संगठन और जो तैयार नहीं है उसमें क्या अंतर है?

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

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

एक निदान प्रश्न जो मैं किसी भी इंजीनियरिंग नेता से पूछूंगा: क्या आप मुझे बता सकते हैं कि आपके एजेंट ने पिछले स्प्रिंट में क्या उत्पादित किया, कि कितना आउटपुट को ऐसा ही स्वीकार किया गया और कितना संशोधित किया गया, और संशोधन प्रयास कहां केंद्रित था? यदि आप उस प्रश्न का उत्तर दे सकते हैं, तो आपके पास सुधार के लिए साधन हैं। यदि आप नहीं कर सकते हैं, तो आप भावना से उड़ रहे हैं।

आपने इंजीनियरिंग कार्य को व्यावसायिक परिणामों के साथ संरेखित करने के महत्व पर जोर दिया है। संगठन व्यावसायिक परिणामों के साथ इंजीनियरिंग प्रयासों को पुल करने के लिए व्यावसायिक और मापने योग्य तरीके से कैसे पुल कर सकते हैं?

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

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

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

आपके पास हाथों-हाथ इंजीनियरिंग और वेब विकास की शिक्षा देने का अनुभव है। क्या आप एआई कोडिंग कार्यभार को अधिक से अधिक अपने हाथ में लेते हुए डेवलपर्स की भूमिका को कैसे बदलते हुए देखते हैं?

ईमानदारी से, मैं थोड़ा चिंतित हूं, हालांकि मुझे विश्वास है कि स्मार्ट लोग इसे आउट फिगर करेंगे।

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

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

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

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

हम एक फीचर आर्म्स रेस देखेंगे जैसा हमने पहले कभी नहीं देखा है। जैसे ही निर्माण की लागत शून्य के करीब आती है, कंपनियों, यहां तक कि बड़ी कंपनियों को भी, एक नई प्रतिबंध का सामना करना पड़ता है: गुणवत्ता वाली चीजें बनाने के लिए पर्याप्त ग्राहक प्रतिक्रिया एकत्र करना और मापना।

होने वाला परिवर्तन यह है कि निर्माण के लिए बार को ऊपर करने की आवश्यकता है। वर्तमान प्रतिबंध अधिकांश इंजीनियरिंग संगठनों में सरल है: पांच शीर्ष प्राथमिकताएं, शायद दो वितरित। एजेंटों के साथ, अनुपात फ्लिप हो जाता है। आपके पास पांच शीर्ष, दस अगले, और शायद二十 हो सकते हैं, और आप सौ को शिप कर सकते हैं। प्रश्न यह है कि आप उन आखिरी पचास को खराब कल्पना और खराब निष्पादन से कैसे बचाते हैं।

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

साक्षात्कार के लिए धन्यवाद, पाठक जो और जानना चाहते हैं उन्हें ऑलस्टैक्स पर जाना चाहिए।