VM0 dev workflow: AI एजेंट को एक टीम की तरह प्रबंधित करना

VM0 की dev टीम में, हर डेवलपर एक ही समय में कई Claude Code इंस्टेंस के साथ काम करता है। आम तौर पर आठ से ज़्यादा।

हम Claude Code के साथ ठीक वैसा ही व्यवहार करते हैं जैसा हम किसी असली डेवलपर के साथ करते हैं। (हाँ, हमारी कंपनी को आधे-मज़ाक में AI Colleagues Co! कहा जाता है!)

इसी वजह से, VM0 dev workflow के पीछे का डिज़ाइन दर्शन सॉफ़्टवेयर इंजीनियरिंग में क्लासिक टीम प्रबंधन प्रथाओं को प्रतिबिंबित करता है।

हम काम को ट्रैक करने के लिए GitHub Issues, कोड समीक्षा और मर्जिंग के लिए Pull Requests, और ऑटोमेशन संभालने के लिए GitHub Actions का इस्तेमाल करते हैं। दो महीनों में, इस सेटअप ने हमें 404 रिलीज़ जारी करने और 230,000 से ज़्यादा लाइन कोड लिखने में मदद की।

यह पोस्ट बताती है कि हमने इसे कैसे काम लायक बनाया, और मुख्य समस्या कभी AI की क्षमता क्यों नहीं थी, बल्कि मानव समन्वय थी।

व्यवहार में AI-संचालित dev workflow

जब आप कई AI एजेंट को समानांतर रूप से समन्वित करते हैं, तो अड़चन यह नहीं है कि मॉडल कोड लिख सकता है या नहीं। असली अड़चन है मानव संज्ञानात्मक भार (cognitive load)।

यह वर्कफ़्लो 14 slash कमांड से बना है, जो तीन परतों में संगठित हैं: Deep Dive, Issue Management, और PR Management।

आइए पहले देखें कि मेरा वर्कफ़्लो कैसा दिखता है और एक फ़ीचर आम तौर पर कैसे बनता है।

1. आवश्यकता संरेखण (Requirement alignment)

   एक मानव एक Claude सत्र खोलता है और /deep-research से शुरुआत करता है। Claude कोडबेस, दस्तावेज़ीकरण, और प्रासंगिक संदर्भ से तथ्य इकट्ठा करता है। हम निष्कर्षों पर चर्चा करते हैं और इस पर संरेखित होते हैं कि हम असल में कौन-सी समस्या हल कर रहे हैं।

2. समाधान अन्वेषण (Solution exploration)

   /deep-innovate का इस्तेमाल करके, Claude कई संभावित दिशाएँ प्रस्तावित करता है, ट्रेड-ऑफ़ के साथ। हम चर्चा करते हैं, दायरा सीमित करते हैं, और एक दिशा चुनते हैं।

3. इश्यू निर्माण (Issue creation)

   हम /issue-create का इस्तेमाल करके एक GitHub इश्यू बनाते हैं। मानव यह सुनिश्चित करने के लिए इश्यू की समीक्षा करता है कि आवश्यकताएँ स्पष्ट रूप से दर्ज की गई हैं।

4. योजना और अनुमोदन (Planning and approval)

   Claude को काम जारी रखने देने के लिए /issue-plan का इस्तेमाल करें। Claude अपने-आप पूरा deep-dive वर्कफ़्लो चलाएगा और परिणाम इश्यू में पोस्ट करेगा, जिसमें शामिल हैं:

   1. /deep-research से निष्कर्ष
   2. /deep-innovate से तुलनाएँ
   3. /deep-plan से एक ठोस इम्प्लीमेंटेशन योजना

5. इम्प्लीमेंटेशन (Implementation)

   अनुमोदन के बाद, /issue-action Claude को योजना लागू करने, टेस्ट लिखने, एक PR खोलने, और CI के पास होने को सुनिश्चित करने देता है।

6. समीक्षा और मर्ज (Review and merge)

   हम एक संरचित समीक्षा के लिए /pr-review का इस्तेमाल करते हैं, फिर मर्ज करने से पहले अंतिम मानव समीक्षा करते हैं।

   मानव तीन चेकपॉइंट पर हस्तक्षेप करता है: आवश्यकताएँ, दिशा, और स्वीकृति। बाक़ी सब कुछ स्वायत्त रूप से चलता है।

मानसिकता में बदलाव: आप AI डेवलपरों की एक टीम का नेतृत्व कर रहे हैं

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

बाहरी टूल के बिना, मैं उतने सारे Claude इंस्टेंस एक साथ संभाल ही नहीं सकता था। तभी बात समझ में आई: यह कोई AI समस्या नहीं थी, यह एक प्रबंधन समस्या थी।

GitHub सॉफ़्टवेयर विकास में सहयोग के लिए पहले से ही स्वाभाविक टूल है, इसलिए कुछ नया आविष्कार करने के बजाय, मैंने Claude के साथ ठीक वैसा ही व्यवहार करना शुरू किया जैसा मैं किसी मानव साथी के साथ करता हूँ। एक बार जब मैंने ऐसा किया, तो मेरी प्रबंधन क्षमता अचानक स्केल हो गई।

प्रोजेक्ट और टीम प्रबंधन के दस वर्षों के अनुभव ने आख़िरकार इस नए संदर्भ में मायने पाए। Claude को एक टीम सदस्य और GitHub को हमारी साझा संचार और प्रबंधन जगह के रूप में मानकर, पूरा सिस्टम फिर से संभालने लायक हो गया।

एक अच्छा टीम लीडर जानता है कि कब शामिल होना है और कब पीछे हटना है:

Checkpoint	मैं क्या करता हूँ	AI क्या करता है
Requirements	समस्या पर संरेखित हों, दायरा स्पष्ट करें	कोडबेस पर रिसर्च, संदर्भ इकट्ठा करना
Direction	निष्कर्ष समीक्षा करें, दृष्टिकोण अनुमोदित करें	2-3 दृष्टिकोण प्रस्तावित करना, ट्रेड-ऑफ़ का मूल्यांकन
Acceptance	PR समीक्षा करें, गुणवत्ता सत्यापित करें	इम्प्लीमेंट करना, टेस्ट करना, CI ठीक करना

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

deep dive फ़्लो संरचित, धीमी सोच को लागू करता है

deep dive वर्कफ़्लो इम्प्लीमेंटेशन से पहले सोच-समझकर सोचना लागू करता है। कभी-कभी Claude किसी गतिरोध में फँस जाता है। जब ऐसा होता है, तो हम Claude को रुकने और सोचने के लिए मजबूर करते हैं, और फिर साथ मिलकर इसे सुलझाते हैं। इसके तीन चरण हैं:

Phase	Command	उद्देश्य	Output
Research	/deep-research	तथ्य इकट्ठा करना, संदर्भ समझना	research.md
Innovate	/deep-innovation	कई दृष्टिकोण तलाशना	innovate.md
Plan	/deep-plan	ठोस चरण परिभाषित करना	plan.md

हर चरण की सख़्त सीमाएँ हैं।

• Research: कोई सुझाव नहीं
• Innovate: कोई ब्योरा नहीं
• Plan: कोई इम्प्लीमेंटेशन नहीं

ये बाधाएँ Claude को सीधे कोड पर कूदने के बजाय धीमे, सोच-समझकर तर्क करने के लिए मजबूर करती हैं। इनके बिना, एज केस और आर्किटेक्चरल चिंताएँ अक्सर छूट जाती हैं!

उपयोग उदाहरण

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

सरल कार्यों के लिए, आप deep dive छोड़ सकते हैं और सीधे /issue-create पर जा सकते हैं।

तकनीकी अनिश्चितता वाले जटिल कार्यों के लिए, deep dive चरण यह सुनिश्चित करने में मदद करते हैं कि इम्प्लीमेंटेशन शुरू होने से पहले आप और Claude संरेखित हैं।

GitHub को साझा स्मृति के रूप में इस्तेमाल करें

ज़्यादातर AI टूल संदर्भ को अस्थायी मानते हैं। जब सत्र ख़त्म होता है, तो स्मृति ग़ायब हो जाती है।

VM0 GitHub को स्थायी स्मृति के रूप में इस्तेमाल करता है:

GitHub feature	यह क्या संग्रहीत करता है
Issue body	आवश्यकताएँ और निर्णय
Issue comments	रिसर्च, विकल्प, योजनाएँ
PR comments	समीक्षाएँ और सारांश
Labels	वर्कफ़्लो स्थिति

यह एक मानव समस्या को भी हल करता है: संदर्भ पुनर्प्राप्ति (context recovery)।

जब मैं 8+ Claude इंस्टेंस का प्रबंधन कर रहा होता हूँ, तो मुझे सूचनाएँ मिलती हैं कि काम पूरा हो गया। पर मैं Claude की बातचीत से यह पुनर्निर्मित नहीं कर सकता कि वह क्या कर रहा था, कौन-से निर्णय लिए गए, या मौजूदा स्थिति क्या है।

GitHub इश्यू इसे हल करते हैं। हर इश्यू दिखाता है:

• मूल आवश्यकताएँ
• रिसर्च निष्कर्ष (क्या खोजा गया)
• इनोवेशन चरण (कौन-से विकल्पों पर विचार किया गया)
• अनुमोदित योजना (क्या इम्प्लीमेंट किया जाएगा)

यह संरचित प्रारूप समीक्षा को कुशल बनाता है। तो मैं चरणों को जल्दी से स्कैन कर सकता हूँ, दृष्टिकोण को समझ सकता हूँ, और बदलाव अनुमोदित या अनुरोध कर सकता हूँ, यह सब मूल बातचीत को याद किए बिना।

जब काम ख़त्म होता है, तो मुझे यह याद रखने की ज़रूरत नहीं कि किसी चैट विंडो में क्या हुआ। मैं इश्यू खोल सकता हूँ और पूरी कहानी देख सकता हूँ, संरचित और लिखी हुई।

एजेंट के बीच हैंडऑफ़

चूँकि सारा संदर्भ GitHub में रहता है, काम एजेंट के बीच सहजता से आगे बढ़ सकता है:

• एक एजेंट एक इश्यू या PR बनाता है
• दूसरा बाद में /deep-research issue 123 या /issue-plan 123 या /deep-research PR 124 का इस्तेमाल करके जारी रखता है

लंबी चर्चाओं के लिए, /issue-compact सब कुछ एक साफ़ इश्यू बॉडी में समेकित कर देता है। इससे हैंडऑफ़ मनुष्यों और AI दोनों के लिए आसान हो जाता है।

आइए वर्कफ़्लो पैटर्न का सारांश करें

इन सबके बाद, मैं कुछ व्यावहारिक सुझावों का सारांश दूँ।

सरल कार्य

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

इसका इस्तेमाल तब करें जब आवश्यकताएँ स्पष्ट हों और काम सीधा-सादा हो।

जटिल कार्य

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

यह ग़लत दृष्टिकोण पर बर्बाद होने वाले प्रयास को रोकता है।

समानांतर काम

मानव द्वारा पूरे किए गए चेकपॉइंट की समीक्षा करते समय कई एजेंट एक साथ काम कर सकते हैं। यहीं वर्कफ़्लो सबसे अच्छी तरह स्केल करता है।

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

कमांड संदर्भ

Deep dive कमांड

Command	उद्देश्य
/deep-research	जानकारी इकट्ठा करना, कोडबेस समझना। कोई सुझाव नहीं।
/deep-innovate	2-3 दृष्टिकोण तलाशना, ट्रेड-ऑफ़ का मूल्यांकन। कोई कोड नहीं।
/deep-plan	ठोस इम्प्लीमेंटेशन चरण बनाना। कोई इम्प्लीमेंटेशन नहीं।

Issue कमांड

Command	उद्देश्य
/issue-create	बातचीत संदर्भ से इश्यू बनाना
/issue-bug	पुनरुत्पादन चरणों के साथ बग रिपोर्ट बनाना
/issue-feature	आवश्यकताओं पर केंद्रित फ़ीचर अनुरोध बनाना
/issue-plan	पूरा deep-dive वर्कफ़्लो चलाना, परिणाम इश्यू में पोस्ट करना
/issue-action	मानव अनुमोदन के बाद इम्प्लीमेंटेशन जारी रखना
/issue-compact	हैंडऑफ़ के लिए इश्यू बॉडी + टिप्पणियों को समेकित करना

PR कमांड

Command	उद्देश्य
/pr-check	CI पाइपलाइन मॉनिटर करना, ऑटो-फ़िक्स, 3x तक पुनः प्रयास
/pr-review	प्रोजेक्ट मानकों के विरुद्ध PR की कमिट-दर-कमिट समीक्षा
/pr-comment	बातचीत की चर्चा को PR टिप्पणी में सारांशित करना

शुरुआत कैसे करें

1. सरल शुरुआत करें: अपने पहले कार्य के लिए /issue-create → /issue-plan → /issue-action का इस्तेमाल करें
2. जटिल कार्यों के लिए deep dive जोड़ें: जब आवश्यकताएँ अस्पष्ट या तकनीकी रूप से जटिल हों, तो /deep-research से शुरू करें
3. धीरे-धीरे स्केल करें: जैसे-जैसे आप समीक्षा की लय में सहज होते जाएँ, और Claude इंस्टेंस जोड़ें
4. प्रक्रिया पर भरोसा करें: चेकपॉइंट के बीच Claude को स्वायत्त रूप से काम करने दें

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

स्केलिंग संबंधी विचार: जब आपके पास ज़्यादा एजेंट हों तो क्या करें

वर्कफ़्लो को 10+ समवर्ती Claude इंस्टेंस के साथ परखा गया है। हमारी सिफ़ारिश:

• 10 एजेंट तक: हर एक के साथ गहरे सहयोग के लिए सहज
• 10 से ऊपर: अनुशंसित नहीं

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

क्लासिक "two pizza team" सिद्धांत यहाँ लागू होता है। वही बाधाएँ जो मानव टीम के आकार को सीमित करती हैं, यह भी सीमित करती हैं कि एक व्यक्ति कितने AI एजेंट को प्रभावी ढंग से प्रबंधित कर सकता है।

मैं फ़िलहाल 10 एजेंट से आगे स्केल करने के लिए एक 8×8 दो-स्तरीय टीम संरचना की खोज कर रहा हूँ, पर अभी तक प्रभावी प्रथाएँ विकसित नहीं की हैं। जब ठोस परिणाम होंगे तब मैं और साझा करूँगा…

VM0 dev workflow यह बदल देता है कि जब AI टीम का हिस्सा बन जाता है तो हम सॉफ़्टवेयर विकास के बारे में कैसे सोचते हैं।

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

इसी तरह हमने 2 महीनों में 404 रिलीज़ जारी कीं। और इसी तरह आप AI के साथ अपने ख़ुद के विकास को स्केल कर सकते हैं।