कैसे एक डेवलपमेंट टीम में AI कोडिंग एजेंट्स को स्केल करें

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

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

इसके बाद विफलता का क्रम आता है। यह सर्वोत्तम प्रथाओं की एक सूची नहीं है, बल्कि यह उस क्रम का है जिसमें चीजें वास्तव में टूटती हैं, क्योंकि गलत क्रम में उन्हें ठीक करना एक चौथाई बर्बाद करता है।

सबसे पहले क्या टूटता है: साझा संदर्भ

हर डेवलपर जो एक एजेंट चला रहा है, चुपचाप उसे अपने कोडबेस का अपना संस्करण सिखा रहा है।

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

इसका समाधान उबाऊ है और यह इस पृष्ठ पर सबसे अधिक प्रभावी चीज है। परंपराओं को एक फ़ाइल में रखें, फ़ाइल को कमिट करें।

CLAUDE.md क्लॉड कोड के लिए, AGENTS.md कोडेक्स और अधिकांश अन्य CLI एजेंटों के लिए, और व्यावहारिक रूप से कई टीमें एक पोर्टेबल संदर्भ फ़ाइल रखती हैं बजाय इसके कि दो को बनाए रखें जो अलग हो जाएँ। तंत्र फ़ाइल नाम से अधिक महत्वपूर्ण है: निर्देश भंडार में रहते हैं, इसलिए वे git pull के साथ आते हैं बजाय इसके कि जो भी कमरे में था उसके माध्यम से आते हैं।

इसमें क्या होना चाहिए:

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

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

एक लाइन जोड़ने से पहले एक उपयोगी परीक्षण: यदि एक सहकर्मी इसे खींचता है, तो क्या यह उनकी मदद करता है या उन्हें तोड़ता है?

दूसरा क्या टूटता है: दो एजेंट, एक फ़ाइल

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

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

इसे ठीक करने के लिए दो तंत्र हैं, और आप दोनों चाहते हैं।

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

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

दूसरा आधा वह है जिसे टीमें छोड़ देती हैं, और यह वह है जो यह निर्धारित करता है कि मर्ज एक औपचारिकता है या एक दोपहर।

तीसरा क्या टूटता है: समीक्षा

टीम स्केल पर समीक्षा के बारे में सब कुछ एक संख्या से निकलता है: प्रति घंटे कितना डिफ़ आता है।

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

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

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

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

चौथा क्या टूटता है: लागत, और लागत के बारे में बातचीत

टोकन खर्च एक व्यक्तिगत विवरण बनना बंद कर देता है जिस क्षण यह एक टीम के चालान पर दिखाई देता है।

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

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

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

टीम की रस्मों में वास्तव में क्या बदलता है

हमारे अनुभव में और जो टीमें रिपोर्ट करती हैं, तीन चीजें।

स्टैंडअप स्थिति से अनब्लॉकिंग में बदलता है। कल प्रत्येक व्यक्ति ने क्या किया, यह शाखाओं में बड़े पैमाने पर दिखाई देता है। जो पाँच मिनट के लायक है वह है कौन से एजेंट फंसे हुए हैं, और किस पर।

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

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

वह सेटअप जो टिकता है

संक्षेप में, उस क्रम में जो मायने रखता है:

पहले चार का कोई खर्च नहीं है सिवाय सहमति के। अंतिम दो वह हैं जो एक टीम अंततः टर्मिनल से ऊपर कुछ चाहती है: न कि इसलिए कि टर्मिनल खराब हैं, बल्कि इसलिए कि एक टर्मिनल एक समय में एक एजेंट दिखाता है और आपको "कौन क्या चला रहा है, किस परियोजना पर, अभी" का उत्तर देने का कोई तरीका नहीं देता।

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

हालांकि संदर्भ फ़ाइल से शुरू करें। यह मुफ्त है, इसमें एक दोपहर लगती है, और यह इस तिमाही में आप जो भी उपकरण स्थापित कर सकते हैं उससे अधिक घर्षण को हटा देती है।