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

Bugbot बनाने की प्रक्रिया गुणात्मक मूल्यांकनों से शुरू हुई और धीरे-धीरे एक अधिक व्यवस्थित तरीके में विकसित हुई, जहाँ हमने गुणवत्ता को लगातार बेहतर करने के लिए एक कस्टम AI-संचालित मेट्रिक का इस्तेमाल किया।

लॉन्च के बाद से, हमने 40 बड़े प्रयोग चलाए हैं, जिनसे Bugbot की समाधान दर 52% से बढ़कर 70% से अधिक हो गई है। साथ ही, प्रति रन फ़्लैग किए गए बग्स की औसत संख्या 0.4 से बढ़कर 0.7 हो गई है। इसका मतलब है कि प्रति PR सुलझाए गए बग्स की संख्या दोगुने से भी अधिक हो गई है—लगभग 0.2 से बढ़कर करीब 0.5 तक।

#विनम्र शुरुआत

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

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

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

कई हफ्तों के आंतरिक गुणात्मक पुनरावृत्तियों के बाद, हम Bugbot के ऐसे संस्करण तक पहुँचे जो बाज़ार में मौजूद दूसरे कोड समीक्षा टूल्स से बेहतर प्रदर्शन करता था और जिसने हमें इसे लॉन्च करने का भरोसा दिया। इसमें यह फ़्लो इस्तेमाल होता था:

1. डिफ के यादृच्छिक क्रम के साथ आठ समानांतर पास चलाएँ
2. समान बग्स को एक बकेट में संयोजित करें
3. केवल एक पास में मिले बग्स को हटाने के लिए बहुमत-मतदान का उपयोग करें
4. हर बकेट को मर्ज करके एक स्पष्ट विवरण बनाएँ
5. अवांछित श्रेणियों को फ़िल्टर करें (जैसे compiler warnings या दस्तावेज़ीकरण त्रुटियाँ)
6. false positives पकड़ने के लिए परिणामों को एक validator मॉडल से गुजारें
7. पिछले रन से पोस्ट किए गए बग्स के साथ डुप्लिकेट प्रविष्टियाँ हटाएँ

#प्रोटोटाइप से उत्पादन तक

Bugbot को व्यवहार में उपयोगी बनाने के लिए, हमें मुख्य समीक्षा लॉजिक के साथ-साथ कुछ बुनियादी सिस्टमों में भी निवेश करना पड़ा। इसमें हमारी Git इंटीग्रेशन को Rust में फिर से बनाकर और फ़ेच किए जाने वाले डेटा को न्यूनतम रखकर रिपॉज़िटरी तक पहुँच को तेज़ और विश्वसनीय बनाना शामिल था। साथ ही, GitHub की सीमाओं के भीतर काम करने के लिए हमने rate-limit निगरानी, अनुरोध batching, और proxy-आधारित अवसंरचना भी जोड़ी।

जैसे-जैसे अपनाना बढ़ा, टीमों को कोडबेस-विशिष्ट invariants को व्यक्त करने का तरीका भी चाहिए था, जैसे unsafe माइग्रेशन या internal APIs का गलत उपयोग। इसके जवाब में, हमने उन जाँचों का समर्थन करने के लिए Bugbot नियम जोड़े, बिना उन्हें सिस्टम में hardcode किए।

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

#जो मायने रखता है उसे मापना

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

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

#हिल-क्लाइम्बिंग

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

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

#एजेंटिक वास्तुकला

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

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

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

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

#आगे क्या आने वाला है

आज, Bugbot हर महीने Rippling, Discord, Samsara, Airtable, और Sierra AI जैसे ग्राहकों के लिए बीस लाख से ज़्यादा PR समीक्षाएँ करता है। हम Cursor में अपने सभी आंतरिक कोड पर भी Bugbot चलाते हैं।

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

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

अब तक हमने काफ़ी बड़ी प्रगति की है, जो Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman, और Josh Ma जैसे कुछ अहम साथियों के योगदान के बिना संभव नहीं होती। साथ मिलकर, हमारा लक्ष्य अब भी यही है कि जैसे-जैसे आपके AI विकास वर्कफ़्लो स्केल हों, हम आपकी टीमों को कोड गुणवत्ता बनाए रखने में मदद करें।

दस्तावेज़ पढ़ें या आज ही Bugbot आज़माएँ।