मैंने एक auth module refactor करने के लिए पाँच-subagent orchestration चालू किया। इसमें मुझे $11 लगे, बारह मिनट लगे, और एक thread में करने से बदतर नतीजा मिला। Solo builders के लिए Subagents overrated हैं, और Twitter पर जो demos खूबसूरत agent swarms दिखाते हैं, वे आपको वह हिस्सा नहीं बताते जहाँ यह महंगा और अजीब हो जाता है।
गलत मत समझिए। Subagents एक real feature हैं जिनके real uses हैं। लेकिन default सलाह — "सब कुछ specialized agents में बाँट दो" — उस व्यक्ति के लिए गलत है जो अकेले एक product बना रहा हो। ज्यादातर समय आप एक flat, single-threaded agent चाहते हैं जो बस काम करे। मैं बताता हूँ क्यों।
एक subagent का असल खर्चा क्या है
जब आप एक subagent spawn करते हैं, तो आप सिर्फ एक task delegate नहीं कर रहे। आप एक ऐसा fresh context spin up कर रहे हैं जिसे आपके main thread के बारे में कुछ नहीं पता। तो आपको उसे brief करना होता है। हर subagent को relevant files, conventions, goal — सब शुरू से explain करना होता है। यह briefing tokens है। Subagent का काम tokens है। फिर वह report करता है, और उसकी report को main thread में synthesize करना और ज्यादा tokens हैं।
Clean boundaries वाले parallel task के लिए, यह overhead worth it है। ऐसे task के लिए जहाँ pieces आपस में उलझी हों — जो real coding का description है — आप बार-बार briefing tax देते हैं, और subagents एक-दूसरे पर कदम रखते रहते हैं क्योंकि किसी को भी पूरी तस्वीर नहीं दिखती।
Single-thread version के पास तो context पहले से ही है। उसने एक बार files पढ़ीं। तीन steps पहले उसने क्या किया वह याद है। कोई briefing नहीं, कोई synthesis नहीं, कोई coordination overhead नहीं। अक्सर यह सस्ता भी होता है और बेहतर भी।
Context fragmentation की समस्या
यह subtle वाला है। Agents coding में अच्छे होने की पूरी वजह है shared context — model problem, files, और अपने पिछले decisions को एक जगह रखता है और उन सब पर reason करता है। Subagents इसे तोड़ देते हैं। हर एक को एक slice दिखता है।
Subagent A अपने तरीके से error handling fix करता है। Subagent B, अलग से briefed, validation को अलग तरीके से fix करता है। किसी को नहीं पता दूसरे ने क्या किया। आप, main thread में, अब दो locally-reasonable changes को reconcile करने की कोशिश कर रहे हैं जो साथ fit नहीं होतीं। मैंने subagent output reconcile करने में उससे ज्यादा समय लगाया जितना subagents ने बचाया। यही trap है।
Solo builder के लिए, आपकी edge यह है कि आप पूरी तस्वीर अपने दिमाग में रखते हैं और agent उसे context में रखता है। इसे team की तरह दिखाने के लिए fragment करना उस org का cosplay है जो आपके पास है नहीं।
Subagents कब सच में फायदेमंद होते हैं
मैं कह नहीं रहा कभी नहीं। यहाँ वह जगह है जहाँ मैं actually इन्हें use करता हूँ:
- सच में parallel, independent काम। "Test suite चलाओ जबकि codebase को lint भी करो।" कोई shared state नहीं, कोई reconciliation नहीं। Clean fan-out।
- जानबूझकर context isolation। जब एक subtask मेरे main context में इतना कूड़ा डाल देगा कि मैं main thread को pollute नहीं करना चाहता — जैसे एक सवाल का जवाब देने के लिए 40 files पढ़ना। Subagent 40 पढ़ता है, एक जवाब देता है, मेरा main context clean रहता है। यह एक अच्छा use है।
- Bounded research। "जाओ पता लगाओ इस library का auth कैसे काम करता है और report करो।" Exploration गंदी होती है; मुझे सिर्फ conclusion चाहिए।
पैटर्न देखें: Subagents तब value देते हैं जब subtask independent और summarizable हो। जब value main thread से mess बाहर रखने में हो, team होने का नाटक करने में नहीं।
Orchestration fantasy
एक तरह का content है जो multi-agent dream बेचता है — एक planner agent, एक coder agent, एक reviewer agent, एक tester agent, सब एक छोटी company की तरह coordinate करते हुए। Diagram में अविश्वसनीय लगता है। Solo builder के लिए यह ज्यादातर $0.50 के task को $6 का बनाने का तरीका है।
Planner coder को task re-explain करता है। Coder काम produce करता है। Reviewer, अपने fresh context के साथ, उसे review करने के लिए सब कुछ दोबारा पढ़ता है। Tester फिर से पढ़ता है। हर handoff वही code दोबारा process करता है। आपने एक बड़ी team की inefficiency recreate की — सारा communication overhead — बिना किसी benefit के, क्योंकि अब भी सिर्फ आप और model हैं।
एक single capable agent एक thread में सब कुछ context में रखते हुए plan, code, और self-check करता है। आप अंत में diff पढ़ते हैं। यही आपका reviewer है। आप ही org chart हैं।
मेरा नियम
Default flat रखें। एक thread, एक agent, full context। Subagent तभी spawn करूँ जब मैं इसका जवाब हाँ में दे सकूँ: क्या यह subtask independent है, और क्या मुझे सिर्फ summary वापस चाहिए?
# Spawn करने से पहले मैं जो सवाल पूछता हूँ:
# - Main काम से independent? (reconcile करने के लिए कोई shared state नहीं)
# - Summarizable? (मुझे conclusion चाहिए, raw output नहीं)
# दोनों हाँ -> subagent। वरना -> flat रखें।
बाकी सब main thread में रहता है, जहाँ context पूरा है और बिल छोटा है।
Agent swarm future जैसा लगता है। एक product ship करने वाले एक इंसान के लिए, यह आमतौर पर एक costume है। उसे उतारें और एक thread में काम करें। आपका token budget आपका शुक्रिया अदा करेगा, और code भी।