40 सब-एजेंट्स के साथ एक बड़े प्रोजेक्ट को व्यवस्थित करने के लिए Fable का उपयोग कैसे करें

पिछले सप्ताह @HelloUntangle पर हमने अपने इतिहास का सबसे बड़ा और जोखिम भरा इंजीनियरिंग प्रोग्राम पूरा किया।

• 834 फ़ाइलें
• प्रोडक्शन डेटा म्यूटेशन
• DB स्कीमा अपडेट
• 31 PRs
• शुक्रवार से शुरू → सोमवार तक पूरा
• शून्य प्रोडक्शन इंसिडेंट

सब कुछ एक ही Fable पैरेंट ऑर्केस्ट्रेटर सेशन के साथ।

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

इसे कारगर बनाने वाली चीज़ प्रोग्राम-मैनेजमेंट पैटर्न का एक सेट था जो किसी भी बड़े माइग्रेशन को बेहतर बना सकता है।

यहाँ बताया गया है कि हमने यह कैसे किया ...

आर्किटेक्चर: एक ऑर्केस्ट्रेटर, कई वर्कर

• एक पैरेंट सेशन ने प्रोग्राम को शुरू से अंत तक संभाला। इसका एकमात्र काम योजना बनाना, चाइल्ड सेशन शुरू करना, उनके आउटपुट की समीक्षा करना, चरणों को अनुक्रमित करना और मुझे तब बढ़ाना था जब किसी निर्णय के लिए मानव की आवश्यकता हो। इसने शून्य कोड लिखा।
• ~40 चाइल्ड सेशन ने हर वास्तविक काम किया: फेज़ 0 में ग्यारह समानांतर ऑडिट सेशन, प्रत्येक वेव के लिए निष्पादन सेशन, और समर्पित गेट-रनर सेशन जिनका एकमात्र काम रिग्रेशन सूट चलाना था।

यह विभाजन मायने रखता है क्योंकि लंबे समय तक चलने वाली परियोजनाओं — AI या मानव — की विफलता का तरीका संदर्भ पतन है: काम करने वाली चीज़ धीरे-धीरे समग्र प्रोग्राम की समझ खो देती है।

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

सात पैटर्न जिन्होंने इसे कारगर बनाया

1. पहले ऑडिट करें, और निष्कर्षों को एक ही मेनिफेस्ट में फ्रीज़ करें

फेज़ 0 ग्यारह समानांतर ऑडिट सेशन थे, प्रत्येक कोडबेस के एक हिस्से को कवर करता था: ऐप रूट्स, API रूट्स और क्रॉन्स, डेटाबेस स्कीमा, शेयर्ड लाइब्रेरीज़ और वर्कफ़्लोज़, स्क्रिप्ट्स और डॉक्स। उनके निष्कर्षों को एक फ़ाइल में संश्लेषित किया गया और रिपॉजिटरी में कमिट किया गया।

मेनिफेस्ट कोड की प्रत्येक इकाई को एक फैसला और एक वेव नंबर प्रदान करता है। दो नियमों ने इसे शक्तिशाली बनाया:

• कोई वर्कर स्कोप पर पुनर्विचार नहीं करता। प्रत्येक निष्पादन प्रॉम्प्ट ने प्रभावी रूप से कहा: मेनिफेस्ट सत्य का स्रोत है। इसके बिना, चालीस में से प्रत्येक सेशन अपनी स्वयं की राय बनाएगा कि स्कोप में क्या है — और वे असहमत होंगे।
• UNKNOWN का अर्थ है रुकें और पूछें।* ऑडिट जिन चीज़ों पर चुप थे, उन्हें स्पष्ट रूप से अज्ञात के रूप में चिह्नित किया गया था, एक निर्देश के साथ: अनुमान न लगाएं; फैसला लें।* मालिक के फैसले सीधे मेनिफेस्ट में दर्ज किए गए, ताकि बाद के सेशन उन्हें विरासत में ले सकें।

2. काम को सुविधा के अनुसार नहीं, बल्कि जोखिम के अनुसार क्रमबद्ध करें

वेव्स को सबसे सुरक्षित से सबसे अपरिवर्तनीय तक अनुक्रमित किया गया था।

वेव

क्या

जोखिम

0

ऑडिट + मेनिफेस्ट + रिस्टोर-पॉइंट git टैग

कोई नहीं

1

परिवर्तन जिनके कोई लाइव डिपेंडेंट नहीं होने की पुष्टि हुई

लगभग शून्य

2

शेयर्ड इंफ्रास्ट्रक्चर पर एंटैंगलमेंट सर्जरी

मध्यम

3–4

कोड परिवर्तनों का बड़ा हिस्सा

मध्यम

5

प्रोडक्शन डेटा परिवर्तन (ड्राई-रन इन्वेंटरी + स्नैपशॉट के साथ)

उच्च

6

स्कीमा माइग्रेशन

उच्च

7

डिपेंडेंसी प्रूनिंग, agents.md रीराइट, एजेंट नॉलेज-बेस ऑडिट

निम्न

प्रोडक्शन डेटा परिवर्तन (वेव 5) स्कीमा परिवर्तनों (वेव 6) से पहले आते हैं, और दोनों तभी आते हैं जब प्रभावित तालिकाओं को छूने वाले प्रत्येक कोड पथ को सत्यापित रूप से अपडेट कर दिया गया हो। जब तक माइग्रेशन चले, कुछ भी पुरानी स्थिति पर निर्भर नहीं रह सकता था।

3. फ़ाइल-डिस्जॉइंट सीमाएँ समानांतरता को सुरक्षित बनाती हैं

एक वेव के भीतर, चाइल्ड सेशन समानांतर रूप से चले — एक वेव में पेड़ के विभिन्न हिस्सों पर एक साथ काम करने वाले चार सेशन थे। अनुशासन: प्रत्येक प्रॉम्प्ट में एक स्पष्ट फ़ाइल सीमा शामिल थी, और सीमाएँ डिस्जॉइंट थीं। कोई मर्ज कॉन्फ्लिक्ट नहीं, एक ही फ़ाइल को संपादित करने वाले दो एजेंट नहीं, बच्चों के बीच किसी समन्वय की आवश्यकता नहीं।

यह क्लासिक टास्क डीकंपोज़िशन है — वही चीज़ जो आप इंजीनियरों के बीच काम बाँटते समय करेंगे — लेकिन एजेंटों को इसे स्पष्ट रूप से, हर बार प्रॉम्प्ट में बताने की आवश्यकता होती है।

4. वेव्स के बीच सुरक्षा गेट्स

कोई भी वेव तब तक शुरू नहीं हुई जब तक पिछली वेव गेट पास नहीं कर लेती। गेट्स स्वयं चाइल्ड सेशन थे:

• एक ब्राउज़र-संचालित, एंड-टू-एंड रिग्रेशन सूट जो प्लेटफ़ॉर्म के मुख्य ग्राहक वर्कफ़्लो को कवर करता था, वेव 2 के बाद और फिर वेव्स 3–4 के बाद, एक ताज़ा पृथक डेटाबेस ब्रांच पर चला।
• किसी भी प्रोडक्शन डेटा परिवर्तन से पहले: एक समर्पित सेशन ने हमारे डेटाबेस बैकअप इन्वेंटरी (गिनती, दिनांक सीमा, प्रतिधारण) का ऑडिट किया, और हमने एक ताज़ा पॉइंट-इन-टाइम स्नैपशॉट लिया।
• प्रोडक्शन स्टेप स्वयं पहले ड्राई-रन चला, मालिक की मंजूरी के लिए पंक्ति गणना तैयार की, और निष्पादन के बाद गणनाओं को फिर से सत्यापित किया।
• एक git टैग प्रत्येक बदली गई लाइन के लिए रिस्टोर पॉइंट को चिह्नित करता है।

जब कोई गेट विफल हुआ, तो इसने एक सीमित फिक्स सेशन तैयार किया। रिग्रेशन सूट ने, उदाहरण के लिए, एक ग्राहक-सामना करने वाले फ़्लो को पकड़ा जो एक अति-उत्साही परिवर्तन से टूट गया था; एक फिक्स सेशन ने इसे घंटों के भीतर बहाल कर दिया। यह सिस्टम का काम करना है — गेट ने जो ग्राहक-रिपोर्टेड बग होता, उसे उसी दिन के फिक्स में बदल दिया।

5. मानव अनुमोदन करते हैं; एजेंट प्रस्ताव करते हैं

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

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

6. आश्चर्य के लिए एक एस्केलेशन प्रोटोकॉल

बच्चों को बताया गया था कि जब वास्तविकता मेनिफेस्ट से असहमत हो तो क्या करना है: रुकें, पैरेंट को रिपोर्ट करें, सुधार न करें। वास्तविक उदाहरण:

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

पैरेंट ने इन आश्चर्यों को योजना में शामिल किया। व्यक्तिगत वर्कर ने कभी स्कोप निर्णय नहीं लिए।

7. कैम्पसाइट को साफ छोड़ें: सिस्टम को सिखाएं कि क्या बदला

वेव 7 सबसे कम आंका गया चरण हो सकता है। परिवर्तन शिप होने के बाद, सेशन ने नए आर्किटेक्चर का वर्णन करने के लिए हमारे AGENTS.md, रिपो स्किल्स और एजेंट नॉलेज बेस को फिर से लिखा — ताकि हर भविष्य का एजेंट सेशन पुराने निर्देशों से नहीं, बल्कि सच्चाई से शुरू हो। यदि आपकी इंजीनियरिंग एजेंट-संचालित है, तो आपका दस्तावेज़ीकरण लोड-बेयरिंग इंफ्रास्ट्रक्चर है।

इसकी लागत क्या थी

प्रोग्राम में प्रत्येक सेशन को टैग किया गया था, इसलिए लेज़र पूरा है: एक पैरेंट और उनतालीस चाइल्ड, सभी Devin के Ultra Agent पर, शुक्रवार दोपहर से सोमवार सुबह तक। ये हमारे उपयोग डैशबोर्ड से वास्तविक मीटर्ड लागतें हैं।

चरण

सेशन

लागत

पैरेंट ऑर्केस्ट्रेटर (मल्टी-डे)

1

$115.26

फेज़ 0 ऑडिट (दो राउंड) + मेनिफेस्ट संश्लेषण

12

$85.56

वेव 1

4

$37.55

वेव 2 (एंटैंगलमेंट सर्जरी)

4

$299.34

वेव्स 2–4 रिग्रेशन गेट्स + फिक्सेस

4

$244.69

वेव्स 3–4

5

$130.84

वेव 5 (प्रोडक्शन) + बैकअप ऑडिट

2

$15.20

वेव 6 (स्कीमा माइग्रेशन)

3

$118.83

वेव 7 (डिपेंडेंसीज़, डॉक्स, नॉलेज) + अंतिम गेट

4

$96.64

इंफ्रास्ट्रक्चर फिक्स

1

$11.47

कुल

40

$1,155.38

ब्रेकडाउन में तीन चीज़ें सामने आती हैं।

1. पूरे बारह-सेशन ऑडिट चरण की लागत जिसने मेनिफेस्ट तैयार किया, $90 से कम थी — हमने अब तक का सबसे सस्ता बीमा खरीदा है।
2. सबसे महंगी लाइन आइटम ठीक वहीं हैं जहाँ कठिन सोच थी: एंटैंगलमेंट सर्जरी ($299) और रिग्रेशन गेट्स ($245) जिन्होंने सब कुछ ईमानदार रखा।
3. उच्चतम दांव वाले कदम — प्रोडक्शन डेटा परिवर्तन — की लागत $15 थी, क्योंकि जब तक यह चला, सारा जोखिम पहले ही इंजीनियरिंग द्वारा हटा दिया गया था।

नोट: यह पूरा प्रोजेक्ट अधिक किफायती हो सकता था यदि Devin मुझे सब-एजेंट्स के लिए एक अलग मॉडल चुनने की अनुमति देता। अधिकांश कोडिंग कार्य gpt 5.5 या opus 4.8 के साथ सफलतापूर्वक पूरा किया जा सकता था। Fable को सब-एजेंट कार्य से मेल खाने के लिए उपयुक्त मॉडल चुनने का निर्देश देना सरल होता।

उसके बिना भी: $1K उस काम के लिए अविश्वसनीय रूप से सस्ता है जो हमने पूरा किया - और जिस गति से यह किया गया और सत्यापित किया गया - वाह।

https://x.com/ryancarson/status/2072694425365426344

निष्कर्ष

सुर्खियाँ यह नहीं हैं कि AI ने बहुत सारा कोड लिखा — अच्छी तरह से निर्दिष्ट परिवर्तनों को निष्पादित करने वाले एजेंट अब टेबल स्टेक्स हैं।

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

यदि आप इसे आज़माने जा रहे हैं, तो टूलिंग को नहीं, बल्कि पैटर्न को चुराएं:

1. पहले ऑडिट करें; निष्कर्षों को एक मेनिफेस्ट में फ्रीज़ करें जिस पर कोई वर्कर पुनर्विचार न कर सके।
2. वेव्स को जोखिम के अनुसार अनुक्रमित करें; अपरिवर्तनीय कदम अंत में।
3. समानांतर वर्कर को स्पष्ट रूप से डिस्जॉइंट फ़ाइल सीमाएं दें।
4. प्रत्येक वेव को एक वास्तविक रिग्रेशन सूट और वास्तविक बैकअप के साथ गेट करें।
5. विनाशकारी परिवर्तनों से पहले प्रस्तावित इन्वेंटरी की आवश्यकता रखें; विचार को नहीं, बल्कि सूची को अनुमोदित करें।
6. आश्चर्य आने से पहले एस्केलेशन पथ को परिभाषित करें।
7. अपने डॉक्स और एजेंट नॉलेज को प्रोजेक्ट के हिस्से के रूप में अपडेट करें, बाद में नहीं।

खुश ऑर्केस्ट्रेटिंग की शुभकामनाएं! :)