Claude Code के लिए संपूर्ण ग्राफ इंजीनियरिंग प्लेबुक

अधिकतर लोग अभी भी Claude Code का उपयोग एक बहुत महँगे इंटर्न की तरह कर रहे हैं।

वे इसे एक कार्य देते हैं, एक उत्तर की प्रतीक्षा करते हैं, फिर मैन्युअल रूप से तय करते हैं कि आगे क्या होगा।

लेकिन जो टीमें AI से सबसे अधिक लाभ उठा रही हैं, वे एक छोटी वितरित प्रणाली के करीब कुछ बना रही हैं।

एक एजेंट समस्या का दायरा तय करता है।

पाँच सस्ते एजेंट समानांतर में खोज करते हैं।

एक नियतात्मक स्क्रिप्ट डुप्लिकेट हटाती है।

तीन संदेहास्पद एजेंट निष्कर्षों को तोड़ने का प्रयास करते हैं।

एक शीर्ष-स्तरीय मॉडल अंतिम निर्णय लेता है।

यही ग्राफ़ इंजीनियरिंग है।

पढ़ना जारी रखने से पहले:

इस गाइड को बुकमार्क करें ताकि जब आप अपने स्वयं के Claude वर्कफ़्लो बनाना शुरू करें तो आप ग्राफ़ पैटर्न पर वापस आ सकें।

और फॉलो करें

@Gyome1_ -

मैं Claude Code, AI एजेंट्स, और उन सिस्टमों को विस्तार से समझाता हूँ जो एक मॉडल को एक विश्वसनीय इंजीनियरिंग वर्कफ़्लो में बदल देते हैं।

मैंने वास्तविक एजेंट आर्किटेक्चर, वर्कफ़्लो आरेखों और प्रोडक्शन पैटर्न का विश्लेषण करने में सप्ताह बिताए ताकि Graph Engineering को एक व्यावहारिक प्लेबुक में फिर से बनाया जा सके।

एक लंबा प्रॉम्प्ट लिखने के बजाय, आप उस पथ को डिज़ाइन करते हैं जो सूचना सिस्टम में ले जाती है:

linear → fan-out → reduce → verify → synthesize

प्रत्येक एजेंट एक सीमित कार्य वाला नोड बन जाता है। प्रत्येक एज से संरचित डेटा बहता है। राउटर तय करते हैं कि कौन सी शाखा चलेगी। वेरिफ़ायर कमज़ोर आउटपुट को अस्वीकार करते हैं। लूप तब तक चलते रहते हैं जब तक ग्राफ़ को कुछ नया खोजने में नहीं आता।

महत्वपूर्ण बदलाव यह है कि Claude Code को अब एक विशाल चेकलिस्ट से गुज़रने वाली एक बुद्धि की तरह व्यवहार नहीं करना पड़ता।

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

मूल पैटर्न नए नहीं हैं। सॉफ़्टवेयर इंजीनियरों ने दशकों से DAGs, पाइपलाइन, बैरियर, MapReduce और वितरित वर्कर्स का उपयोग किया है।

जो बदल गया है वह यह है कि अब प्रत्येक नोड के अंदर क्या बैठता है।

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

यह गाइड पूरे सिस्टम को सबसे सरल लीनियर एजेंट से लेकर डायमंड ग्राफ़, राउटर नोड, प्रतिकूल वेरिफ़ायर पैनल, अभिसरण लूप, मॉडल टियरिंग, और Claude Code के अंदर सीधे उत्पन्न गतिशील वर्कफ़्लो तक विभाजित करता है।

अंत तक, आप एक बड़े कार्य को देखकर यह पूछना बंद कर देंगे:

"मुझे कौन सा प्रॉम्प्ट लिखना चाहिए?"

1. GRAPH ENGINEERING की शुरुआत बिल से होती है

Graph Engineering को अक्सर अधिक एजेंट चलाने के एक तरीके के रूप में प्रस्तुत किया जाता है।

यह ढाँचा महँगे भाग को छोड़ देता है।

आप एक ही रिपॉजिटरी पर बीस Claude एजेंट चला सकते हैं और बीस ओवरलैपिंग रिपोर्ट, दोहराया गया संदर्भ, विरोधाभासी निष्कर्ष, और एक बहुत बड़ा API बिल प्राप्त कर सकते हैं।

एक उपयोगी ग्राफ़ यह नियंत्रित करता है कि गणना कहाँ होती है, कौन सा मॉडल प्रत्येक निर्णय को संभालता है, और अनिश्चित निष्कर्ष वर्कफ़्लो में कैसे चलते हैं।

कल्पना करें कि आप Claude Code को एक प्रोडक्शन माइग्रेशन तैयार करने के लिए कहते हैं:

रिपॉजिटरी का निरीक्षण करें, हर निर्भरता खोजें, माइग्रेशन का प्रस्ताव दें, जोखिमों की पहचान करें, योजना को सत्यापित करें, और अंतिम ब्रीफ लिखें।

एक प्रॉम्प्ट के अंदर, यह एक लंबी अपारदर्शी प्रक्रिया बन जाती है। Claude कोडबेस खोजता है, निष्कर्षों को संदर्भ में संग्रहीत करता है, माइग्रेशन डिज़ाइन करता है, अपनी योजना की समीक्षा करता है, और अंतिम रिपोर्ट तैयार करता है।

जब रिपोर्ट विफल होती है, तो विफलता के स्रोत का पता लगाना मुश्किल होता है। Claude ने कोई फ़ाइल छोड़ दी हो सकती है, किसी निर्भरता को गलत समझा हो सकता है, कोई पिछला विवरण खो दिया हो सकता है, या सत्यापन के दौरान एक कमज़ोर धारणा स्वीकार कर ली हो सकती है।

प्रत्येक चरण उसी महँगे मॉडल पर भी चल सकता है, भले ही कार्य के कुछ हिस्सों में सरल निष्कर्षण या छँटाई शामिल हो।

Graph Engineering उस वर्कफ़्लो को खोलता है और हर निर्णय को एक दृश्य स्थान देता है।

निरीक्षण शाखाएँ एक ही समय पर चलती हैं क्योंकि वे एक ही दायरे वाले कार्य का उपयोग करती हैं और एक-दूसरे के आउटपुट पर निर्भर नहीं होती हैं।

उनके निष्कर्ष एक रिड्यूस स्टेज पर मिलते हैं, जहाँ डुप्लिकेट गायब हो जाते हैं और साक्ष्य एक छोटे डेटासेट में संपीड़ित हो जाते हैं।

एक राउटर तब गंभीरता को पढ़ता है। नियमित परिवर्तन एक हल्की समीक्षा से गुज़रते हैं। उच्च-जोखिम वाले निष्कर्ष अंतिम मॉडल तक पहुँचने से पहले कई स्वतंत्र समीक्षकों से गहन विश्लेषण प्राप्त करते हैं।

परिणाम एक ऐसा वर्कफ़्लो है जहाँ विलंबता, मॉडल लागत, संदर्भ आकार, और सत्यापन गहराई को ग्राफ़ की संरचना के माध्यम से नियंत्रित किया जाता है।

एक नोड को एक निर्णय लेना चाहिए

एक उपयोगी नोड की एक सीमित जिम्मेदारी होती है।

डिप्रेकेटेड API की हर कॉल खोजें। प्रत्येक माइग्रेशन जोखिम को निम्न, मध्यम, या उच्च के रूप में वर्गीकृत करें। रोलबैक योजना का परीक्षण विफलता मामलों के लिए करें।

प्रत्येक नोड को एक स्पष्ट इनपुट, एक परिभाषित आउटपुट, और एक सीमित निर्णय सतह की आवश्यकता होती है।

एक नोड जो रिपॉजिटरी खोजता है, व्यावसायिक प्रभाव का अनुमान लगाता है, फिक्स डिज़ाइन करता है, और सिफारिश लिखता है, उसमें अभी भी कई छिपे हुए चरण होते हैं।

डिबगिंग मुश्किल बनी रहती है क्योंकि मध्यवर्ती तर्क एक मॉडल कॉल के अंदर दबा होता है।

छोटी सीमाएँ यह प्रकट करती हैं कि साक्ष्य सिस्टम में कहाँ प्रवेश किया और उसका अर्थ कहाँ बदला।

एक एज को साक्ष्य ले जाना चाहिए

एक एज अगले नोड के लिए आवश्यक डेटा का प्रतिनिधित्व करता है।

स्कैनर एक पूर्वानुमानित ऑब्जेक्ट लौटा सकता है:

1{
2  "file": "src/auth/session.ts",
3  "lines": [84, 119],
4  "dependency": "legacySessionClient",
5  "confidence": 0.94,
6  "evidence": "दोनों कॉल साइट्स डिप्रेकेटेड रिफ्रेश मेथड पर निर्भर हैं।"
7}

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

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

संरचित आउटपुट साक्ष्य को स्थिर रखता है जबकि यह ग्राफ़ से गुज़रता है।

कुछ नोड सामान्य कोड होते हैं

मान लीजिए आठ खोज एजेंट अस्सी निष्कर्ष लौटाते हैं।

वर्कफ़्लो को सरणियों को संयोजित करने, खाली प्रतिक्रियाओं को त्यागने, डुप्लिकेट हटाने, और शेष वस्तुओं को क्रमबद्ध करने की आवश्यकता है।

इन संक्रियाओं के नियतात्मक उत्तर हैं:

1const uniqueFindings = [
2  ...new Map(
3    results
4      .flatMap(batch => batch ?? [])
5      .map(item => [`${item.file}:${item.lines.join("-")}`, item])
6  ).values()
7];

एक JavaScript ट्रांसफ़ॉर्म इसे तुरंत संभालता है और हर रन पर समान आउटपुट उत्पन्न करता है। उसी कार्य को दूसरे मॉडल पर भेजने से टोकन लागत बढ़ती है और एक और स्थान बनता है जहाँ साक्ष्य गायब हो सकता है।

मॉडल नोड खोज, वर्गीकरण, तुलना, समीक्षा और संश्लेषण के आसपास होते हैं। कोड सत्यापन, डिडुप्लिकेशन, छँटाई, स्पष्ट रूटिंग नियम और अन्य पूर्वानुमानित परिवर्तनों को संभाल सकता है।

यह विभाजन ग्राफ़ की नींव बन जाता है।

प्रत्येक मॉडल कॉल एक ऐसे निर्णय के अनुरूप होना चाहिए जिसमें वास्तव में निर्णय की आवश्यकता हो।

2. डायमंड: वास्तविक एजेंट ग्राफ़ कैसे काम को स्थानांतरित करते हैं

अधिकांश गंभीर एजेंट ग्राफ़ अंततः एक ही आकार लेते हैं।

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

वह आकार डायमंड है।

बाईं ओर fan-out है।

मध्य बिंदु जहाँ सभी शाखाएँ मिलती हैं, वह barrier है।

दाईं ओर fan-in है।

यह पैटर्न हर जगह दिखाई देता है जब कोई कार्य एक संदर्भ विंडो के लिए बहुत बड़ा हो जाता है।

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

प्रत्येक वर्कर को एक संकीर्ण असाइनमेंट के साथ समान दायरा प्राप्त होता है।

ग्राफ़ तब तक प्रतीक्षा करता है जब तक पर्याप्त उपयोगी साक्ष्य वापस नहीं आ जाते।

Fan-out को स्वतंत्र कार्य बनाना चाहिए

एक शाखा fan-out में तब होती है जब वह साझा इनपुट से शुरू हो सकती है और बिना किसी अन्य शाखा के आउटपुट को पढ़े एक उपयोगी परिणाम उत्पन्न कर सकती है।

सुरक्षा ऑडिट के लिए, विभाजन इस तरह दिख सकता है:

Claude Code इन कॉलों को एक बैरियर प्रिमिटिव जैसे parallel() के साथ समवर्ती रूप से लॉन्च कर सकता है।

1const findings = await parallel(
2  checks.map(check => async () => {
3    return agent({
4      task: "रिपॉजिटरी का निरीक्षण करें, हर निर्भरता खोजें, माइग्रेशन का प्रस्ताव दें, जोखिमों की पहचान करें, योजना को सत्यापित करें, और अंतिम ब्रीफ लिखें।",
5      context: auditScope,
6      schema: FINDING_SCHEMA
7    });
8  })
9);

ऑर्केस्ट्रेशन सामान्य JavaScript में रहता है। प्रत्येक शाखा को एक सीमित कार्य मिलता है और एक मान्य ऑब्जेक्ट लौटाता है।

परिणाम आउटपुट के एक संग्रह के रूप में आता है जिसे फ़िल्टर किया जा सकता है, निरीक्षण किया जा सकता है, और अगले चरण में पास किया जा सकता है।

एक बड़े fan-out को अभी भी हर शाखा के पीछे एक कारण चाहिए।

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

उपयोगी समानांतरता विभिन्न स्रोतों, दृष्टिकोणों, कोड क्षेत्रों या परिकल्पनाओं से आती है।

बैरियर एक निर्णय बिंदु बनाता है

एक बैरियर अगले चरण को तब तक रोकता है जब तक आवश्यक शाखाएँ पूरी नहीं हो जातीं।

वह रुकना मायने रखता है क्योंकि कुछ निर्णय पूरे सेट पर निर्भर करते हैं।

एक रैंकिंग नोड सबसे महत्वपूर्ण कमज़ोरी की पहचान नहीं कर सकता जबकि आधी रिपॉजिटरी का अभी भी निरीक्षण किया जा रहा है।

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

बैरियर पर, ग्राफ़ के पास रन की स्थिति का निरीक्षण करने का अवसर होता है:

1const completed = findings.filter(Boolean);
2
3if (completed.length < MIN_REQUIRED_RESULTS) {
4  throw new Error("Insufficient audit coverage");
5}

यहीं पर आंशिक विफलताएँ दिखाई देती हैं।

एक वर्कर टाइम आउट कर सकता है, विकृत डेटा लौटा सकता है, या कोई निष्कर्ष नहीं दे सकता। null मानों को फ़िल्टर करने से रन चलता रहता है, लेकिन प्रोडक्शन वर्कफ़्लो को आमतौर पर एक स्पष्ट नीति की आवश्यकता होती है:

• कितनी सफल शाखाएँ आवश्यक हैं;
• कौन सी शाखाएँ अनिवार्य हैं;
• क्या विफल नोड को पुनः प्रयास करना चाहिए;
• क्या अंतिम परिणाम को अपूर्ण चिह्नित किया जाना चाहिए।

बैरियर इसलिए विश्वसनीयता मॉडल का हिस्सा है, न कि केवल एक सिंक्रनाइज़ेशन तंत्र।

संश्लेषण से पहले कम करें

Fan-out के बाद, ग्राफ़ में दर्जनों ओवरलैपिंग निष्कर्ष हो सकते हैं।

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

रिड्यूस स्टेज साक्ष्य तैयार करता है।

कुछ कमी कोड में हो सकती है:

1const unique = deduplicateByKey(
2  completed.flatMap(result => result.findings),
3  finding => `${finding.file}:${finding.line}:${finding.type}`
4);

अगली परत में निर्णय की आवश्यकता हो सकती है:

1const curated = await agent({
2  task: `
3    संबंधित निष्कर्षों को समूहित करें।
4    सभी फ़ाइल और लाइन संदर्भों को संरक्षित करें।
5    प्रत्येक समूह को परिचालन प्रभाव के आधार पर रैंक करें।
6    हर निष्कर्ष के लिए सबसे मजबूत साक्ष्य लौटाएं।
7  `,
8  input: unique,
9  schema: CURATED_FINDINGS_SCHEMA
10});

कमी नियंत्रित करती है कि अंतिम मॉडल तक क्या पहुँचता है।

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

सबसे सुरक्षित पैटर्न हर कम किए गए दावे और उसके स्रोत वस्तुओं के बीच एक लिंक रखता है।

1{
2  "risk": "माइग्रेशन के बाद सत्र रिफ्रेश विफल हो सकता है",
3  "severity": "उच्च",
4  "sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],
5  "evidence": [
6    "तीन सेवाएँ डिप्रेकेटेड रिफ्रेश मेथड को कॉल करती हैं",
7    "कोई फ़ॉलबैक पथ मौजूद नहीं है",
8    "एकीकरण कवरेज गायब है"
9  ]
10}

अब संश्लेषण नोड को ट्रेसेबिलिटी खोए बिना एक छोटा डेटासेट प्राप्त होता है।

3. विश्वसनीयता ग्राफ़ का हिस्सा है

एक ग्राफ़ जल्दी समाप्त हो सकता है और फिर भी एक खराब उत्तर उत्पन्न कर सकता है।

एक बार जब कई एजेंट एक ही कार्य की खोज, वर्गीकरण और समीक्षा करना शुरू कर देते हैं, तो मुख्य समस्या नियंत्रण बन जाती है।

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

जोखिम के अनुसार रूट करें

एक राउटर नोड संरचित आउटपुट पढ़ता है और अगली शाखा चुनता है।

वर्गीकरण एक मॉडल से आ सकता है, जबकि शाखा स्वयं कोड में स्पष्ट रहती है।

1const route =
2  finding.severity === "high"
3    ? runFullAudit(finding)
4    : runQuickReview(finding);

यह महँगी समीक्षा को सार्थक प्रभाव वाले निष्कर्षों के आसपास केंद्रित रखता है।

एक उपयोगी राउटर उन फ़ील्ड पर निर्भर करता है जिनका ग्राफ़ निरीक्षण कर सकता है: गंभीरता, आत्मविश्वास, प्रभावित सिस्टम, वित्तीय जोखिम, या लापता साक्ष्य की उपस्थिति।

स्वतंत्र सत्यापन जोड़ें

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

एक मजबूत ग्राफ़ महत्वपूर्ण निष्कर्षों को अलग-अलग असाइनमेंट वाले कई समीक्षकों को भेजता है।

समीक्षकों को मूल उत्तर में सुधार करने के निर्देश नहीं मिलने चाहिए। उनका कार्य उन कारणों की खोज करना है जिनसे यह अधूरा या गलत हो सकता है।

ग्राफ़ किसी निष्कर्ष को आगे बढ़ने से पहले सहमति की आवश्यकता कर सकता है:

1const accepted = votes.filter(vote => vote.approve).length >= 2;

कोड बदलने वाले एजेंटों को अलग करें

समानांतर कोडिंग एजेंट एक-दूसरे के साथ हस्तक्षेप कर सकते हैं जब वे एक ही कार्यशील निर्देशिका को संपादित करते हैं।

एक एजेंट किसी फ़ाइल को ओवरराइट कर सकता है जबकि दूसरा अभी भी उसे पढ़ रहा है। टेस्ट असंबंधित परिवर्तनों के मिश्रण के विरुद्ध चल सकते हैं।

Git worktrees प्रत्येक शाखा को रिपॉजिटरी की अपनी प्रतिलिपि देते हैं।

1मुख्य रिपॉजिटरी
2      │
3      ├→ worktree/auth-fix
4      ├→ worktree/db-migration
5      └→ worktree/test-repair

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

यह अलगाव को मैन्युअल सफाई चरण के बजाय ग्राफ़ का हिस्सा बनाता है।

खोज को अभिसरण करने दें

कुछ कार्य एक पास में पूरे नहीं किए जा सकते।

एक रिपॉजिटरी ऑडिट एक ऐसी निर्भरता का पता लगा सकता है जो किसी अन्य पैकेज की ओर इशारा करती है। वह पैकेज एक और कॉल साइट प्रकट कर सकता है। ग्राफ़ को बिना वह सब कुछ दोहराए जो वह पहले ही देख चुका है, खोज जारी रखने का एक नियंत्रित तरीका चाहिए।

1const seen = new Set();
2let dryRounds = 0;
3
4while (dryRounds < 2) {
5  const findings = await discoverNext([...seen]);
6  const fresh = findings.filter(item => !seen.has(item.id));
7
8  fresh.forEach(item => seen.add(item.id));
9  dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;
10}

महत्वपूर्ण विवरण हर पहले देखी गई वस्तु के विरुद्ध डिडुप्लिकेशन करना है।

केवल पुष्ट निष्कर्षों के विरुद्ध डिडुप्लिकेशन करने से अस्वीकृत या अनिश्चित वस्तुओं को अगले पास पर वापस आने और उसी कार्य को फिर से उपभोग करने की अनुमति मिलती है।

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

मॉडल को नोड से मिलाएँ

प्रत्येक नोड को उपलब्ध सबसे मजबूत मॉडल की आवश्यकता नहीं होती है।

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

मॉडल टियरिंग ग्राफ़ की एक और संपत्ति बन जाती है।

बजट इस बात से निर्धारित होता है कि कितने नोड चलते हैं, लूप कितनी बार दोहराते हैं, प्रत्येक एज से कितना संदर्भ गुज़रता है, और कौन सा मॉडल प्रत्येक चरण को संभालता है।

बीस सस्ते खोज कॉल वाला ग्राफ़ अभी भी एक मजबूत कॉल से अधिक खर्च कर सकता है। आर्किटेक्चर को किसी अन्य शाखा की आवश्यकता से पहले एक टोकन बजट की आवश्यकता होती है।

जानें कि कब चित्र बनाना बंद करना है

छोटे कार्यों को शायद ही कभी राउटर, वोटिंग पैनल, वर्कट्री और अभिसरण लूप की आवश्यकता होती है।

ग्राफ़ ओवरहेड में ऑर्केस्ट्रेशन कोड, स्कीमा, रीट्राय, लॉगिंग, मध्यवर्ती भंडारण, और डिबग करने के लिए और अधिक विफलता स्थितियाँ शामिल हैं।

एक रैखिक वर्कफ़्लो आमतौर पर पर्याप्त होता है जब एक मॉडल प्रासंगिक संदर्भ रख सकता है, कार्य में कुछ स्वतंत्र शाखाएँ होती हैं, और गलत उत्तर की लागत कम होती है।

Graph Engineering तब उपयोगी हो जाता है जब कार्य में समानांतर कार्य, महँगे निर्णय, बड़े साक्ष्य सेट, या सार्थक सत्यापन आवश्यकताएँ शामिल हो जाती हैं।

पूर्ण वर्कफ़्लो अंततः इस तरह दिख सकता है:

मूल्य काम की गति को दृश्यमान बनाने से आता है।

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

उस बिंदु पर, Claude Code अब एक लंबे निर्देश के माध्यम से काम नहीं कर रहा है।

यह एक इंजीनियर्ड सिस्टम को निष्पादित कर रहा है।