अली-रेज़ा अदल-तबाताबाई, गिटार के संस्थापक और सीईओ – साक्षात्कार श्रृंखला

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

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

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

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

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

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

एआई-जनित कोड के उदय के साथ, कई टीमें अब कोड ओवरलोड से जूझ रही हैं। यह समस्या आज उद्यमों के भीतर कितनी महत्वपूर्ण है, और टीमें सबसे ज्यादा संघर्ष कहां कर रही हैं?

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

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

यहीं पर घर्षण बैठता है। निर्माण में नहीं, बल्कि कोड को जोखिम के बिना फिनिश लाइन पार करने में。

उद्योग ने मुख्य रूप से कोड को तेजी से उत्पन्न करने पर ध्यान केंद्रित किया है। आप क्यों सोचते हैं कि मान्यकरण को नजरअंदाज किया गया है, और यह अब क्यों अधिक महत्वपूर्ण हो रहा है?

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

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

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

गिटार कोड समीक्षा, परीक्षण और निरंतर एकीकरण (सीआई) कार्य प्रवाहों को संभालने के लिए एआई एजेंटों का उपयोग करता है। ये एजेंट पारंपरिक स्थिर विश्लेषण उपकरणों और नियम-आधारित पाइपलाइनों से मूल रूप से कैसे भिन्न हैं?

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

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

यही कारण है कि बातचीत “क्या हमारे पास एजेंट हैं” से “वास्तव में कौन सा काम संभाला जा सकता है” में बदल रही है।

स्वचालन में विश्वास एक प्रमुख बाधा है सॉफ्टवेयर विकास में। गिटार अपनी मान्यकरण प्रक्रिया को इतना विश्वसनीय बनाने के लिए क्या करता है कि टीमें उस पर भरोसा कर सकें?

काम करने वाला पैटर्न सरल है। काम को छोटे चरणों में तोड़ें। स्पष्ट सीमाएं निर्धारित करें। निरंतर मान्यकरण करें। जोखिम वाले निर्णयों में मानवों को शामिल रखें।

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

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

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

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

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

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

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

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

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

अंतिम अवस्था एक नया उपकरण नहीं है जिसमें डेवलपर लॉग इन करते हैं। यह मौजूदा उपकरण हैं जो अपने दम पर अधिक काम करते हैं, ताकि डेवलपर्स अपने निर्णय लेने वाले काम पर ध्यान केंद्रित रख सकें।

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

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

पहला स्तर पता लगाना है। टीमें विश्वास बनाती हैं कि एजेंट वास्तविक मुद्दों को कम झूठी सकारात्मक दर के साथ पा सकते हैं। एक बार यह विश्वास स्थापित हो जाने के बाद, वे एआई को महत्वपूर्ण मुद्दों का पता लगाने पर स्वचालित रूप से पीआर को ब्लॉक करने देते हैं।

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

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

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

एआई के रूप में डिफ़ॉल्ट समीक्षक में बदलाव एक छलांग नहीं है। यह एक सीढ़ी है, और संगठन इसे एक बार में एक पायदान चढ़ते हैं क्योंकि साक्ष्य जमा होता है।

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

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

जैसा कि एजेंट पुनरावृत्ति मान्यकरण कार्य लेते हैं, इंजीनियर लूप में रहते हैं लेकिन स्टैक में ऊपर जाते हैं। वे मैनुअल ट्राइएज पर कम समय बिताते हैं और यह तय करने में अधिक समय बिताते हैं कि क्या जहाज करना चाहिए और क्यों।

गिटार ने हाल ही में 9 मिलियन डॉलर जुटाया है प्लेटफ़ॉर्म को स्केल करने के लिए। इस पूंजी के लिए आपकी शीर्ष प्राथमिकताएं क्या हैं, और अगले 12 से 18 महीनों में सफलता क्या दिखती है?

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

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

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