बड़े codebase में Claude Code कैसे काम करता है: best practices और शुरुआत के बिंदु

 (claude.com)
4 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code index upload किए बिना developer machine पर file system navigation और grep, reference tracking के जरिए live codebase को सीधे पढ़ता है
  • प्रदर्शन केवल model पर नहीं, बल्कि CLAUDE.md, hooks, skills, plugins, MCP server और इनके build order से बने harness पर भी बहुत निर्भर करता है
  • बड़े repository में पतला और layered CLAUDE.md, subdirectory से शुरुआत, scoped test·lint, और exclude rules navigation efficiency बढ़ाते हैं
  • LSP integration string search के बजाय symbol-आधारित definition·reference tracking देता है, जिससे multi-language और बड़े codebase में गलत navigation कम होता है
  • सफल adoption के लिए हर 3–6 महीने में configuration review करना और plugin·permissions·rules को manage करने के लिए एक DRI या agent manager रखना ज़रूरी है

बड़े codebase में Claude Code कैसे navigate करता है

  • Claude Code एक software engineer की तरह file system में घूमता है, files पढ़ता है, grep से ज़रूरी चीज़ें ढूंढता है, और पूरे codebase में references को follow करता है
  • यह developer machine पर locally चलता है, इसलिए codebase index बनाने, maintain करने या server पर upload करने की ज़रूरत नहीं होती
  • RAG-आधारित AI coding tools पूरे codebase को embed करते हैं और query के समय relevant chunks लाते हैं, लेकिन बड़े environment में embedding pipeline तेज़ development speed के साथ कदम नहीं मिला पाती
  • अगर index कुछ हफ्ते, कुछ दिन, या कुछ घंटे पुरानी स्थिति दिखाता है, तो वह ऐसे functions या modules लौटा सकता है जिनका नाम बदल चुका हो या जो पिछले sprint में हट चुके हों, और यह संकेत भी न मिले कि जानकारी पुरानी है
  • Claude Code का agentic search embedding pipeline या central index के बिना हर developer instance को live codebase के आधार पर काम करने देता है
  • इसकी एक कमी भी है: Claude तब सबसे अच्छा काम करता है जब उसे यह समझने के लिए पर्याप्त starting context मिले कि कहाँ देखना है
  • अगर उससे कहा जाए कि वह 1 अरब lines वाले codebase में किसी अस्पष्ट pattern के सभी instances ढूंढे, तो काम शुरू होने से पहले ही वह context window limit से टकरा सकता है
  • जिन टीमों ने codebase को अच्छी तरह set up किया है और CLAUDE.md files व skills से context को layer किया है, उन्हें बेहतर परिणाम मिलते हैं

model जितना ही महत्वपूर्ण harness

  • Claude Code का performance model से ज़्यादा उसके आसपास बने harness पर निर्भर करता है
  • harness पाँच extension points से बना है: CLAUDE.md, hooks, skills, plugins, और MCP server
  • हर layer पिछली layer के ऊपर बनती है, इसलिए टीम इन्हें किस क्रम में बनाती है, यह भी महत्वपूर्ण है
  • LSP integration और subagents इस setup को पूरा करने वाली अतिरिक्त क्षमताएँ हैं

  • CLAUDE.md files

    • CLAUDE.md एक context file है जिसे Claude हर session की शुरुआत में अपने-आप पढ़ता है
    • root file में बड़ा चित्र होता है, जबकि subdirectory files में local rules होते हैं
    • क्योंकि यह हर session में load होती है, इसलिए performance गिरने से बचाने के लिए इसमें केवल broadly applicable बातें रखनी चाहिए

  • Hooks

    • Hooks केवल Claude के गलत व्यवहार को रोकने वाले scripts नहीं हैं; उनका बड़ा मूल्य setup को लगातार बेहतर बनाना है
    • stop hook session के दौरान हुई चीज़ों की समीक्षा करके, context ताज़ा होने पर CLAUDE.md update सुझा सकता है
    • start hook team-specific context को dynamically load कर सकता है ताकि developer बिना manual setup के अपने module के अनुरूप configuration पाए
    • linting और formatting जैसी automatic checks, Claude को निर्देश याद दिलाने की तुलना में, hook के ज़रिए rules को निश्चित रूप से लागू करने पर अधिक consistent results देती हैं

  • Skills

    • Skills ज़रूरत पड़ने पर on-demand विशेषज्ञता उपलब्ध कराते हैं, बिना हर session को भारी बनाए
    • बड़े codebase में दर्जनों task types हो सकते हैं, लेकिन हर session में हर expertise लोड करना ज़रूरी नहीं
    • Skills progressive disclosure के ज़रिए specialized workflows और domain knowledge को context space से बाहर रखते हैं और केवल ज़रूरत पड़ने पर load करते हैं
    • उदाहरण के लिए, security review skill Claude के vulnerability assessment के समय load होती है, और documentation processing skill तब load होती है जब code change के बाद docs update करनी हों
    • Skills को specific paths तक scope किया जा सकता है, ताकि payments service team की deployment skill केवल उसी directory से bind हो और monorepo के दूसरे हिस्सों में अपने-आप load न हो

  • Plugins

    • Plugins अच्छे setup को tribal knowledge बनकर रह जाने से बचाने का माध्यम हैं
    • plugin, skills, hooks और MCP settings को एक installable package में bundle करता है
    • अगर कोई नया engineer पहले दिन plugin install कर ले, तो उसे तुरंत वही context और capabilities मिल जाती हैं जो पहले से Claude इस्तेमाल करने वालों के पास हैं
    • plugin updates को managed marketplaces के जरिए पूरी organization में roll out किया जा सकता है
    • एक बड़े retail organization ने Claude को अपने internal analytics platform से जोड़ने वाली skill बनाई, ताकि business analysts workflow छोड़े बिना performance data ला सकें, और फिर company-wide rollout से पहले उसे plugin के रूप में deploy किया

  • Language Server Protocol integration

    • Language Server Protocol(LSP) integration Claude को developer के IDE जैसी code navigation capability देता है
    • बड़े codebase के लिए ज़्यादातर IDE पहले से LSP चला रहे होते हैं, जो “go to definition” और “find all references” जैसी सुविधाएँ देते हैं
    • जब Claude को यह access मिलता है, तो वह function calls से definitions तक जा सकता है, files में references trace कर सकता है, और अलग-अलग भाषाओं में एक ही नाम वाले functions में फर्क कर सकता है — यानी symbol-level precision मिलती है
    • LSP के बिना Claude text pattern matching पर निर्भर रहता है और गलत symbol तक पहुँच सकता है
    • एक enterprise software company ने बड़े environment में C और C++ navigation को stable बनाने के लिए Claude Code rollout से पहले organization-wide LSP integration deploy किया
    • multi-language codebase में यह सबसे मूल्यवान investments में से एक है

  • MCP servers

    • MCP server वह तरीका है जिससे Claude उन internal tools, data sources, और APIs से जुड़ता है जिन तक वह सीधे नहीं पहुँच सकता
    • सबसे mature teams ऐसे MCP servers बनाती हैं जो Claude के लिए structured search को callable tools के रूप में expose करें
    • दूसरी teams Claude को internal docs, ticket systems, और analytics platforms से जोड़ती हैं

  • Subagents

    • Subagents navigation और editing को अलग करते हैं
    • subagent अपने context window वाला एक isolated Claude instance होता है, जो काम लेकर उसे पूरा करता है और final result parent को लौटाता है
    • harness तैयार होने के बाद कुछ teams read-only subagents चलाती हैं जो subsystem map करते हैं, result files में लिखते हैं, और फिर main agent उस बड़े चित्र के आधार पर edits करता है

  • हर component की भूमिका और आम भ्रम

    • CLAUDE.md: यह Claude द्वारा अपने-आप पढ़ी जाने वाली context file है और हर session में load होती है। project-specific rules और codebase knowledge के लिए उपयुक्त है, लेकिन इसमें ऐसी reusable expertise डाल देना आसान है जो skill में होनी चाहिए
    • Hooks: event से trigger होने वाले scripts, जो key moments पर चलते हैं। consistent behavior automation और session learnings capture करने के लिए उपयुक्त हैं, लेकिन ऐसे काम prompt से करवाना आसान है जिन्हें auto-run होना चाहिए
    • Skills: specific task types के लिए packaged instructions, जो relevant होने पर on-demand load होते हैं। session और project के पार reusable expertise के लिए उपयुक्त हैं, लेकिन सब कुछ CLAUDE.md में डाल देना आसान है
    • Plugins: skills, hooks और MCP settings के bundles, जो setup के बाद हमेशा उपलब्ध रहते हैं। organization-wide working setup distribute करने के लिए उपयुक्त हैं, लेकिन अच्छे setup को tribal knowledge बनाकर छोड़ देना आसान है
    • LSP: language-specific servers के जरिए real-time code intelligence, जो setup के बाद हमेशा उपलब्ध रहती है। typed languages में symbol-level navigation और automatic error detection के लिए उपयुक्त है, लेकिन यह मान लेना आसान है कि यह अपने-आप काम करेगी
    • MCP server: external tools और data connections, जो setup के बाद हमेशा उपलब्ध रहते हैं। उन internal tools तक Claude की पहुँच के लिए उपयुक्त हैं जिन तक वह सीधे नहीं पहुँच सकता, लेकिन basic setup के सही होने से पहले MCP connection बना लेना आसान है
    • Subagents: specific tasks के लिए अलग Claude instances, जो call होने पर चलते हैं। navigation और editing अलग करने और parallel work के लिए उपयुक्त हैं, लेकिन navigation और editing को एक ही session में रखना आसान है
    • LSP तक पहुँच plugin layer के जरिए होती है, और subagents configured extension point नहीं बल्कि delegation capability हैं

सफल deployments में बार-बार दिखे तीन setup patterns

  • बड़े scale पर भी navigable codebase बनाना

    • बड़े codebase में Claude कितनी मदद कर सकता है, यह उसकी सही context खोजने की क्षमता से सीमित होता है
    • अगर हर session में बहुत अधिक context load हो, तो performance गिरती है; अगर बहुत कम context हो, तो Claude अंधेरे में navigate करता है
    • प्रभावी deployments शुरू में इस बात में निवेश करते हैं कि codebase Claude के लिए पढ़ने योग्य बने

    • CLAUDE.md files को पतला और layered रखें

      • Claude codebase में चलते समय CLAUDE.md files को additive तरीके से load करता है
      • root file बड़ा चित्र देती है, और subdirectory files local rules संभालती हैं
      • root file में केवल pointers और critical cautions होने चाहिए; बाकी सब आसानी से noise बन सकता है

    • repository root नहीं, subdirectory से शुरू करें

      • Claude तब सबसे अच्छा काम करता है जब उसका scope codebase के उस हिस्से तक सीमित हो जो task से वास्तव में जुड़ा हो
      • monorepo में यह थोड़ा उल्टा लग सकता है, क्योंकि tools अक्सर root access को default मानते हैं
      • Claude अपने-आप directory tree में ऊपर की ओर जाकर मिले सभी CLAUDE.md files load कर लेता है, इसलिए root-level context खोता नहीं है

    • tests और lint commands को subdirectory के हिसाब से scope करें

      • अगर Claude ने केवल एक service बदली है लेकिन पूरा test suite चला दिया, तो timeout हो सकता है और irrelevant output पर context waste होता है
      • subdirectory के CLAUDE.md files में उन commands को साफ़ लिखना चाहिए जो codebase के उसी हिस्से पर लागू होती हैं
      • यह service-oriented codebase में अच्छा काम करता है, जहाँ हर directory के अपने tests और build commands होते हैं
      • जिन compiled language monorepos में deep cross-directory dependencies हों, वहाँ per-subdirectory scoping कठिन हो सकती है और project-specific build configuration चाहिए हो सकती है

    • .ignore files से generated files, build outputs और third-party code को exclude करें

      • .claude/settings.json में permissions.deny rules commit करने से exclusion rules version-controlled हो जाते हैं
      • team के सभी developers बिना अलग setup के एक जैसा noise reduction पाते हैं
      • कुछ codebase में generated files खुद development target हो सकती हैं
      • code generator पर काम करने वाले developers local settings में project-level exclusion rules override कर सकते हैं, बिना बाकी team को प्रभावित किए

    • अगर directory structure काफ़ी नहीं है, तो codebase map बनाएं

      • जिन organizations में code सामान्य directory structure में व्यवस्थित नहीं है, वहाँ root में रखा हल्का Markdown file मददगार होता है
      • हर top-level folder और उसमें क्या है, इसका एक-line description Claude के लिए ऐसी table of contents बन जाता है जिसे वह files खोले बिना scan कर सके
      • अगर top-level folders सैकड़ों में हों, तो root file केवल highest-level structure बताए और subdirectory CLAUDE.md files अगला स्तर on-demand दें — यह layered approach सबसे बेहतर काम करती है
      • सरल मामलों में Claude को जिन specific files या directories का संदर्भ लेना है, उन्हें @ से mention करना भी वही काम कर सकता है

    • string नहीं, symbol के आधार पर search के लिए LSP server का उपयोग करें

      • बड़े codebase में किसी common function name पर grep करने से हज़ारों matches मिल सकते हैं, और Claude महत्वपूर्ण चीज़ पहचानने के लिए files खोलते-खोलते context खर्च कर देता है
      • LSP केवल उसी symbol की references लौटाता है, इसलिए Claude कुछ पढ़ने से पहले ही filtering हो जाती है
      • इसे set up करने के लिए language-specific code intelligence plugin और संबंधित language server binary install करनी होती है
      • Claude Code docs में available plugins और troubleshooting methods शामिल हैं

    • अपवाद

      • layered CLAUDE.md approach के भी कुछ edge cases हैं जहाँ यह टूट सकती है
      • जैसे codebase जिनमें लाखों files और लाखों-करोड़ों folders हों, या legacy systems जो Git के बजाय किसी और version control में हों

  • model intelligence बदलने पर CLAUDE.md files का maintenance

    • जैसे-जैसे model बेहतर होते हैं, वर्तमान model के लिए लिखे गए निर्देश future model के लिए बाधा बन सकते हैं
    • CLAUDE.md rules जो पहले Claude को कठिन patterns समझाने के लिए मदद करते थे, नए model में अनावश्यक या उलटे restrictive हो सकते हैं
    • उदाहरण के लिए, हर refactoring को single-file changes में बाँटने का rule पहले के model के लिए flow बनाए रखने में मददगार रहा हो, लेकिन नया model coordinated multi-file edits अच्छे से कर सकता हो, तब यह rule रुकावट बन जाता है
    • वे skills और hooks जो model reasoning या Claude Code tools की किसी विशेष limitation को compensate करने के लिए बनाए गए थे, limitation हटते ही overhead बन जाते हैं
    • Perforce codebase में p4 edit enforce करने के लिए file writes intercept करने वाला hook, Claude Code में native Perforce mode आने के बाद duplicate हो गया
    • teams को हर 3–6 महीने में meaningful configuration review की अपेक्षा रखनी चाहिए
    • बड़े model release के बाद अगर performance ठहरी हुई लगे, तब भी configuration review करना उपयोगी है

  • Claude Code management और adoption की ownership तय करें

    • केवल technical setup से adoption नहीं होता
    • जिन rollouts ने सबसे तेज़ adoption देखा, उनमें broad access से पहले infrastructure investment किया गया था
    • एक छोटी team, कभी-कभी सिर्फ एक व्यक्ति, tools को जोड़ता था ताकि developers पहली बार Claude इस्तेमाल करते ही उसे अपने workflow के अनुरूप काम करता हुआ पाएँ
    • एक company में कुछ engineers ने पहले दिन से उपयोग योग्य plugin और MCP bundles बनाए
    • दूसरी company में AI coding tools को manage करने वाली dedicated team ने rollout से पहले infrastructure तैयार किया
    • यह काम आमतौर पर developer experience या developer productivity organizations के भीतर आता है, जो new engineer onboarding और developer tooling संभालते हैं
    • कई organizations में Claude Code ecosystem को संभालने के लिए agent manager नाम की hybrid PM/engineer भूमिका उभर रही है
    • अगर dedicated team न हो, तो न्यूनतम व्यवहार्य विकल्प एक DRI है
    • इस DRI के पास Claude Code setup, configuration decisions, permissions policy, plugin marketplace, और CLAUDE.md rules की ownership और उन्हें updated रखने की ज़िम्मेदारी होनी चाहिए
    • bottom-up adoption उत्साह तो बनाती है, लेकिन अगर असरदार चीज़ों को centralize करने वाला कोई न हो, तो यह fragment हो सकती है
    • standardized CLAUDE.md hierarchy या curated skills और plugins जैसी Claude Code practices को इकट्ठा करने और फैलाने के लिए व्यक्ति या team चाहिए
    • इसके बिना knowledge tribal knowledge ही बनी रहती है और adoption रुक जाती है

governance और rollout

  • बड़े organizations, खासकर regulated industries में, governance के सवाल जल्दी सामने आते हैं
  • कौन तय करता है कि कौन-सी skills और plugins इस्तेमाल हो सकती हैं, कैसे सुनिश्चित किया जाए कि हज़ारों engineers एक ही चीज़ स्वतंत्र रूप से दोबारा न बना रहे हों, और AI-generated code भी human-written code जैसी review process से गुज़रे — ये प्रमुख मुद्दे हैं
  • शुरुआत में approved skills का defined set, mandatory code review process, और सीमित initial access से शुरू करके भरोसा बढ़ने पर विस्तार करने वाला approach सुझाया जाता है
  • सबसे smooth deployments उन organizations में देखे गए जहाँ शुरुआत में engineering, infosec, और governance प्रतिनिधियों का cross-functional working group बनाया गया और requirements व rollout roadmap साथ मिलकर तय किए गए

organization में लागू करते समय मान्यताएँ और सीमाएँ

  • Claude Code को ऐसे traditional software engineering environment के लिए design किया गया है जहाँ engineers प्रमुख codebase contributors हों, repository Git इस्तेमाल करती हो, और code standard directory structure का पालन करता हो
  • ज़्यादातर बड़े codebase इस ढाँचे में फिट होते हैं, लेकिन बड़े binary assets वाले game engines, non-traditional version control environments, या ऐसे setups जहाँ non-engineers भी codebase में योगदान देते हों, वहाँ अतिरिक्त setup work चाहिए
  • यहाँ दिए गए patterns traditional setup को ध्यान में रखकर बनाए गए हैं और कई customer environments में काम कर चुके हैं
  • बाकी complexity को हर organization को अपने codebase, tools, और structure के अनुसार समझना होगा
  • Anthropic की Applied AI team ऐसे patterns को organization-specific requirements में बदलने के लिए engineering teams के साथ सीधे काम करती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियाँ

  • “software engineer की तरह” codebase को explore करने वाली बात और निष्कर्ष एक-दूसरे से मेल नहीं खाते लगते हैं
    autocomplete या LSP तो हमेशा इस्तेमाल होते हैं और उपयोगी भी हैं, वह भी एक तरह का index ही नहीं है? यह भी सवाल है कि Claude ऐसा क्यों नहीं इस्तेमाल कर पाता
    software engineer codebase को याद भी रखते हैं, जो असल में RAG के ज़्यादा क़रीब है, और CMD+P autocomplete से ज़रूरी file ढूँढने की muscle memory भी बहुत होती है
    हज़ारों engineers एक साथ बदल रहे पूरे codebase पर real-time होने की ज़रूरत नहीं है, बस मैं जिस branch पर काम कर रहा हूँ उसे ठीक से देखना काफ़ी है
    शुरुआत से file system को घूमते हुए codebase explore करना बहुत कम होता है, आमतौर पर सिर्फ़ नए codebase में, और उस हालत में भी उसे best experience कहना मुश्किल है

    • यह बिल्कुल मेरे काम करने के तरीके जैसा है
      मैंने LSP से पहले के दौर से ही बड़े codebase को explore करना सीखा, और लंबे समय तक vim इस्तेमाल करते हुए grep से relevant files ढूँढीं
      पिछले साल जब पहली बार Claude Code इस्तेमाल किया, तो लगा “अरे, यह तो वही कर रहा है जो मैं करने वाला था”
    • जवाब लेख की शुरुआत में ही है
      Claude Code यह मानकर चल रहा है कि वह लाखों lines वाले monorepo, दशकों पुराने legacy system, और दर्जनों repositories में फैले distributed architecture में चल रहा है
      इसलिए यह general case के लिए optimize किया गया है, यानी ऐसे robust tools के लिए जो हर जगह काम करें, ख़ासकर बड़े और बिखरे हुए codebase में
      लेकिन अगर repository छोटी और अच्छी तरह व्यवस्थित है, तो बेहतर tools इस्तेमाल किए जा सकते हैं और किए जाने चाहिए — यह बात भी सही है
      कम से कम Codex तो ऐसे ही काम करता है, और उदाहरण के लिए grep करने से पहले go doc इस्तेमाल करता है
    • सचमुच बहुत बड़े codebase में grep और find timeout हो जाते हैं
      उस scale पर काम करते हुए जल्दी समझ आ जाता है कि Claude ने search को संभव बनाने के लिए जो tools बनाए हैं, Claude खुद उनका इस्तेमाल नहीं करता
    • छोटे से paragraph में कई भरोसेमंद लगने वाले वाक्य हैं, लेकिन असल में यह इच्छाधारित दावा ज़्यादा लगता है
      “software engineer की तरह” वाली बात सिर्फ़ आंशिक रूप से सही है
      लोग भी symbol search इस्तेमाल करते हैं, लेकिन वे वही symbols ढूँढते हैं जो उन्हें किसी ख़ास task context में याद हों
      अभी Claude Code जिस तरह symbols को अंधाधुंध explore करता है, वह engineer के काम करने के तरीके जैसा नहीं है
      एक typo की वजह से agent यह मान सकता है कि उसे कुछ फिर से implement करना चाहिए, और अगर किस्मत से सही file पढ़ भी ले, तब भी वह आसानी से hallucinate कर सकता है
      बड़े codebase में काम करने का यह तरीका भी नहीं है
      “grep से ठीक वही चीज़ ढूँढ लेते हैं जिसकी ज़रूरत है” वाली बात ख़ास तौर पर खटकती है
      grep करने के लिए पहले यह पता होना चाहिए कि grep क्या करना है, और अगर हज़ारों results आएँ तो सब देखने पड़ते हैं
      ऐसे results आने पर इंसान उन्हें अंधाधुंध स्कैन करने के बजाय output को narrow करने का तरीका सोचता है
      लेख का approach मज़बूत recommendation से ज़्यादा, मौजूदा तरीके को सही ठहराने वाली explanation जैसा लगता है
      “codebase index की ज़रूरत नहीं” यह बात technically सही हो सकती है, लेकिन इसका मतलब बस इतना है कि grep-read-grep से context बढ़ाते हुए कभी न कभी जवाब मिल जाएगा
      यह कुछ वैसा सुनाई देता है जैसे कहना कि “Claude Code की ज़रूरत नहीं, क्योंकि developer वही चीज़ खुद कर सकता है”
      यह “ज़रूरत नहीं” वाला संदेश community तक निर्णय को किसी absolute truth की तरह पहुँचाता है, और मुझे यह ग़लत लगता है
      कुल मिलाकर संगठनात्मक लागतों के बारे में लेख ईमानदार है
      कई संगठनों में “agent manager” जैसा रोल, जो PM और engineer के मिश्रण जैसा है, Claude Code ecosystem को manage करने के लिए उभर रहा है, और यह भी कहा गया है कि teams को हर 3–6 महीने में meaningful configuration review करनी चाहिए
      यह large-scale Claude Code को बिना पहले से बने code-intelligence layer के इस्तेमाल करने की हक़ीक़त को ठीक से दिखाता है
      दिशा सही पकड़ी गई है, लेकिन लेख पढ़कर आख़िर में ऐसा स्वाद रह जाता है कि “हम समस्या हल नहीं कर पाए, और यही हमारी सीमा है”
    • अगर codebase के किसी हिस्से को शुरू से explore भी करना पड़े, तब भी कुछ हिस्से लगभग कभी नहीं बदलते; उन्हें हर बार फिर से explore करना token की बर्बादी है
      Claude से मेरी अक्सर बहस यही होती है कि उसे explore बहुत कम करना चाहिए
      जो चीज़ें लगभग नहीं बदलतीं, उन्हें धीमे और महँगे तरीक़े से scan करने से बेहतर मैं ख़ुद उन्हें जानता हूँ और तेज़ हूँ
      लेकिन वह हर बार उसी तरह के rabbit hole में घुस जाता है

  • एक किस्से के तौर पर, मैं LLM onboarding और orchestration के लिए एक project design कर रहा था, और Claude ने हर file की सिर्फ़ शुरुआती 40 lines पढ़ने का चुनाव किया
    बाद में किसी दूसरे session में low quality की वजह खोजते हुए Claude ने वही defect ढूँढा, और code बदलकर documentation lines और function signatures के input/output को input मानकर AST analysis करने लगा
    Claude का शुरुआती approach वाक़ई बहुत ख़राब था
    इससे यह सवाल उठता है कि Claude Code को अच्छा बनने के लिए कितना ज़्यादा सुधार और review चाहिए, और क्या यह शुरुआत से अच्छा code बना भी सकता है
    सामान्य रूप से देखें तो Claude “पहली 40 lines ही पढ़ना” जैसे local और पहचानने योग्य बुरे फ़ैसले सुधार सकता है
    क्योंकि defect अलग किया जा सकता है और किसी एक code fragment तक trace किया जा सकता है
    लेकिन असली software quality problems अक्सर कई छोटे-छोटे फ़ैसलों से बनती हैं, जो अकेले देखें तो ठीक लगते हैं लेकिन मिलकर बुरा परिणाम देते हैं
    तब उनमें से कोई एक साफ़-साफ़ “defect” नहीं होता, इसलिए ऐसा tool जो low-quality components को टुकड़ों में generate करता है, वह अच्छे code तक converge नहीं कर पाएगा, क्योंकि हर टुकड़ा अलग से देखने पर ठीक-ठाक लगता है

    • ऐसा लगता है कि इसे context बनाए रखने के लिए source code को एक संकरे छेद से झाँककर देखने की ट्रेनिंग दी गई है
      ऐसे मामलों में lower-level logic या पूरा sub-agent बेहतर fit हो सकता है
      उदाहरण के लिए, sub-agent को कहा जाए: “इस file को scan करके summarize करो, और X तथा Y से संबंधित हिस्सों को mark करो, फिर मैं उन्हें main context में देखूँगा”
      या फिर उसे main workflow को समय-समय पर observe करने दिया जाए, ताकि अगर उसे लगे कि जिस file पर वह सोच रहा है उसमें कुछ ऐसा है जो मौजूदा task से जुड़ा है या दिशा बदल सकता है, तो वह बीच में हस्तक्षेप कर सके

  • Claude Code बड़े codebase में कैसे काम करता है? आसान है
    छोटे project में भी पहला prompt ही 5 घंटे की usage limit का 35% खा जाता है, और अगर 5 मिनट के भीतर तेज़ जवाब न मिले तो cache उड़ जाती है, फिर अगले prompt पर फिर से 12–15% देना पड़ता है

    • linked लेख बताता है कि इससे कैसे बचें
      बड़े codebase में इसे भोलेपन से खुला छोड़ दें, तो खोजते समय token बहुत जलना तय है

  • क्या Claude Code codebase inspect करके अपने-आप कोई असरदार harness नहीं बना सकता?
    मैंने CLAUDE.md, AGENTS.md, skills, और plugins define करके देखे, लेकिन दूसरों के बताए जितने फ़ायदे नहीं मिले
    उदाहरण के लिए, LSP plugin होने पर भी Claude Code LSP का symbol rename इस्तेमाल नहीं करता, बल्कि files को एक-एक करके धीमे-धीमे बदलता है; या prompt में साफ़ लिखा हो कि किसी ख़ास clue पर skill call करनी है, तब भी वह call नहीं करता
    क्या मैं इसे ग़लत इस्तेमाल कर रहा हूँ? कोई मज़बूत harness example है जिसे copy karke इस्तेमाल किया जा सके?

    • यह कई सालों से चला आ रहा pain point है और अब तक बिल्कुल हल नहीं हुआ
      “अगर A हो तो X करो. B, C, D करो. A करो” कहने पर भी वह X नहीं करता
      वजह है कि वह “भूल जाता है”
      rules बनाने में लगाया गया समय सचमुच return देगा या नहीं, इस पर भरोसा नहीं होता; उल्टा यह भरोसा ज़्यादा होता है कि कभी न कभी fail ज़रूर करेगा
      RAG, harness, और skills — सबने कहा था कि वे इसे ठीक करेंगे, लेकिन व्यवहार में वे ऐसा नहीं कर पाए
    • मैंने /init का इस्तेमाल और codebase समझाने वाली CLAUDE.md या AGENTS.md files रखना छोड़ दिया
      अब सिर्फ़ codebase explore करने का तरीका और investigation करते समय git log इस्तेमाल करने की बात छोड़ी है, लेकिन यह भी शायद दोहराव ही हो
      मुझे भी जवाब नहीं पता
      जिस codebase पर मैं काम कर रहा हूँ वह लगभग 1 लाख lines का है; पता नहीं इसे बड़ा माना जाएगा या नहीं, लेकिन व्यक्तिगत रूप से यह मेरे काम किए हुए repositories में सबसे बड़ा है
    • कुछ मामलों में scripts लगे हुए hooks context window में जानकारी डालने के लिए असरदार लगे हैं
      context सीमित रखने के लिए मुझे कुछ अनावश्यक linter messages हटाने पड़े
      ऐसे linters या language-specific checkers भी मददगार हैं जिन्हें OS package repository से install करके scripts में call किया जा सके
      model और skill context का संयोजन भी फ़र्क़ डाल सकता है
      जो skill 4.6 में “काम कर रही थी”, वह 4.7 में उतनी फिट न बैठे; 4.7 को ज़्यादा explicit निर्देश चाहिए, लेकिन वह 4.6 से तुलनात्मक रूप से ज़्यादा stable है
      skill update करना भी मदद कर सकता है, और पहले व बाद में tests व runs की तुलना करनी चाहिए
      Claude Code अनावश्यक tool calls को भी context में डाल देता है, इसलिए अगर आपको beads पसंद हैं, तो हो सकता है आपको task को रोककर सीमित करना पड़े

  • codebase indexing के ख़िलाफ़ किए गए दावे से मैं सहमत नहीं हूँ
    PHPStorm या दूसरे JetBrains IDEs में indexing काफ़ी अच्छी तरह काम करती है

    • PHPStorm indexing शानदार है
      बहुत कम मामलों में यह corrupt हुई, लेकिन उसे आसानी से ठीक किया जा सका, और मुझे कभी stale results नहीं मिले
      अगर आपने Claude के search tools इस्तेमाल किए हैं, तो आपको यह जानकर हैरानी नहीं होगी कि उस team को indexing के बारे में कुछ पता नहीं है
      यह समझना मुश्किल है कि एक ऐसी company जिसका मुख्य product text-based chat है, वही users के लिए उस chat में text search आसान क्यों नहीं बनाती
    • Claude Code JetBrains के MCP का इस्तेमाल करके वह index इस्तेमाल कर सकता है
    • यह अजीब दावा है
      क्या यह AI-generated कचरा लेख है? GitHub Copilot के पास भी काफ़ी अच्छा local index है
      code को vector database में डालना इतना मुश्किल problem नहीं है

  • यह लेख साफ़ तौर पर Claude ने लिखा है
    इसमें फ़ालतू verbosity बहुत है और ठोस substance कम

  • यह कहना अजीब है कि इसमें C, C++, C#, Java, PHP जैसी भाषाएँ भी शामिल हैं, जिन्हें teams हमेशा AI coding tools से जोड़कर नहीं सोचतीं
    क्यों यह मानना चाहिए कि Claude Code ऐसी भाषाओं में अच्छा काम नहीं करेगा? फिर किन भाषाओं की कल्पना की जा रही है — Python और JavaScript?

  • ऐसे industry में जहाँ खेल कुछ हफ़्तों नहीं बल्कि कुछ महीनों में बदल जाता है, यह दिलचस्प है कि स्पष्ट pattern उभरने लायक काफ़ी समय भी बीत गया और वह pattern बड़े codebase में सफल भी रहा
    success criteria क्या है? यह कि production database delete नहीं हुई, या team की speed बढ़ी, या codebase की उम्र बढ़ी, या ops team ज़्यादा खुश हुई?

    • अगर AI tool की वजह से production database उड़ गई, तो मैं यही कहता रहूँगा कि वह आपकी और आपकी organization की failure है कि आपने developers को production resources delete करने जैसी production permissions दे रखी थीं
      मैंने कभी ऐसी company में काम नहीं किया जहाँ इतनी खुली और असीम access दी गई हो

  • आजकल मेरा सारा stress इस बात से आता है कि Claude Code instructions follow नहीं करता, और codebase जितना बड़ा होता गया, यह उतना बुरा होता गया
    ग़लत न समझें, Claude कमाल का है और मुझे पसंद है
    लेकिन Claude Code को अकेले hire करके codebase maintain करवाना या features जोड़वाना बिल्कुल संभव नहीं है
    मैं इसकी memory entries में पुरानी ग़लतियों के नोट लगातार जोड़ता रहता हूँ, लेकिन महत्वपूर्ण निर्देशों को ignore करने की समस्या अब भी लगभग 90% संभावना से होती है
    इससे बचने का एक ही तरीका है: हर काम के दौरान उसके बगल में खड़े रहना और नतीजों की बहुत गहराई से समीक्षा करना
    documentation या बड़े codebase को समझने में Claude Code शानदार है, लेकिन ऐसे बदलावों में कमज़ोर है जहाँ पूरी तस्वीर समझनी पड़ती है
    उदाहरण के लिए, पूरे codebase में कई entities के लिए इस्तेमाल होने वाले लगभग 10 registry patterns हैं, और साफ़ नियम था कि “यही एक registry pattern इस्तेमाल करो”, फिर भी Claude Code ने हर entity के लिए अलग-अलग 4 independent registries implement कर दीं
    इस साधारण काम को सही करवाने के लिए मैंने आधा दिन लगभग Claude Code पर चिल्लाते हुए बिताया, और आख़िर में stress और समय बचाने के लिए ख़ुद ही ठीक कर दिया

  • अगर यह ठीक-ठीक specific terms में बताता ही नहीं कि हर CLAUDE.md file में क्या होना चाहिए, तो मुझे समझ नहीं आता कि ऐसी files कितनी महत्वपूर्ण हैं

    • मछली: यहाँ पढ़ सकते हैं https://code.claude.com/docs/en/best-practices#write-an-effe...
      मछली पकड़ना: 1) आधिकारिक skill-creator install करें 2) ऊपर दिए गए link का उपयोग करके claude-md-improver बनाएँ 3) आधिकारिक documentation से progressive-disclosure विषय पर research करवाकर skill सुधारें 4) नई skill को CLAUDE.md file पर apply करें और changes स्वीकार करें