Claude Code Subagents: समानांतर Agents में काम विभाजित करना

पिछले साल नवंबर के अंत में मैं एक도매 ग्राहक के लिए WooCommerce निर्माण में तीन हफ्ते में था। तीस के करीब कस्टम post types, एक विशेष pricing engine, और एक checkout flow जिसमें मुझे याद है उससे अधिक conditional logic था। मैं इसका एकमात्र developer था। और मैं plugin layer, theme overrides, और REST API endpoints के बीच context-switching में दिन खो रहा था।

तब मैंने Claude Code subagents को समानांतर में चलाने के लिए सही तरह से प्रतिबद्ध किया। सिर्फ प्रयोग नहीं। असल में मैंने अपने काम को विभाजित करने का तरीका बदल दिया ताकि कई agents एक दूसरे को रोके बिना एक साथ आगे बढ़ सकें।

यहाँ वह है जो मैंने सीखा, साथ ही वह जगहें जहाँ मैंने पहले गलती की।

---

Claude Code में "Subagents" का असल मतलब क्या है

लोग इस शब्द को ढीले ढाले तरीके से इस्तेमाल करते हैं। Claude के agentic framework में, एक subagent सिर्फ एक Claude instance है जो एक orchestrator से scoped task लेता है, इसे execute करता है, और output देता है। orchestrator (जो खुद एक Claude session हो सकता है) यह तय करता है कि काम को कैसे विभाजित करें, कौन से subagents को शुरू करें, और परिणामों को कैसे जोड़ें।

व्यवहार में, हम में से अधिकांश जो sites और applications बनाते हैं, इसका मतलब है कि एक ही codebase के विरुद्ध प्रत्येक focused Claude Code context के साथ कई terminal sessions चलाना। कभी-कभी orchestration एक script के माध्यम से automated है। अक्सर, सच कहूँ तो, यह सिर्फ मैं हूँ जो Notion में एक planning doc से manually प्रत्येक agent क्या काम कर रहा है इसे coordinate करता हूँ।

Sequential और parallel के बीच अंतर

Sequential agentic work वह है जिसमें अधिकांश developers जाते हैं: Claude को task A करने के लिए कहें, प्रतीक्षा करें, फिर B करने के लिए कहें। सरल चीजों के लिए ठीक है। लेकिन अगर A और B एक दूसरे के output पर निर्भर नहीं करते हैं, तो आप समय बर्बाद कर रहे हैं।

Parallel subagents independent workstreams पर एक साथ चलते हैं। WooCommerce project जिसका मैंने उल्लेख किया: मेरे पास एक agent pricing engine logic को refactor कर रहा था जबकि एक अन्य REST API controllers में PHPDoc comments generate कर रहा था। कोई overlap नहीं। दोनों लगभग उसी समय में पूरे हुए जितना समय में एक को करने में लगता।

---

मैं वास्तव में काम का विभाजन कैसे करता हूँ

यह वह हिस्सा है जिस पर कोई भी स्पष्ट रूप से बात नहीं करता। Agent setup आसान हिस्सा है। कठिन हिस्सा यह पता लगाना है कि क्या विभाजित करें।

मैं एक सरल rule का उपयोग करता हूँ जो मैंने 2022 में एक दर्दनाक merge conflict incident के बाद आया: कोई भी दो agents एक ही session में एक ही file को touch नहीं कर सकते। पूरी तरह। अगर मैं इसकी गारंटी नहीं दे सकता, तो tasks समानांतर में नहीं चलते।

किसी भी parallel run से पहले मेरा planning step

इससे पहले कि मैं कुछ भी शुरू करूँ, मैं एक short task manifest लिखता हूँ। कुछ खास नहीं, बस एक plain text file या एक Notion page जिसमें है:

Task name और एक-वाक्य विवरण
Scope में Files (explicit list)
Scope से बाहर Files (कोई भी सन्निहित चीज जो एक agent को घूमने के लिए लुभा सकती है)
Expected output format
किसी भी संदर्भ को शामिल करें जो कोडबेस में नहीं है

यह मुझे शायद 15 मिनट लगता है। इसने मुझे सच में शर्मनाक संख्या में conflicts से बचाया है।

---

तीन Workstream Types जिन्हें मैं सबसे अधिक Split करता हूँ

Seahawk पर 12,000+ site builds के साथ, और अपने अलग से client work के साथ, मैंने देखा है कि parallelisation के लिए अच्छे candidates के रूप में बार-बार एक ही categories आती हैं।

1. Documentation और code generation

एक agent code लिखता या refactor करता है। दूसरा एक अलग module के लिए documentation, tests, या comments लिखता है। ये लगभग कभी conflict नहीं करते और दोनों मैनुअली करने में सच में उबाऊ होते हैं। WooCommerce wholesale project पर, मेरे पास एक subagent pricing functions के लिए PHPUnit test stubs generate कर रहा था जबकि दूसरा custom admin columns बना रहा था। Test stubs को करीब चार मिनट लगे। Admin columns को बारह लगे। मैंने उन चार मिनटों में से कोई नहीं खोया।

2. Frontend और backend isolation

अगर आपका frontend और backend clearly separated directories में रहते हैं (जो उन्हें करना चाहिए, लेकिन वह एक अलग post है), तो यह एक प्राकृतिक split है। मैंने एक subagent को /resources/js में React components बनाते हुए चलाया है जबकि दूसरा /app/Http में Laravel controllers को wire कर रहा था। एकमात्र coordination point दोनों agents शुरू होने से पहले API contract पर सहमत होना था। मैंने वह project के root में एक AGENTS.md file में लिखा। दोनों agents ने इसे reference किया।

3. Module-by-module refactoring

Big refactors तब मिसरेबल होते हैं जब sequentially किए जाते हैं। अगर आपके पास, कहो, आठ feature modules हैं जिनमें से प्रत्येक को एक ही प्रकार का change चाहिए (एक deprecated method को update करना, एक नए helper को migrate करना, जो कुछ भी), उन्हें agents में split करो। मैंने एक बार चार simultaneous agents चलाए थे जो एक legacy plugin को WP_Query loops से एक repository pattern में migrate कर रहे थे। प्रत्येक agent को दो modules मिले। एक घंटे से भी कम में पूरा। Sequentially वह आधा दिन होने वाला था।

---

Tooling Setup: मैं वास्तव में क्या इस्तेमाल करता हूँ

मैं यह नहीं कहने वाला कि मेरे पास कोई elaborate infrastructure है। मेरी actual setup है:

Claude Code एक MacBook Pro M3 पर multiple tmux panes में चल रहा है
project root में एक shared AGENTS.md file जो conventions, file ownership, और workstreams के बीच API contract को define करती है
प्रत्येक agent के लिए Git branches। हमेशा। भले ही branch सिर्फ बीस मिनटों के लिए रहता हो
किसी भी merge से पहले एक quick git diff --stat surprises को catch करने के लिए

AGENTS.md file शायद सबसे useful चीज़ है जो मैंने पिछले साल अपने workflow में जोड़ी है। यह एक plain markdown file है जो किसी भी agent (या मानव, फिर भी) को बताती है कि project conventions क्या हैं, कौन सी files किस workstream को belong करती हैं, और क्या से बचना है। इसे एक CONTRIBUTING.md जैसा समझें लेकिन AI context windows के लिए लिखा गया है।

Context window management पर

यह वह जगह है जहाँ लोग lazy हो जाते हैं और फिर confused। प्रत्येक subagent के पास अपना context है। इसका मतलब यह है कि अगर Agent B को यह जानना है कि Agent A ने क्या decide किया, तो आपको इसे explicitly बताना होगा। यह बस ही जान नहीं पाएगा।

मैं इसे handle करता हूँ एक SESSION_LOG.md रखकर जिसे मैं manually update करता हूँ प्रत्येक agent के एक chunk complete करने के बाद। यह max तीन से पाँच bullet points हैं: क्या किया गया, क्या बदला, अगले agent को क्या जानना चाहिए। Overhead कम है। Alternative एक agent को assumptions बनाने देना है जो आपके code को break करे, और वह overhead बहुत ज्यादा है।

---

यह कहाँ गलत जाता है (दर्दनाक अनुभव से)

Seahawk के पास पिछली spring में एक fintech dashboard project था जहाँ हमने एक monorepo में subagents चलाने की कोशिश की बिना proper file ownership के। दो agents दोनों ने shared utils/formatters.ts file को update करने का decide किया। किसी को दूसरे के बारे में पता नहीं था। नतीजा merge technically fine था, लेकिन हमने intent को reconcile करने में 40 मिनट बिताए। पूरी तरह से avoidable था।

मैं repeatedly जो failure modes देखता हूँ:

Shared utility files। ये एक trap हैं। इन्हें lock करो। अगर एक subagent को एक shared utility update करने की ज़रूरत है, तो वह task अकेले चलना चाहिए, parallel में नहीं।
अस्पष्ट कार्य विवरण। एक एजेंट को "auth मॉड्यूल को साफ करो" दिया गया तो वह अपने संदर्भ के आधार पर बिल्कुल अलग तरीके से व्याख्या करेगा। विशिष्ट बनो। "AuthController.php को रीफैक्टर करो ताकि app/Repositories/UserRepository.php में पहले से परिभाषित UserRepository इंटरफ़ेस का उपयोग हो। इंटरफ़ेस को स्वयं संशोधित न करो।" यह एक सुरक्षित प्रॉम्प्ट है।
कोई शाखा अलगाव नहीं। सभी एजेंटों को मुख्य पर चलाना यही है कि आप रोमांचक शुक्रवार की दोपहर कैसे बनाते हैं। शाखाओं की कोई कीमत नहीं।
मैनिफेस्ट को छोड़ देना। मुझे पता है, मुझे पता है। यह ओवरहेड जैसा लगता है। वैसे भी करो। हर बार जब मैंने इसे छोड़ा है मुझे एक घंटे में पछतावा हुआ है।

---

एक वास्तविक समानांतर रन, चरण दर चरण

पिछले मंगलवार का सत्र एक Shopify-से-WooCommerce माइग्रेशन प्रोजेक्ट के लिए कुछ इस तरह लगता था (गुमनाम, लेकिन संरचना बिल्कुल यही है)।

मैंने Notion में कार्य मैनिफेस्ट लिखा। चार कार्य समानांतरकरण योग्य के रूप में चिह्नित।
चार git शाखाएं बनाईं: agent/product-import, agent/tax-logic, agent/rest-endpoints, agent/admin-ui।
चार tmux पैन खोले, प्रत्येक में एक Claude Code सत्र।
प्रत्येक सत्र की शुरुआत में AGENTS.md का संबंधित खंड संदर्भ के रूप में चिपकाया।
प्रत्येक एजेंट को उसका कार्य प्रॉम्प्ट दिया, विशिष्ट फ़ाइलों का संदर्भ दिया।
सभी चारों को एक साथ चलाया। कॉफ़ी बनाई। वास्तव में इसे पिया जब यह अभी गर्म था, जो एक चमत्कार जैसा लगा।
प्रत्येक शाखा के आउटपुट की समीक्षा की। PHP पर phpcs चलाया, कोई भी JS को छुआ तो eslint चलाया।
क्रम में मर्ज किया: पहले प्रोडक्ट आयात (दूसरों पर इसके स्कीमा पर हल्की निर्भरताएं थीं), फिर टैक्स लॉजिक, फिर REST एंडपॉइंट, फिर एडमिन UI।
SESSION_LOG.md को जो बदला गया उससे अपडेट किया।

सभी चार कार्यों के लिए कुल समय: लगभग 35 मिनट। क्रमिक समापन के लिए मेरा अनुमान 90 मिनट से 2 घंटे था। मैं इसे ले लूंगा।

---

यह क्या करता है (और नहीं करता)

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

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

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

दूसरी चीज जो यह नहीं बदलती: क्लाइंट के साथ संचार। एक एजेंट एक सुविधा बना सकता है। यह क्लाइंट को नहीं बता सकता कि समय सीमा क्यों स्थानांतरित हुई या स्कोप क्रीप के बारे में अपेक्षाओं का प्रबंधन करो। वह हिस्सा अभी भी आपका है।

---

FAQ

क्या मुझे Claude Code सबएजेंट चलाने के लिए विशेष API पहुंच या टूलिंग की आवश्यकता है?

कोई विदेशी सेटअप की आवश्यकता नहीं। Claude Code Anthropic का टर्मिनल-आधारित कोडिंग टूल है, और आप अलग-अलग टर्मिनल सत्रों में कई इंस्टेंस चला सकते हैं (मैं tmux का उपयोग करता हूं)। यदि आप API को सीधे हिट कर रहे हैं तो आपको पर्याप्त दर सीमा के साथ Claude API कुंजी की आवश्यकता है। भारी समानांतर कार्यभार के लिए, शुरू करने से पहले अपनी दर सीमा टायर जांचें ताकि आप सत्र के बीच में थ्रॉटलिंग से न फंसें।

मैं एजेंटों को साझी फ़ाइलों पर संघर्ष करने से कैसे रोकूं?

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

क्या यह केवल बड़े प्रोजेक्ट पर ही उपयोगी है?

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

अगर कोई एजेंट खराब आउटपुट दे, तो क्या होता है?

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

क्या मैं ऑर्केस्ट्रेशन को मैनुअली करने की जगह ऑटोमेट कर सकता हूँ?

हाँ, और बार-बार आने वाले वर्कफ़्लो के लिए यह काबिल-ए-ग़ौर है। मैंने सरल Bash स्क्रिप्ट लिखी हैं जो पहले से तय प्रॉम्प्ट और कॉन्टेक्स्ट के साथ क्रमवार Claude Code कॉल शुरू करती हैं। पूरी तरह ऑटोमेटेड समानांतर ऑर्केस्ट्रेशन के लिए, आपको एक ऑर्केस्ट्रेटर लेयर बनानी होगी जो प्रोग्रामेटिक तरीके से एजेंट शुरू करे, आउटपुट इकट्ठा करे, और निर्भरताओं को संभाले। यह एक बड़ी इंजीनियरिंग का निवेश है। अधिकतर फ्रीलांसर और छोटी एजेंसियों के लिए, tmux और एक टास्क मैनिफ़ेस्ट के साथ मैनुअल कोऑर्डिनेशन काफ़ी है।

---

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

लेकिन ये उबाऊ एक्सीक्यूशन वाले हिस्से? मैं जितना भी समय वापस ले सकूँ, लूँगा।