Gautam Korlam, Sonar के प्रधान इंजीनियर – साक्षात्कार श्रृंखला

Gautam Korlam, Sonar में प्रधान इंजीनियर, एक अनुभवी सॉफ़्टवेयर इंजीनियर और प्रौद्योगिकी नेता हैं, जिनका करियर डेवलपर इन्फ्रास्ट्रक्चर, कोड गुणवत्ता, स्वचालन, और AI‑सहायता सॉफ़्टवेयर विकास पर केंद्रित रहा है। Sonar में शामिल होने से पहले, उन्होंने Gitar की सह‑स्थापना की और CTO के रूप में कार्य किया, एक AI‑मूल प्लेटफ़ॉर्म बनाया जो कोड समीक्षा को स्वचालित करने, निरंतर एकीकरण (CI) विफलताओं का निदान करने, मूल कारणों की पहचान करने, और सुधार उत्पन्न करने के लिए डिज़ाइन किया गया था। Sonar ने मई 2026 में Gitar का अधिग्रहण किया, जिसमें Korlam और Gitar टीम कंपनी में शामिल होकर Sonar के व्यापक कोड सत्यापन प्लेटफ़ॉर्म के हिस्से के रूप में प्रौद्योगिकी का विकास जारी रखी। Gitar से पहले, Korlam ने Uber में लगभग एक दशक बिताया, जहाँ वे मोबाइल प्लेटफ़ॉर्म टीम के संस्थापक इंजीनियर से प्रधान इंजीनियर तक पहुँचे। अपने कार्यकाल के दौरान, उन्होंने Uber की केंद्रीकृत डेवलपर इन्फ्रास्ट्रक्चर का निर्माण और स्केलिंग में मदद की, प्रमुख मोनोरेपो और बिल्ड‑सिस्टम पहलों का नेतृत्व किया, रिमोट डेवलपर वातावरण और CI/CD टूलिंग विकसित की, और StarCoder, OctoCoder, और Code Llama जैसे ओपन‑सोर्स बड़े भाषा मॉडल के साथ प्रयोग किया ताकि Uber के कोडबेस में AI‑सहायता कोडिंग को बेहतर बनाया जा सके। उनका पूर्व अनुभव Lookout में इंजीनियरिंग भूमिकाओं और UC Santa Barbara में शोध कार्य, साथ ही Microsoft और Oracle के साथ इंटर्नशिप शामिल है।

Sonar एक सॉफ़्टवेयर कंपनी है जो कोड सत्यापन, स्वचालित कोड समीक्षा, कोड गुणवत्ता, और एप्लिकेशन सुरक्षा पर केंद्रित है। इसका प्रमुख उत्पाद SonarQube प्लेटफ़ॉर्म डेवलपर द्वारा लिखे और AI‑जनित कोड का विश्लेषण करता है ताकि बग, कमजोरियों, रखरखाव समस्याओं और अन्य गुणवत्ता मुद्दों की पहचान उत्पादन तक पहुँचने से पहले की जा सके, और यह क्लाउड, स्व‑प्रबंधित, तथा एकीकृत विकास पर्यावरण वर्कफ़्लो सहित कई विकल्प प्रदान करता है। Sonar के अनुसार, इसकी तकनीक 7 मिलियन से अधिक डेवलपर्स और 22 000 ग्राहकों द्वारा उपयोग की जाती है और यह प्रतिदिन 750 अरब से अधिक कोड पंक्तियों का विश्लेषण करती है। Gitar का अधिग्रहण इस दृष्टिकोण को AI‑मूल कोड समीक्षा और सुधार तक विस्तारित किया, जहाँ SonarQube के सत्यापन इंजन को ऐसे एजेंटिक टूल्स के साथ जोड़ा गया जो कोड की समीक्षा, CI विफलताओं की जाँच, और सुधार प्रस्ताव या लागू करने में सक्षम हैं, क्योंकि सॉफ़्टवेयर विकास अधिक AI‑प्रेरित हो रहा है।

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

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

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

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

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

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

AI सिस्टम व्यावसायिक लॉजिक, डेवलपर अभिप्राय और आर्किटेक्चरल ट्रेड‑ऑफ़ का मूल्यांकन कर सकते हैं, लेकिन उनके निष्कर्ष संभाव्यात्मक होते हैं। विकास टीमें इस संदर्भात्मक तर्क से कैसे लाभ उठा सकती हैं बिना AI समीक्षक के आउटपुट को स्वाभाविक रूप से सही मानें?

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

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

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

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

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

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

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

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

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

मुख्य बात यह है कि हरे (सफल) को स्वीकृति मानदंड मानने से इनकार करना, क्योंकि पासिंग बिल्ड केवल यह बताता है कि मौजूद परीक्षण विफल नहीं हुए।

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

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

प्रभावी AI कोड समीक्षा के लिये रिपॉज़िटरी की मान्यताएँ, निर्भरताएँ, आर्किटेक्चर और प्रस्तावित परिवर्तन का उद्देश्य समझना आवश्यक है। एक AI समीक्षक को उपयोगी निर्णय लेने के लिये कौन‑सा संदर्भ चाहिए, और जैसे-जैसे उनके सिस्टम विकसित होते हैं, संगठन वह संदर्भ सटीक कैसे रख सकते हैं?

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

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

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

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

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

परिणामों से शुरू करें, न कि AI सिस्टम द्वारा उत्पन्न टिप्पणियों की संख्या से। मैं मर्ज तक पुल‑रिक्वेस्ट के समय, CI विफलताओं के निदान में बिताए समय, पहले सत्यापन प्रयास पर सुधारों के पास होने की दर, और मुद्दों के बाद के चरणों या प्रोडक्शन में पहुंचने की आवृत्ति को मापूँगा।

फिर गुणवत्ता संकेतों जैसे फॉल्स‑पॉज़िट और अस्वीकृति दर, पुनः खोले गए मुद्दे, हाल ही में मर्ज किए गए परिवर्तनों से जुड़े रिग्रेशन, और यह कि डेवलपर्स को निष्कर्ष कार्रवाई योग्य लगते हैं, पर ध्यान दें। सही मीट्रिक मिश्रण टीम के अनुसार बदलता है, लेकिन प्रश्न समान रहता है: क्या हम पुनः‑काम और समीक्षा प्रतीक्षा समय को घटा रहे हैं बिना सुरक्षित, विश्वसनीय सॉफ़्टवेयर के मानक को कम किए?

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

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

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

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