8 पॉइंट द्वारा GN⁺ 2025-08-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 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, find commands जैसी सीधी 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 टिप्पणियां

 
kaydash 2025-08-25

बहुत अच्छा है, बहुत खुशी हो रही है, सबसे बढ़िया है, कितना प्यारा है, मैं इसे करते रहना चाहूँगा

 
GN⁺ 2025-08-24
Hacker News की राय
  • मेरा मानना है कि KISS जैसी सादगी हमेशा जीतती है, और यह लेख अच्छी तरह व्यवस्थित था इसलिए उपयोगी लगा।

  • यह अफसोस की बात है कि Claude Code open source नहीं है, लेकिन ऐसे टूल्स भी हैं जिनसे इसकी अंदरूनी कार्यप्रणाली को बेहतर समझा जा सकता है। अगर आपको सच में जानना है कि यह कैसे काम करता है, तो Claude Trace की सिफारिश है।
    https://github.com/badlogic/lemmy/tree/main/apps/claude-trace
    यह टूल एक JSON फ़ाइल बनाता है जिसमें सेशन में इस्तेमाल हुए सभी tools और prompts दिखते हैं, और साथ ही एक आसानी से पढ़ी जा सकने वाली formatted HTML फ़ाइल भी बनाता है।

    • अगर open source विकल्प ढूंढ रहे हैं, तो OpenHands CLI देखने का सुझाव है।
      https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file
    • https://github.com/anthropics/claude-code
      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 से भी काम चल सकता है।

    • लंबा prompt तभी अच्छा है जब मॉडल उसे ठीक से handle करने के लिए optimized हो। मैंने Claude Code में दूसरे models पर स्विच करके देखा, लेकिन लंबे prompts और tool use—दोनों में—ऐसा कोई local model नहीं मिला जो प्रचार जितना अच्छा हो।
      OpenAI, Google Gemini आदि के models भी आज़माए, लेकिन Anthropic के models जितने अच्छे नहीं लगे और धीमे भी महसूस हुए। prompt लंबा होने पर वे tools भूल जाते हैं या गलत format में output देने लगते हैं।
    • (ब्लॉग पोस्ट के लेखक) का मानना है कि सिर्फ बुनियादी features का सही उपयोग करके ही लगभग 99% स्थितियों में अच्छा performance निकाला जा सकता है। loop को simple रखना और साफ़ tools देना महत्वपूर्ण है; features overlap करें तो भी कोई दिक्कत नहीं।
      स्पष्टता और सादगी सर्वोच्च हैं।
  • यह सवाल है कि Google Gemini, खासकर Pro version, Claude के मुकाबले कैसा है। Google के कई products पसंद हैं, लेकिन कंपनी का अक्सर products बंद कर देना, corporate control (जैसे Chrome) को लेकर उसका भारी-भरकम रवैया, और censorship से जुड़ी चिंताएँ परेशान करती हैं।

    • Gemini तब खास तौर पर बेहतरीन है जब पूरे repository की merged files एक साथ देकर उससे बातचीत की जा सके। पूरे codebase को समझने की इसकी क्षमता चौंकाने वाली है, और architecture design में भी बहुत मदद मिलती है। इस मामले में Claude काफ़ी पीछे है।
      मेरी अपनी रणनीति यह है कि पहले Gemini से project summary और high-level design plan बनवाता हूँ, फिर gpt5 से refinement और detailed workflow design (जैसे XML documents) करवाता हूँ, और उसके बाद वह सब Claude को दे देता हूँ। सिर्फ इससे ही Claude की भटकने वाली प्रवृत्ति से लगभग बचा जा सकता है।
    • Gemini Pro coding में बुरा नहीं है, लेकिन मेरे अनुभव में terminal-संबंधित कामों (CLI आदि) में Claude कहीं बेहतर है। ज़्यादातर CLI tools भी Claude का अधिक उपयोग करते हैं।
      https://www.tbench.ai/leaderboard
    • web UI (chat) में Gemini 2.5 Pro काफ़ी पसंद है, लेकिन command-line tool में Gemini code बेकार है और Claude code ज़्यादातर धीमा है।
    • कई function calls को follow करने वाले कठिन debugging problems में Gemini बेहतर है, जबकि Claude हर बार अधिक predictable रहता है और निर्देशों का अच्छी तरह पालन करता है। todo list manage करने में यह खास तौर पर अच्छा है।
    • पहले यह काफ़ी पसंद था, लेकिन हाल में थोड़ा ज़्यादा बेवकूफ़-सा लगने लगा है—पता नहीं सिर्फ मुझे ही ऐसा लग रहा है या नहीं।
  • मेरा मानना है कि users Claude को इसलिए इतना अच्छा कहते हैं क्योंकि base model खुद असली coding work में बहुत मजबूत है, न कि सिर्फ सामान्य benchmark problems में। GitHub Copilot इस्तेमाल करके देखें तो Claude, OpenAI और Google models से बहुत आगे दिखता है। अंतर इतना बड़ा है कि बाकी models व्यवहार में लगभग बेकार लगते हैं।

    • Anthropic reinforcement learning के दौरान अंदरूनी तौर पर model और prompt को optimize कर सकता है, इसलिए लेख में दी गई “मौजूदा तरीके वैसे ही इस्तेमाल करो” वाली सलाह Anthropic models पर अधिक लागू होती है। subscription model की वजह से loop efficiency बेहतर करने के लिए मज़बूत incentive भी है।
    • इसे सिर्फ base model के अंतर से नहीं समझाया जा सकता। VS Code में opus और cline को साथ इस्तेमाल करने और Claude code इस्तेमाल करने के बीच productivity का अंतर संख्याओं में बताना मुश्किल है, लेकिन CC के साथ मैं ज़्यादा काम कर पाता हूँ।
    • बहुत तारीफ़ सुनकर मैंने उम्मीद के साथ Claude Code को एक महीने इस्तेमाल किया, लेकिन उल्टा निराशा ही बढ़ी। यह Cursor sidebar से भी कमतर अनुभव लगा, और लगा कि शायद मैं ही इसे गलत तरीके से इस्तेमाल कर रहा हूँ। दो अलग codebases में यह बार-बार बेहूदी code mistakes करता रहा, जो निराशाजनक था।
  • मैं अभी Claude Code के साथ Security Onion में Elastic से जुड़ी समस्या debug करने की कोशिश कर रहा हूँ, लेकिन कुछ मिनट बाद ही उलझा हुआ JS code आने लगता है और Error: kill EPERM एरर दिखता है।
    logs देखकर लगता है कि शायद यह Node.js process को kill कर रहा है और उसी से Claude खुद भी बंद हो जाता है। या फिर समस्या हल न होने पर Claude खुद ही exit कर रहा है।
    जो भी हो, अगर process बना रहे तो काश यह थोड़ा और मदद करता।

    • Claude और localstack के कुछ हिस्से एक-दूसरे के साथ अच्छे से काम नहीं करते। Rust में हालांकि यह उम्मीद से बेहतर करता है।
      मुझे लगता है कि आगे चलकर वही language/platform/architecture मुख्यधारा में आएँगे जिन्हें LLM सबसे अच्छी तरह समझते हैं। उदाहरण के लिए अगर LLM nodejs को 10 गुना बेहतर संभालता है, तो शुरू से Elixir या Go के बजाय nodejs चुनना ज़्यादा तर्कसंगत हो सकता है। junior developers भी LLM की मदद से mid-level या senior स्तर जैसा काम कर सकते हैं।
    • ऐसी error तब भी आती है जब आप process को superuser permissions के साथ चलाने के लिए sudo इस्तेमाल करते हैं और वह timeout हो जाता है।
    • installation upgrade करने या पुरानी installation files हटाकर फिर से install करने से भी कभी-कभी समस्या हल हो जाती है। मैंने अपना issue ऐसे ही ठीक किया था।
    • किसी दूसरे LLM पर स्विच करके यह देखने का भी अनुभव है कि वास्तव में क्या हुआ था, हालांकि यह आधिकारिक सलाह नहीं है।
    • मुझे Elasticsearch और LLM के combination में कभी अच्छे नतीजे नहीं मिले। ज़्यादातर outputs बिना आधार वाले “hallucinations” ही थे। शायद इसलिए कि इंटरनेट पर सही examples बहुत कम हैं।
  • मैंने अपने startup का पहला MVP पूरा का पूरा Claude Code से बनाया, और अब paying customers भी मिल चुके हैं। बेशक अंदर ही अंदर यह बुनियादी चिंता बनी रहती है कि अगर कोई SEV (service outage) incident हो गया तो सब एक झटके में बिखर सकता है, लेकिन security vulnerability fixes, test-driven development, और long-term roadmap के अनुसार software architecture design के लिए मैं अभी भी Claude का सक्रिय रूप से उपयोग कर रहा हूँ।
    उम्मीद है कि आगे चलकर ऐसी कहानियाँ और आम होंगी।

    • product के बारे में जिज्ञासा है, क्या उसका लिंक साझा कर सकते हैं? वास्तविक user cases देखना दिलचस्प होगा।
    • “security vulnerability fixes” सुनकर मज़ाक में पूछा गया कि क्या शुरुआत में code भी Claude ने लिखा था और vulnerabilities भी उसी ने बनाई थीं?
    • test-driven development और software design जैसे हिस्सों में Claude ने ठोस तौर पर कैसे मदद की, इसके उदाहरण बताने का अनुरोध है।
    • मैंने Claude Code से कहा कि हर महीने मेरे bank account में पैसे transfer कर दिया करे, और मज़ाक यह है कि वह सच में ऐसा कर देता है।
    • यह feedback है कि खास तौर पर क्या चीज़ Claude Code से बनाई गई, यह खुलकर बताना चाहिए।
  • अगर “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 हो चुका है। साइट वैध नहीं है, इसलिए सावधान रहने की सलाह है।