Claude Code इतना अच्छा क्यों है
(minusx.ai)- Claude Code उपयोगिता के लिहाज़ से एक बेहद शानदार AI agent/workflow है
- आर्किटेक्चरल सरलता और स्पष्ट control loop की वजह से debugging और maintenance का अनुभव आसान बनता है
- RAG का उपयोग न्यूनतम रखकर और उन्नत prompts व context files का सक्रिय उपयोग करके LLM की ताकत को अधिकतम किया जाता है
- विभिन्न tools और स्पष्ट guidelines के ज़रिए काम की स्पष्टता और consistency बनाए रखी जाती है
- complexity के बजाय आसानी से समझ आने वाली संरचना और prompt design के कारण, अपना खुद का LLM agent भी इसी तरह बनाया जा सकता है
अवलोकन
- Claude Code (आगे CC) वर्तमान में उपलब्ध AI agent/coding workflows में सबसे संतोषजनक अनुभवों में से एक देता है
- CC की ताकत लक्षित code editing, अनावश्यक बाधाओं में कमी, और user control बनाए रखते हुए बेहतर UX देने में है
- Claude 4 model और उसकी खास Interleaved Thinking इसमें मुख्य भूमिका निभाते हैं, लेकिन Cursor या Github Copilot जैसे उसी model पर आधारित दूसरे tools की तुलना में भी यह कम झुंझलाहट देता है
- यह लेख CC के implementation principles को खोलकर समझाता है और वैसा ही अनुभव देने वाला स्वयं का LLM agent बनाने के लिए व्यावहारिक मार्गदर्शिका देता है
Claude Code का मुख्य गुण: सरलता
- सबसे बड़ा सबक है "इसे सरल रखो (Keep Things Simple, Dummy)"
- LLM agents में अगर जटिल संरचनाएँ (multi-agent, complex RAG, validation systems आदि) जोड़ दी जाएँ, तो debugging और improvement बेहद कठिन हो जाते हैं
- CC एक single main loop, सरल toolset, और तुरंत समझ आने वाली संरचना अपनाता है, और सारी core logic को एक ही file में रखकर अनावश्यक boilerplate और complexity से बचता है
सरलता क्यों महत्वपूर्ण है
- multi-agent संरचना के बजाय ज़्यादातर काम एक main thread में संभाले जाते हैं
- history summarization, UX के लिए message consolidation जैसी चीज़ें सहायक रूप में लागू होती हैं
- जब जटिल काम की ज़रूरत हो, तो खुद की प्रति बनाकर sub-agent में branch किया जाता है (recursive branching नहीं, सिर्फ एक स्तर तक अनुमति)
- todo list का सक्रिय उपयोग किया जाता है
- जटिल समस्याओं को sub-agent में बाँटकर संभाला जाता है, लेकिन परिणाम main message history में merge कर दिए जाते हैं
- अत्यधिक abstract multi-layer संरचनाएँ (multiple agents, graph navigation) उल्टा system stability और scalability को कमजोर कर सकती हैं
हल्के models का सक्रिय उपयोग
- claude-3-5-haiku जैसे हल्के LLM models का उपयोग अधिकांश requests में किया जाता है
- बड़े files पढ़ना, webpages parse करना, git history summarize करना जैसे कई काम कुशलता से किए जाते हैं
- हल्के models के उपयोग से लागत अधिकतम 70~80% तक कम की जा सकती है
- सभी प्रमुख feature calls के लिए उपयुक्त model combinations इस्तेमाल करने की सिफारिश की जाती है
परिष्कृत prompt design
- CC का system prompt काफी बड़ा (लगभग 2800 tokens) है और इसमें कई sections होते हैं (tone & style, task management, tool usage policy, OS/directory info आदि)
- claude.md जैसे context files की पूरी सामग्री हमेशा शामिल की जाती है ताकि context की समृद्धि अधिकतम हो
- system prompt में policies, examples, सावधानियाँ, tool इस्तेमाल का timing आदि बहुत विस्तार से बताए जाते हैं
XML और Markdown का साथ में उपयोग
- prompt के भीतर XML tags और Markdown संरचना दोनों का एक साथ उपयोग किया जाता है
<system-reminder>,<good-example>,<bad-example>आदि के माध्यम से detail और conditional branching वाली जानकारी दी जाती है- markdown headings के ज़रिए sections को स्पष्ट रूप से अलग किया जाता है
context files का महत्व
- claude.md होने या न होने से CC के प्रदर्शन में बड़ा फर्क पड़ता है
- codebase से अनुमान लगाना कठिन हो ऐसी अतिरिक्त rules (folder/library exclusions, preferred policies आदि) देने के लिए यह ज़रूरी है
- MinusX भी minusx.md के ज़रिए team/user preferences को व्यवस्थित करता है
RAG को न्यूनतम रखना, LLM search का उपयोग
- CC RAG (Retrieval Augmented Generation) के बजाय, एक वास्तविक developer की तरह
ripgrep,jq,findcommands जैसी सीधी code search आधारित संरचना को प्राथमिकता देता है- यह complex RAG setups से आने वाली छिपी हुई failure possibilities (जैसे similarity functions, re-rankers, chunking) का विकल्प देता है
- इसमें LLM सीधे code context को खोजता और समझता है, जिससे moving parts कम होते हैं और RL training की efficiency भी बढ़ सकती है
tool design और hierarchy
- CC low-level (Bash, Read, Write), mid-level (Edit, Grep, Glob), high-level (Task, WebFetch आदि) सभी तरह के tools को support करता है
- usage frequency और accuracy को ध्यान में रखकर ज़रूरी tools को अलग-अलग विभाजित किया गया है
- tools के description, examples, और उपयोग का समय system prompt में साफ़-साफ़ बताया गया है
- जटिल कामों को
Taskया high-level tools के माध्यम से consistency के साथ संभाला जाता है
Explicit Todo management से context loss की रोकथाम
- लंबे समय तक चलने वाले LLM agents की प्रमुख समस्याओं (context loss, दिशा खो देना) को हल करने के लिए CC सीधे maintain की जाने वाली Todo list से state management करता है
- multi-agent प्रणाली के बजाय model खुद Todo अपडेट करता है, जिससे काम की दिशा और लचीलापन दोनों बने रहते हैं
agent के tone, style और friendliness का control
- tone, style, proactiveness आदि को अलग sections में manage किया जाता है
- अनावश्यक explanations से बचना, emojis को सिर्फ स्पष्ट अनुरोध पर ही अनुमति देना आदि के ज़रिए consistent user experience डिज़ाइन किया जाता है
- "बहुत महत्वपूर्ण (IMPORTANT)", "कभी नहीं (NEVER)", "हमेशा (ALWAYS)" जैसे मजबूत modifiers के ज़रिए सावधानियाँ बताई जाती हैं
decision algorithm और flow design
- LLM को जिन मुख्य algorithms का पालन करना है, उन्हें स्पष्ट रूप से लिखा और उदाहरणों सहित समझाया जाता है
- सिर्फ Do/Don't lists देने की तुलना में flow charts और step-by-step checklists algorithm stability बनाए रखने में अधिक प्रभावी हैं
- अलग-अलग instructions और examples के टकराव की संभावना को ध्यान में रखकर roles की सीमा और policies को संरचित रूप से बताया जाता है
design patterns और व्यावहारिक लागू करने के सुझाव
- मजबूत opinions और संरचना, अपना agent design करते समय तुरंत benchmark की तरह इस्तेमाल की जा सकती है
- दिमाग उलझाने वाले frameworks के अति-उपयोग के बजाय सरल और प्रभावी संरचना बनाना ज़्यादा महत्वपूर्ण है
- वास्तविक MinusX में भी इन सिद्धांतों में से कई लागू हैं, और उन्हें धीरे-धीरे और बढ़ाने की योजना है
निष्कर्ष
- Claude Code से सबसे बड़ा सबक: “सरलता ही सबसे बड़ी ताकत है”
- संरचनात्मक स्पष्टता, अर्थपूर्ण prompt design, और हल्के tools का संयोजन शक्तिशाली LLM agents को संभव बनाता है
- अपना खुद का LLM agent बनाते समय CC की design philosophy और guidelines को सक्रिय रूप से संदर्भित करना बहुत उपयोगी हो सकता है
2 टिप्पणियां
बहुत अच्छा है, बहुत खुशी हो रही है, सबसे बढ़िया है, कितना प्यारा है, मैं इसे करते रहना चाहूँगा
Hacker News की राय
मेरा मानना है कि KISS जैसी सादगी हमेशा जीतती है, और यह लेख अच्छी तरह व्यवस्थित था इसलिए उपयोगी लगा।
यह अफसोस की बात है कि Claude Code open source नहीं है, लेकिन ऐसे टूल्स भी हैं जिनसे इसकी अंदरूनी कार्यप्रणाली को बेहतर समझा जा सकता है। अगर आपको सच में जानना है कि यह कैसे काम करता है, तो Claude Trace की सिफारिश है।
https://github.com/badlogic/lemmy/tree/main/apps/claude-trace
यह टूल एक JSON फ़ाइल बनाता है जिसमें सेशन में इस्तेमाल हुए सभी tools और prompts दिखते हैं, और साथ ही एक आसानी से पढ़ी जा सकने वाली formatted HTML फ़ाइल भी बनाता है।
https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file
system prompt भी देखा जा सकता है।
मॉडल को मूल रूप से काम को कई चरणों में बाँटकर धैर्यपूर्वक हल करने के लिए प्रशिक्षित किया गया है, और यह failure cases में भी काफ़ी हद तक robust है।
आजकल जब multi-agent systems पर बहुत ध्यान दिया जा रहा है, यह देखना उपयोगी लगा कि LLM-केंद्रित संगठन इस समस्या को कैसे देखते हैं। मैं भी रोज़मर्रा में अलग-अलग design perspectives के साथ प्रयोग कर रहा हूँ, इसलिए इससे जुड़ाव महसूस हुआ।
मुख्य insights ये हैं:
(1) prompt लंबा हो तो भी ठीक है, और tool का उद्देश्य या वह कैसे मदद करेगा जैसी बुनियादी व्याख्या ज़रूर शामिल होनी चाहिए।
(2) tool call बहुत बुनियादी स्तर की चीज़ है, इसलिए उसमें context को और बेहतर ढंग से शामिल करना चाहिए—जैसे कब इस्तेमाल करना है, कब नहीं करना है।
(3) system state को message के रूप में manage करना ठीक है। fancy तरीकों—जैसे dataframe store करना, variables parse करना—के बारे में भी सोचा, लेकिन अगर context window लंबी हो तो सिर्फ messages से भी काम चल सकता है।
OpenAI, Google Gemini आदि के models भी आज़माए, लेकिन Anthropic के models जितने अच्छे नहीं लगे और धीमे भी महसूस हुए। prompt लंबा होने पर वे tools भूल जाते हैं या गलत format में output देने लगते हैं।
स्पष्टता और सादगी सर्वोच्च हैं।
यह सवाल है कि Google Gemini, खासकर Pro version, Claude के मुकाबले कैसा है। Google के कई products पसंद हैं, लेकिन कंपनी का अक्सर products बंद कर देना, corporate control (जैसे Chrome) को लेकर उसका भारी-भरकम रवैया, और censorship से जुड़ी चिंताएँ परेशान करती हैं।
मेरी अपनी रणनीति यह है कि पहले Gemini से project summary और high-level design plan बनवाता हूँ, फिर gpt5 से refinement और detailed workflow design (जैसे XML documents) करवाता हूँ, और उसके बाद वह सब Claude को दे देता हूँ। सिर्फ इससे ही Claude की भटकने वाली प्रवृत्ति से लगभग बचा जा सकता है।
https://www.tbench.ai/leaderboard
मेरा मानना है कि users Claude को इसलिए इतना अच्छा कहते हैं क्योंकि base model खुद असली coding work में बहुत मजबूत है, न कि सिर्फ सामान्य benchmark problems में। GitHub Copilot इस्तेमाल करके देखें तो Claude, OpenAI और Google models से बहुत आगे दिखता है। अंतर इतना बड़ा है कि बाकी models व्यवहार में लगभग बेकार लगते हैं।
मैं अभी Claude Code के साथ Security Onion में Elastic से जुड़ी समस्या debug करने की कोशिश कर रहा हूँ, लेकिन कुछ मिनट बाद ही उलझा हुआ JS code आने लगता है और
Error: kill EPERMएरर दिखता है।logs देखकर लगता है कि शायद यह Node.js process को kill कर रहा है और उसी से Claude खुद भी बंद हो जाता है। या फिर समस्या हल न होने पर Claude खुद ही exit कर रहा है।
जो भी हो, अगर process बना रहे तो काश यह थोड़ा और मदद करता।
मुझे लगता है कि आगे चलकर वही language/platform/architecture मुख्यधारा में आएँगे जिन्हें LLM सबसे अच्छी तरह समझते हैं। उदाहरण के लिए अगर LLM nodejs को 10 गुना बेहतर संभालता है, तो शुरू से Elixir या Go के बजाय nodejs चुनना ज़्यादा तर्कसंगत हो सकता है। junior developers भी LLM की मदद से mid-level या senior स्तर जैसा काम कर सकते हैं।
sudoइस्तेमाल करते हैं और वह timeout हो जाता है।मैंने अपने startup का पहला MVP पूरा का पूरा Claude Code से बनाया, और अब paying customers भी मिल चुके हैं। बेशक अंदर ही अंदर यह बुनियादी चिंता बनी रहती है कि अगर कोई SEV (service outage) incident हो गया तो सब एक झटके में बिखर सकता है, लेकिन security vulnerability fixes, test-driven development, और long-term roadmap के अनुसार software architecture design के लिए मैं अभी भी Claude का सक्रिय रूप से उपयोग कर रहा हूँ।
उम्मीद है कि आगे चलकर ऐसी कहानियाँ और आम होंगी।
अगर “Keep things simple” वाली बात सही है, तो यह सेटअप उल्टा थोड़ा complex भी लग सकता है।
मैं तो हमेशा एक prompt में जो चाहिए वही पूछने वाले सरल तरीके से ही काफ़ी काम कर लेता हूँ।
यक़ीन नहीं होता कि यहाँ चर्चा की गई complex structures, एक बहुत अच्छी तरह लिखे गए prompt के मुकाबले वास्तव में कितनी अतिरिक्त value देती हैं।
उदाहरण के लिए, "नई सीख रही भाषा में while loop कैसे बनता है" जैसी one-sentence prompt शायद ज़्यादा प्रभावी हो सकती है।
control flow उल्टा और धुंधला लगता है। यह भी संदेह है कि क्या LLM appendix (tools या system prompt) हिस्से का सही इस्तेमाल करता भी है या नहीं। अगर request बहुत complex हो जाए, तो क्या उसका कुछ हिस्सा ignore नहीं हो जाता या tokens व्यर्थ नहीं जाते?
हिस्सों में बाँटकर अलग-अलग prompts के साथ programming करना मुझे कहीं ज़्यादा स्वाभाविक लगता है।
मैं ऐसे उदाहरण या prompts देखना चाहूँगा जहाँ लोग कोई दूसरा तरीका इस्तेमाल कर रहे हों।
लोग वास्तव में LLM का उपयोग करके पूरा program कैसे बनाते हैं, यह जानने की जिज्ञासा है; prompt-दर-prompt बनाये गए examples देखना चाहूँगा।
संदर्भ के लिए, लेख के अंत में minusx.com का लिंक है, लेकिन उसका security certificate 553 दिन पहले expire हो चुका है। साइट वैध नहीं है, इसलिए सावधान रहने की सलाह है।