DoorDash के एजेंट ने 50 में 45 पुराने फ़्लैग हटाए—हर काम पर $4.79

DoorDash की बहु-एजेंट प्रणाली ने 50 पुराने फ़ीचर फ़्लैग की सफ़ाई में 45 उपयोगी, विलय-योग्य पुल अनुरोध बनाए। DoorDash के मूल तकनीकी विवरण में औसत समय 13.8 मिनट और औसत API लागत $4.79 प्रति सफ़ाई बताई गई है; कंपनी के अनुसार यही काम हाथ से करने में एक से दो घंटे लगते थे।

यह 90% नतीजा उत्पादन में बिना समीक्षा किए गए 45 बदलावों का दावा नहीं है। शीर्षक में “हटाए” प्रकाशित बेंचमार्क में बने 45 उपयोगी पुल अनुरोधों का संक्षिप्त रूप है: लक्ष्य मान की इंजीनियर द्वारा पुष्टि, जीवंत प्रयोग डेटा, अलग Git कार्य-वृक्ष और नियतात्मक जाँच पार करने के बाद भी अंतिम विलय मनुष्य की स्वीकृति पर निर्भर था।

बेंचमार्क ने क्या मापा

मूल्यांकन DoorDash की प्रणाली द्वारा कई Kotlin भंडारों में संसाधित 50 सबसे हालिया पुराने फ़्लैग पर हुआ। इनमें छह सरल, 18 मध्यम और 26 जटिल मामले थे; प्रकार के आधार पर 41 बूलियन, छह स्ट्रिंग और तीन पूर्णांक या दीर्घ-पूर्णांक फ़्लैग थे। उपयोगी परिणाम के लिए CI का सफल होना, कोड की शुद्धता और विकासकर्ता समीक्षा आवश्यक थीं।

• उपयोगी पुल अनुरोध: 45/50, यानी 90%।
• औसत समय और लागत: 13.8 मिनट तथा $4.79 प्रति सफ़ाई। सरल मामलों में औसत 7.5 मिनट और $2.69 था; जटिल मामलों में 17.7 मिनट और $6.20।
• पहली कोशिश: 31 सफ़ाइयाँ पहली बार में विलय हुईं। अन्य 14 उपयोगी परिणाम एक मामूली संशोधन के बाद पूरे हुए।
• विफलता-सीमा: पांच मामलों में इंजीनियर को हस्तक्षेप करना पड़ा; सभी जटिल, कई फ़ाइलों वाली गहरी कॉल-श्रृंखलाओं से जुड़े थे।

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

नतीजा अकेले मॉडल का नहीं था

InfoQ के स्वतंत्र तकनीकी सारांश के अनुसार यह व्यवस्था 60,000 से अधिक फ़्लैग और लगभग 623 भंडार वाले परिवेश के लिए बनाई गई, जहाँ करीब 2,300 नए फ़्लैग हर महीने जुड़ते थे। निर्भरता-प्रविष्ट आवरणों के कारण एक साधारण बूलियन फ़्लैग भी स्थिरांक, व्यावसायिक तर्क और परीक्षणों सहित पांच से 20 फ़ाइलों में फैला हो सकता था।

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

दूसरे चरण में Claude Opus आधारित हटाने वाले एजेंट अलग Git कार्य-वृक्षों में बदलाव करते थे। एक भंडार में अधिकतम चार एजेंट समानांतर चल सकते थे, प्रत्येक पर एक घंटे की सीमा थी और साझा Gradle स्थिति से बचने के लिए डेमन बंद रखा गया था। विफल प्रयास को मुख्य कार्य-वृक्ष बदले बिना हटाया जा सकता था।

पुल अनुरोध से पहले अनिवार्य सुरक्षा द्वार

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

1. निर्माण और संबंधित परीक्षण सफल हों।
2. बदली गई पंक्तियों पर JaCoCo पैच कवरेज कम-से-कम 95% हो।
3. Detekt स्थिर विश्लेषण सफल हो।
4. सभी जाँच पार होने के बाद ही पुल अनुरोध खुले।
5. अंतिम विलय विकासकर्ता की समीक्षा और स्वीकृति के बाद हो।

भारतीय विकास दल के लिए $4.79 तभी सार्थक संदर्भ है जब यही नियंत्रण परत उपलब्ध हो। जीवंत फ़्लैग स्थिति का भरोसेमंद अभिलेख, अलग कार्य-वृक्ष, पैच-कवरेज जाँच या नियतात्मक स्थिर विश्लेषण न होने पर मूल बेंचमार्क की लागत और सफलता दर स्थानीय जोखिम को नहीं दर्शाती।

नियम-आधारित औजार या अर्थ-आधारित एजेंट

PolyglotPiranha का आधिकारिक भंडार इसे पुराने फ़ीचर फ़्लैग से जुड़े कोड के स्वचालित पुनर्गठन का औजार बताता है। इसे फ़्लैग का नाम, अपेक्षित व्यवहार और संबंधित API के नियम दिए जाते हैं; फिर यह उन नियमों के अनुसार संरचनात्मक बदलाव करता है।

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

स्थानीय लागत में क्या जोड़ना होगा

$4.79 केवल औसत API खर्च है। इसमें प्रणाली का निर्माण, प्रयोग मंच और Jira का एकीकरण, CI संगणना, इंजीनियर की समीक्षा और विफल मामलों की मरम्मत शामिल नहीं है। उसी औसत से 100 सफ़ाइयों की API लागत लगभग $479 बनती है, लेकिन यह केवल अंकगणितीय परिदृश्य है—स्थानीय बजट नहीं।

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

निष्कर्ष की सही सीमा

DoorDash का बेंचमार्क दिखाता है कि जीवंत प्रयोग डेटा, लक्ष्य मान की मानवीय पुष्टि, अलग कार्य-वृक्ष और कठोर सत्यापन के भीतर बहु-एजेंट व्यवस्था पुराने फ़्लैग की अर्थ-आधारित सफ़ाई को औसतन 13.8 मिनट और $4.79 की API लागत में विलय-योग्य पुल अनुरोध तक पहुँचा सकती है। यह दावा नहीं करता कि वही परिणाम किसी भी कोडबेस में केवल एजेंट जोड़ देने से दोहराया जा सकता है।

निर्णय-सीमा स्पष्ट है: प्रत्यक्ष और दोहराए जा सकने वाले ढाँचों के लिए नियम-आधारित औजार पहले विकल्प हैं; गहरी अर्थगत निर्भरताओं में एजेंट अतिरिक्त पहुँच दे सकते हैं। दोनों ही स्थितियों में जीवंत लक्ष्य मान, नियतात्मक जाँच और मानवीय स्वीकृति बेंचमार्क से अलग की जा सकने वाली वैकल्पिक सुविधाएँ नहीं हैं।