Claude Code फ्रेमवर्क युद्ध
(shmck.substack.com)- डेवलपर अब AI के साथ सहयोग करने के तरीके सीखने के चरण में हैं, और Claude का मूल्य तब अधिकतम होता है जब उसे सिर्फ एक चैटबॉट नहीं बल्कि एक फ्रेमवर्क की तरह इस्तेमाल किया जाए
- कम्युनिटी में Claude को कैसे कॉन्फ़िगर और उपयोग किया जाए, इस पर कई तरह के प्रयोग जारी हैं, और प्रयोग इतने सक्रिय हैं कि इसे Claude Code Framework Wars कहा जा रहा है
- इसके जरिए Claude को प्रोजेक्ट मैनेजर, आर्किटेक्ट, डेवलपर, रिव्यूअर जैसी कई भूमिकाओं में इस्तेमाल करने की धारा बन रही है
- फ्रेमवर्क डिज़ाइन में कार्य प्रबंधन, निर्देश देना, एजेंट सहयोग, सेशन संचालन, टूल एक्सेस, कोड डेवलपमेंट, डिलीवरी, कॉन्टेक्स्ट बनाए रखना जैसी 8 प्रमुख निर्णयों की आवश्यकता होती है
- मुख्य सीख यह है कि AI डेवलपर की जगह नहीं लेता, बल्कि संरचित नियमों और भूमिकाओं के जरिए उत्पादकता बढ़ाने वाले सहकर्मी के रूप में स्थापित होता है
परिचय
- मुख्य विचार: Claude को एक साधारण बातचीत वाले टूल की बजाय फ्रेमवर्क मानना, ताकि स्पष्ट नियमों और वर्कफ़्लो के जरिए अनुमानित और मूल्यवान परिणाम पैदा किए जा सकें
- डेवलपर कोडिंग के बजाय उच्च-मूल्य भूमिकाओं (प्रोजेक्ट प्रबंधन, डिज़ाइन, आर्किटेक्चर) की ओर शिफ्ट होते हैं
- Claude Code फ्रेमवर्क बिना कोड लिखे संरचित प्रॉम्प्ट्स पर काम करता है
- Claude Code फ्रेमवर्क युद्ध: डेवलपर कम्युनिटी उत्पादक AI उपयोग के लिए अलग-अलग अप्रोच पर प्रयोग कर रही है
- दर्जनों ओपन सोर्स प्रोजेक्ट वर्कफ़्लो और भूमिका संरचना को परिभाषित करते हुए प्रतिस्पर्धा कर रहे हैं
- उदाहरण: Agent OS, Claude-Flow
फ्रेमवर्क डिज़ाइन करते समय विचार करने योग्य मुख्य विकल्प
1. कार्य प्रबंधन कहाँ होगा
- Claude जिन टास्क स्रोतों को रेफ़र कर सके, उन्हें परिभाषित करना ज़रूरी है
- Markdown backlog: कार्यों को Markdown फ़ॉर्मैट की todo list के रूप में प्रबंधित करना
- उदाहरण: Backlog.md, ReqText
- संरचित टेक्स्ट: प्रोडक्ट स्पेक्स को कार्यों में बदलना
- उदाहरण: Agent OS
- Issue/ticket: स्पेक्स को GitHub Issues या Jira tickets में स्टोर करना और उन्हें code review से जोड़ना
- उदाहरण: ccpm
- Markdown backlog: कार्यों को Markdown फ़ॉर्मैट की todo list के रूप में प्रबंधित करना
- मुख्य बात: टास्क ऐसी जगह स्टोर होने चाहिए जहाँ Claude पहुँच सके और उन्हें ट्रैक कर सके
2. Claude को गाइड कैसे दें
- अस्पष्ट प्रॉम्प्ट्स की जगह Claude को स्पष्ट संरचना में निर्देश देना
- Command library: /create-tasks, /review जैसे पहले से परिभाषित slash commands
- Coding standards: tech stack और coding guidelines को स्पष्ट करना
- Definition of done: कार्य पूरा होने के मानदंडों को कोडिफ़ाई करना
- Trigger validation hooks: हर बदलाव पर linting और testing लागू करना
- Claude reviewer: Claude का विकास और रिव्यू दोनों साथ में करना
- मुख्य बात: स्पष्ट और दोहराए जा सकने वाले नियम Claude के काम की गुणवत्ता बढ़ाते हैं
3. एजेंट सहयोग संरचना
- कई Claude agents का उपयोग होने पर भूमिकाओं और योजना के जरिए समन्वय करना
- Role simulation: AI का PM, आर्किटेक्ट, डेवलपर, टेस्टर की भूमिका निभाना
- उदाहरण: Agent OS
- Swarm parallel processing: spec → pseudocode → code → test जैसी संरचित फ़्लो में कई agents को एक साथ चलाना
- उदाहरण: Claude-Flow
- Repository-native artifacts: कार्य, logs और architectural decision records (ADR) को codebase में स्टोर करके memory बनाए रखना
- उदाहरण: Roo Commander
- Role simulation: AI का PM, आर्किटेक्ट, डेवलपर, टेस्टर की भूमिका निभाना
- मुख्य बात: समन्वय कई AI workers के बीच टकराव को रोकता है
4. सेशन संचालन का तरीका
- AI output में अव्यवस्था से बचने के लिए सेशन को कार्य वातावरण के रूप में सेट करना
- Terminal orchestration: Claude का commands, windows और logs को नियंत्रित करना
- उदाहरण: Symphony, Claude-Squad
- Parallel worktrees: Git Worktrees के जरिए कई branches को समानांतर चलाना
- उदाहरण: Crystal
- Parallel containers: Claude को अलग-अलग containers में चलाकर टकराव रोकना
- उदाहरण: ClaudeBox
- Terminal orchestration: Claude का commands, windows और logs को नियंत्रित करना
- मुख्य बात: समानांतर काम से बिना टकराव के उत्पादकता अधिकतम होती है
4. सेशन चलाने का तरीका
- AI output में अव्यवस्था से बचने के लिए सेशन को कार्य वातावरण के रूप में सेट करना
- Terminal orchestration: Claude का commands, windows और logs को नियंत्रित करना
- उदाहरण: Symphony, Claude-Squad
- Parallel worktrees: Git Worktrees के जरिए कई branches को समानांतर चलाना
- उदाहरण: Crystal
- Parallel containers: Claude को अलग-अलग containers में चलाकर टकराव रोकना
- उदाहरण: ClaudeBox
- Terminal orchestration: Claude का commands, windows और logs को नियंत्रित करना
- मुख्य बात: समानांतर काम से बिना टकराव के उत्पादकता अधिकतम होती है
5. Claude की टूल एक्सेस
- Claude को पूरे tech stack के ज्ञान का उपयोग करने लायक बनाना
- MCP integration: browser, database, test runner, UI automation framework को जोड़ना
- Custom tool library: shell scripts और commands से बनाई गई लाइब्रेरी
- उदाहरण: Symphony
- Database accessor: शक्तिशाली database access tools
- उदाहरण: Claudable with Supabase
- Testing and validation hooks: Vitest, Jest आदि से कार्य पूरा होने से पहले tests चलाना
- उदाहरण: Agent OS
- मुख्य बात: टूल इंटीग्रेशन Claude को साधारण autocomplete से सक्रिय टीम सदस्य में बदल देता है
6. कोड डेवलपमेंट का तरीका
- Claude ज़रूरत के अनुसार अलग-अलग भूमिकाएँ निभा सकता है
- Project Manager (PM): product specs को tasks और backlog में बदलना
- आर्किटेक्ट: पूरी संरचना डिज़ाइन करना, interfaces परिभाषित करना, coding से पहले नियम तय करना
- इम्प्लीमेंटर: tests और standards के अनुसार code लिखना
- QA: कार्य से जुड़ी समस्याओं की समीक्षा करना
- उदाहरण: BMAD-code
- रिव्यूअर: PR quality, readability और risk का audit करना
- मुख्य बात: software lifecycle के पूरे दायरे में AI का उपयोग
7. कोड डिलीवरी का तरीका
- कोड repository तक कैसे पहुँचेगा, यह तरीका परिभाषित करना
- मुख्य बात: production के लिए सुरक्षित iteration या prototype के लिए scaffold में से चुनना
8. कॉन्टेक्स्ट कैसे बनाए रखें
- Claude की भूलने की समस्या को फ्रेमवर्क मेमोरी से हल करना
- Documents and journals: CLAUDE.md, architecture notes, project journal को अपडेट रखना
- उदाहरण: Claude Conductor
- Persistent memory and checkups: हाल के कार्यों का सार, project health check, decision storage
- उदाहरण: Claude-Flow
- Documents and journals: CLAUDE.md, architecture notes, project journal को अपडेट रखना
- मुख्य बात: memory के बिना AI बार-बार गलती दोहराता है, memory से प्रगति जटिलता संभाल सकती है
एकीकृत करने के तरीके
- इन विकल्पों को मेन्यू की तरह देखें; एक साथ सब कुछ सेट करना ज़रूरी नहीं
- शुरुआती सेटअप: Markdown backlog + ticket diffs
- संरचित टीम: product specs + standards + role simulation
- Experiment-centric: repository artifacts + parallel sessions
- Prototype mode: app builder + document scaffold
निष्कर्ष और निहितार्थ
- मुख्य सीख: Claude संरचित वातावरण में सबसे अच्छा प्रदर्शन करता है
- डेवलपर की भूमिका को बदलने के बजाय, boilerplate काम कम करके spec definition, design review और architecture definition पर ध्यान केंद्रित करने देता है
- अगर काम गलत दिशा में जाए, तो यह तेजी से पटरी से उतर सकता है; इसलिए संरचित प्रबंधन ज़रूरी है
- अभी यह शुरुआती चरण में है, लेकिन फ्रेमवर्क AI को जादुई डिब्बा नहीं बल्कि प्रबंधित किए जा सकने वाले टीम सदस्यों के समूह की ओर ले जा रहे हैं
- जितनी अधिक संरचना देंगे, उतनी अधिक वैल्यू मिलेगी
- ओपन सोर्स प्रोजेक्ट्स के जरिए कम्युनिटी अलग-अलग फ्रेमवर्क पर प्रयोग कर रही है और उत्पादक AI उपयोग के तरीके खोज रही है
- डेवलपर Claude का व्यवस्थित उपयोग करके उच्च-मूल्य कार्यों पर ध्यान केंद्रित कर सकते हैं और AI को टीम सदस्य के रूप में जोड़कर उत्पादकता अधिकतम कर सकते हैं
1 टिप्पणियां
Hacker News राय
मैंने Claude Code के लिए कई "framework" आज़माए हैं, लेकिन वस्तुनिष्ठ रूप से परफ़ॉर्मेंस बेहतर हुई हो, ऐसा स्पष्ट नहीं लगा
इनमें अक्सर किसी फ़ॉर्मूले की तरह जटिल प्रक्रियाओं के इर्द-गिर्द बस एक तरह की रस्म-अदायगी दिखती है, और असल में फ़ायदा किससे हो रहा है यह सवाल बना रहता है
ऐसा लगता है कि इस तरह का framework approach मॉडल ट्रेनिंग के उद्देश्य से मेल नहीं खाता
असल में यह मॉडल पर अनावश्यक जानकारी फेंकते हुए, "मेरे तय किए हुए process" में फिट करने के लिए ज़बरदस्ती context को प्रदूषित करता है
मेरा मानना है कि context pollution को हटाकर, केवल वही जानकारी देनी चाहिए जो काम के लिए सच में ज़रूरी हो, और धीरे-धीरे सुधार करते रहना चाहिए
इस तरह की पारंपरिक collaboration style, context-limited agent के context के बाहर चलाई जाए तो ज़्यादा उपयुक्त संरचना लगती है
इस लेख में subagents का ज़रा भी ज़िक्र नहीं है, इसलिए जिज्ञासा है कि यह कब लिखा गया था
मैं "memory bank से केवल मौजूदा task से जुड़ी जानकारी लाना" और "tests चलाकर केवल failures और coverage पर feedback देना" जैसे काम subagent को सौंपता हूँ
इससे main agent का context बहुत जल्दी भर जाने से रोकने में मदद मिली
https://docs.anthropic.com/en/docs/claude-code/sub-agents
dev containers और worktrees जैसी कुछ व्यावहारिक practices अपनाने से ज़िंदगी काफ़ी आसान हो गई
मैंने project files manage करने और worktree बनाने के लिए अपना एक shell script "framework" भी बनाया, और यह काम लगभग दो दिन में पूरा हो गया
किसी खास tool पर निर्भर न होने की आज़ादी भी है
मैं सहमत हूँ कि context pollution सच में ध्यान देने लायक वास्तविक समस्या है
खासकर जब मैंने देखा कि MCP endpoint definitions मेरे context का बड़ा हिस्सा (लगभग 20 हज़ार tokens) खा जाती हैं, तब से MCP चुनते समय context issue को भी ज़रूर ध्यान में रखता हूँ
यह मुझे असली project manager जैसी स्थिति लगी
मैं चाहता हूँ कि Claude का उपयोग करते समय proposal writing में पहले अस्पष्ट बातों को पूछने वाला चरण शामिल हो
अगर किसी असली engineer को सिर्फ requirements और expected outcomes दिए जाएँ, तो वह implementation से पहले स्वाभाविक रूप से अतिरिक्त सवाल पूछकर बात साफ़ करेगा
मैं उम्मीद करता हूँ कि Claude भी इस तरह की clarification process को automate कर सके
मैंने कई बार देखा है कि अस्पष्ट सवालों को बिल्कुल ध्यान में न लेने से बहुत सी ग़लतियाँ हो जाती हैं
ऐसे frameworks लागू करते समय, लोग वास्तव में कितनी autonomy देते हैं, और किस environment (greenfield/brownfield) में इसका उपयोग करते हैं, यह जानना चाहता हूँ
क्या किसी ने enterprise software में Claude Code जोड़कर भरोसेमंद नतीजे हासिल किए हैं, यह भी पूछना चाहता हूँ
मेरे पास कंपनी में Claude Code की काफ़ी खुली access है, लेकिन मेरी codebase में frontend UI या Playwright शामिल होते ही नतीजे अस्थिर हो जाते हैं
कितना code debris छूटता है, teammates के साथ collaboration fatigue कैसा रहता है, pull request का आकार, inference cost, parallelization के समय management कैसे करते हैं—ऐसी वास्तविक उपयोग संबंधी जानकारी जानना चाहता हूँ
README documents अक्सर system-specific शब्दों, emoji, और बहुत ज़्यादा personal toolbox organization से भरे होते हैं, इसलिए वे कभी-कभी बेचने के लिए लिखे गए promo documents जैसे लगते हैं
आख़िरकार लगता है कि Anthropic जैसी कंपनियाँ इन सुविधाओं को अपने CLI में ही शामिल कर लेंगी
व्यक्तिगत रूप से मैं reasoning model से 10-page spec, सख़्त lint/type check/formatter/hook, task checklist, और red/green TDD तक सब संभलवाता हूँ, और GPT-5 को एक बार “go” कहने पर ज़रूरी output अपने-आप बन जाता है
एक जैसे tools हों तो कोई भी अपना system आसानी से बना सकता है
मैं $200 Max plan इस्तेमाल करता हूँ, इसलिए inference cost भी स्थिर रहती है
खासकर नए features जोड़ने जैसी greenfield स्थितियों में परिणाम स्पष्ट रूप से अच्छे रहे
जटिल refactoring या सिस्टम के गहरे बदलावों में भी (अगर अच्छी design docs हों) काफ़ी प्रगति होती है, लेकिन जहाँ documentation कमज़ोर हो वहाँ असर अच्छा नहीं पड़ता
शुरुआत में "अच्छा नहीं" कोड—यानी style, reusability, या maintainability में कमज़ोर implementations—काफ़ी मिलती थीं, लेकिन CLAUDE.md file को मज़बूत करने और "elixir-code-reviewer" subagent को developer persona के लिए अनिवार्य करने के बाद code quality में साफ़ सुधार दिखा
हमारा platform open source है, इसलिए अपनी Claude command और subagent configuration अभी यहाँ साझा कर रहा हूँ
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
ब्लॉग में LLM वाली एक खास शैली बहुत तेज़ी से महसूस हुई
जानकारी उपयोगी है, लेकिन यह मज़ेदार है कि AI के बारे में AI से सीख रहे हैं
आजकल AI पर लिखे गए बहुत से लेख ऐसे ही लगते हैं
वास्तव में, अगर काम बहुत साधारण न हो तो Claude Code को सीधे मॉनिटर करना पड़ता है, और गलत दिशा में जाते ही तुरंत दख़ल देना होता है
सुरक्षा के लिहाज़ से उसे बहुत ज़्यादा permissions नहीं दे सकते, और यह भी देखना पड़ता है कि वह वास्तव में कौन-से commands चला रहा है
अभी के "frameworks" को बहुत लंबा रास्ता तय करना है, और फिलहाल इसे “बहुत तेज़ी से code उगलने वाला junior intern” समझना ज़्यादा यथार्थवादी है
हो सकता है लेखक ने repo ठीक से नहीं देखा हो, या रिसर्च वास्तव में सीमित रही हो
उदाहरण के लिए superClaude कोई MCP server नहीं है, और metaGPT Claude Code के साथ compatible नहीं लगता
मुझे हमेशा यह जिज्ञासा रही है कि agents को इंसानों की तरह अपना context खुद manage क्यों नहीं करने दिया जाता
समझ नहीं आता कि पिछले काम का पूरा history हर बार क्यों शामिल किया जाता है
अगर agent को यह तय करने दिया जाए कि कौन-सा context रखना प्रभावी होगा, और context management के फ़ायदे-नुकसान वह खुद सीखे, तो शायद वह हर task बेहतर कर पाए
अंततः यहाँ भी textbook "bitter lesson" दोहराया जा रहा है
लोग तरह-तरह के "frameworks" बनाते हैं, लेकिन अगली पीढ़ी के models आते ही वे सब बेकार हो जाते हैं
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
यह देखकर काफ़ी आश्चर्य हुआ कि BMAD-method का ज़िक्र नहीं है
मेरे अनुभव में BMAD-method, Claude Code के लिए सबसे अच्छा complement है
मैं जानना चाहता हूँ कि BMAD-method क्या है
क्या यह सिर्फ system prompt स्तर की चीज़ है, और यह इतना उपयोगी क्यों लगा—यह समझना चाहता हूँ
https://github.com/bmad-code-org/BMAD-METHOD
BMAD system, पोस्ट में बताए गए AgentOS जैसा दिखता है
इस तरह की context engineering मेरे लिए प्रभावी रही है, और मैंने खुद Claude से commands और agents बनवाकर उन्हें अपनी ज़रूरत के हिसाब से बदला है
हाल के समय में मैं context sharing के लिए json और markdown का भी सक्रिय रूप से उपयोग कर रहा हूँ
taskmaster भी ऐसा ही है, लेकिन सूची में नहीं है
context management मुझे low-level programming जैसा लगता है
मुझे यह वैसा लगता है जैसे सही computation के लिए CPU registers में बिल्कुल सही values डालनी हों
फ़र्क बस इतना है कि हर task के लिए कौन-सा context जोड़ना या हटाना है, इस पर हमारा नियंत्रण बहुत कम है
मैंने B-MAD Framework आज़माया और असर इतना अलग था कि अब इस tool के बिना काम करना मुश्किल लगता है
उम्मीद है कि आगे ऐसे frameworks और बढ़ेंगे
जानना चाहता हूँ कि क्या किसी ने इन frameworks को सच में इस्तेमाल किया है
क्या ये वास्तव में नतीजे देते हैं, या सिर्फ़ trend के साथ चलने वाला hype हैं
नतीजे अनुमान के मुताबिक होते हैं: बिना validation के तरह-तरह की features ठूँस दी जाती हैं, ठीक से documentation भी नहीं होती, और सब कुछ Claude-isms से भरा रहता है
वास्तव में वे बस उन कुछ projects के लिए उपयोगी होते हैं जिनमें उनके निर्माता की दिलचस्पी होती है