Claude Code सर्वोत्तम प्रथाएँ: योजना, कॉन्टेक्स्ट ट्रांसफ़र, TDD

Claude Code एक ऐसे अनुशासन को पुरस्कृत करता है जिसकी मांग ज़्यादातर डेवलपर टूल नहीं करते। यदि आप इसे कुछ समय से उपयोग कर रहे हैं, तो आपने देखा होगा कि कुछ सत्र वही देते हैं जो आप चाहते हैं, जबकि अन्य टोकन जला कर भी कहीं नहीं पहुँचते। Anthropic की अपनी टीम ने पाया कि बिना मार्गदर्शन के प्रयास लगभग 33% समय सफल होते हैं, और टूल के निर्माता 10-20% सत्रों को छोड़ देते हैं। 

अंतर उन पैटर्न में है जो आप टूल के चारों ओर लगाते हैं, न कि उन प्रॉम्प्ट्स में जो आप टाइप करते हैं।

यह लेख बताता है कि व्यवहार में वे पैटर्न कैसे दिखते हैं—Abnormal AI, incident.io और Trail of Bits जैसी कंपनियों के प्रोडक्शन वर्कफ़्लो से लिए गए उदाहरणों के साथ। 

यदि आपको सेटअप और मुख्य फ़ीचर्स पर रीफ़्रेशर चाहिए, तो हमारा Claude Code 2.1 गाइड आपके काम आएगा। यहाँ की हर चीज़ यह मानकर चलती है कि आप मूल बातें जानते हैं और टूल से अधिक निकालना चाहते हैं।

एजेंट्स कैसे तर्क करते हैं और इस ट्यूटोरियल के पैटर्न कहाँ फ़िट होते हैं, इस पर व्यापक नज़र के लिए, मैं हमारे AI Agent Fundamentals ट्रैक में नामांकन की अत्यधिक सिफ़ारिश करता हूँ, जो सभी आधारभूत सिद्धांतों को कवर करता है।

योजना का अनुशासन सब कुछ क्यों बदल देता है

बिना मार्गदर्शन के Claude द्वारा लिया गया हर निर्णय उच्च सटीकता का हो सकता है—जो एकल विकल्प के लिए ठीक लगता है—पर जब किसी फ़ीचर में अनेक निर्णय बिंदुओं पर यह दोहराया जाता है, तो सब कुछ सही होने की संभावना घटती जाती है। यदि आप 20 निर्णयों के लिए 80% सटीकता मानें, तो 0.8^20 मिलता है—यानि पूरे फ़ीचर का पूरी तरह सही इम्प्लिमेंटेशन होने की संभावना लगभग 1%।

योजना उन 20 अस्पष्ट निर्णयों को एक रिव्यू किए गए स्पेसिफ़िकेशन में समेट देती है, जहाँ प्रत्येक लगभग 100% के क़रीब पहुँचता है, क्योंकि आप पहले ही फ़ैसला कर चुके होते हैं।

एनोटेशन साइकिल वर्कफ़्लो के साथ योजना बनाना

स्केल पर जो प्लानिंग वर्कफ़्लो सबसे बेहतर काम करता है, वह है एनोटेशन साइकिल, जैसा कि Boris Tane सुझाव देते हैं। आप Claude से एक plan.md ड्राफ्ट कराते हैं, उसे अपने एडिटर में खोलते हैं, और जहाँ-जहाँ Claude ने गलत फ़ैसला किया हो या कुछ अस्पष्ट छोड़ा हो, वहाँ इनलाइन नोट्स जोड़ते हैं: "drizzle:generate उपयोग करें, रॉ SQL नहीं" या "यह PATCH होना चाहिए, PUT नहीं।" 

फिर आप एनोटेटेड प्लान को इस गार्ड वाक्य के साथ वापस भेजते हैं: "address all notes, don't implement yet." यह गार्ड वाक्य महत्वपूर्ण है, क्योंकि इसके बिना Claude प्लान को छोड़कर तुरंत कोड लिखना शुरू कर देता है। यह चक्र तब तक दोहराएँ जब तक प्लान में कोई अस्पष्टता न रह जाए—उस बिंदु पर Claude बहुत कम गलत मोड़ों के साथ इम्प्लिमेंट करता है, क्योंकि हर निर्णय पहले से लिया जा चुका होता है।

# plan.md — annotation cycle
 
## Step 3: Database migration
Create a new migration for the users table.
> NOTE: use drizzle:generate, not raw SQL
> NOTE: add created_at with default NOW()
 
## Step 4: API endpoint
Add PUT /users/:id endpoint.
> NOTE: this should be PATCH, not PUT. Partial updates only.
 
# After annotating, send back with:
# "address all notes, don't implement yet"

Claude Code प्लान मोड का उपयोग

यदि एनोटेशन साइकिल भारी लगती है, तो Claude Code का बिल्ट-इन प्लान मोड हल्का विकल्प है: 

1. Shift+Tab दो बार दबाएँ।
2. बातचीत में प्लान पर इटरेट करें।
3. Shift+Tab एक बार दबाकर ऑटो-एक्सेप्ट पर स्विच करें। 

प्लान ~/.claude/plans/ में सहेजे जाते हैं, इसलिए वे कॉम्पैक्शन और सत्र रिस्टार्ट्स के बाद भी रहते हैं—अधिकांश कार्यों के लिए बिल्ट-इन प्लान मोड एक बढ़िया डिफ़ॉल्ट है। बहुत बड़े फ़ीचर्स के लिए, पहले से पूर्ण स्पेस लिखना भी अच्छा काम करता है: एक डेवलपर ने 12-स्टेप स्पेस पर दो घंटे लगाए और अनुमानित 6-10 घंटे के इम्प्लिमेंटेशन समय की बचत की। 

प्लानिंग को और आगे ले जाना

किसी भी तरीके में, प्लान रिक्वेस्ट के साथ अच्छा ओपन-सोर्स कोड पेस्ट करना आउटपुट को स्पष्ट रूप से बेहतर बनाता है, क्योंकि Claude अमूर्त विवरणों की तुलना में काम कर रहे संदर्भ के साथ बेहतर कार्य करता है।

प्लानिंग git worktrees के ज़रिए क्षैतिज रूप से भी स्केल होती है। incident.io के इंजीनियर अलग-अलग ब्रांचों पर 4-5 समानांतर Claude सत्र चलाते हैं, प्रत्येक अपने प्लान पर काम करता है। एक इंजीनियर ने $8 के Claude क्रेडिट में एक ऐसा इम्प्लिमेंटेशन बनाया जिसने API जेनरेशन समय में 18% सुधार किया—एक ऐसे टूल पर 30 सेकंड की बचत, जिसका पूरी टीम रोज़ाना उपयोग करती थी। 

कुछ डेवलपर इसे और आगे ले जाते हैं—एक ही समस्या के लिए अलग-अलग तरीकों को इम्प्लिमेंट करने वाले प्रतिस्पर्धी worktrees चलाकर नतीजों की तुलना करते हैं।

CLAUDE.md आर्किटेक्चर की सर्वोत्तम प्रथाएँ

आपकी CLAUDE.md फ़ाइल का एक बजट होता है, जिसके बारे में आप शायद नहीं जानते। HumanLayer के Claude Code इंटरनल्स के विश्लेषण में पाया गया कि सिस्टम आपकी निर्देशों के ऊपर एक रिमाइंडर इंजेक्ट करता है: "This context may or may not be relevant to your tasks." 

Claude Code की परतदार निर्देश प्रणाली को समझना

Claude हर चीज़ को स्थायी कमांड की तरह मानने के बजाय सक्रिय रूप से फ़िल्टर करता है कि क्या फ़ॉलो करना है। इसके ऊपर, फ़्रंटियर थिंकिंग मॉडल लगभग 150-200 निर्देशों तक अच्छे से फ़ॉलो करते हैं—उसके बाद अनुपालन घटता है—और Claude Code का अपना सिस्टम प्रॉम्प्ट उनमें से लगभग 50 ले लेता है। इससे आपके नियमों के लिए लगभग 100-150 स्लॉट बचते हैं। HumanLayer अपनी फ़ाइल 60 पंक्तियों से कम रखता है।

आप इस बजट को क्रियान्वयन में देख सकते हैं। अपनी CLAUDE.md में एक पंक्ति जोड़ें: "always address me as Mr. Tinkleberry" और देखें Claude इसे कितनी जल्दी छोड़ देता है—आम तौर पर कुछ हज़ार टोकन के भीतर। जब नाम गायब हो जाए, समझ लें कि आपकी निर्देशों को अटेंशन मैकेनिज़्म द्वारा कम प्राथमिकता दी जा रही है—और आपकी CLAUDE.md की बाकी बातें भी उसी के साथ प्रभाव खोती हैं।

निर्देश संदर्भों के लिए प्रोग्रेसिव डिस्क्लोज़र का उपयोग

इस बजट के भीतर काम करने का तरीका है प्रोग्रेसिव डिस्क्लोज़र। आपकी रूट CLAUDE.md संक्षिप्त रहे और हर जगह लागू होने वाले नियमों पर केंद्रित हो। डोमेन-विशिष्ट किसी भी चीज़ के लिए, अलग फ़ाइल का संदर्भ दें, उसे इनलाइन न करें: "पेमेंट सिस्टम पर काम करते समय, पहले docs/payment-architecture.md पढ़ें।" 

Claude केवल तभी संदर्भित फ़ाइल पढ़ता है जब वह कोडबेस के उस हिस्से में प्रवेश करता है, जिससे आपका निर्देश बजट उच्च-प्राथमिकता नियमों के लिए मुक्त रहता है। एक कंपनी जो प्रति माह अरबों टोकन खपत करती है, अपनी मोनोरिपो CLAUDE.md को इसी तरह स्ट्रक्चर करती है—हर टीम को उनके सेक्शन के लिए टोकन बजट आवंटित होता है:

# Monorepo CLAUDE.md — progressive disclosure
 
## Python
- Always use type hints for function signatures
- Test with: pytest -x --tb=short
 
## <Internal CLI Tool>
- <usage example>
- Always validate input before processing
- Never use raw SQL, prefer the ORM
For <complex usage> or <error> see path/to/<tool>_docs.md

सबडायरेक्टरी CLAUDE.md फ़ाइलें इसे और आगे बढ़ाती हैं। src/persistence/ में डेटाबेस-विशिष्ट निर्देशों वाली एक CLAUDE.md रखें, और src/api/ में एन्डपॉइंट कंवेंशन्स वाली दूसरी। 

Claude वर्किंग डायरेक्टरी से प्रोजेक्ट रूट तक की CLAUDE.md फ़ाइलें ऑटोमैटिक रूप से लोड करता है, इसलिए सबडायरेक्टरी फ़ाइलें केवल तब सक्रिय होती हैं जब Claude उस क्षेत्र में काम कर रहा हो। इससे आपकी रूट फ़ाइल सामान्य रहती है, जबकि Claude को जहाँ आवश्यक हो वहीं लक्षित मार्गदर्शन मिलता है।

एक आम गलती: डॉक्यूमेंटेशन फ़ाइलों को @ के साथ CLAUDE.md में न जोड़ें। इससे हर रन पर पूरी फ़ाइल एम्बेड हो जाती है और बातचीत शुरू होने से पहले ही आपका निर्देश बजट खप जाता है।

Claude Code में कॉन्टेक्स्ट प्रबंधन

Claude Code आपको 200K टोकन का कॉन्टेक्स्ट देता है, लेकिन उपयोगी विंडो दिखने से छोटी है। 

नया मोनोरिपो सत्र लगभग 20K टोकन जला देता है—सिस्टम प्रॉम्प्ट, टूल परिभाषाएँ और CLAUDE.md लोड करने में—इससे पहले कि आपने कुछ टाइप भी किया हो। हर MCP सर्वर ऐसे टूल स्कीमा जोड़ता है जो स्थायी रूप से कॉन्टेक्स्ट खपत करते हैं, इसलिए 5-8 सर्वरों के बाद आप वास्तविक काम के लिए जगह घेरने लगते हैं।

मामला इस वजह से और बिगड़ता है कि गुणवत्ता बहुत पहले गिरने लगती है। कई प्रैक्टिशनर्स स्वतंत्र रूप से एक ही थ्रेशहोल्ड पर पहुँचे हैं: कॉन्टेक्स्ट को 60% क्षमता से अधिक न जाने दें। 

Claude का आउटपुट विंडो के 20-40% पर ही गिरने लगता है—किसी सीमा के लगने से बहुत पहले—क्योंकि जैसे-जैसे कॉन्टेक्स्ट भरता है, अटेंशन मैकेनिज़्म पहले के निर्देशों को कम वज़न देता है। 

ऑटो-कॉम्पैक्शन लगभग 83.5% पर ट्रिगर होता है और यह लॉसी है: एक डेवलपर ने 3 घंटे का रिफैक्टरिंग काम खो दिया जब इसने सत्र के बीच में माइग्रेशन फ़ैसलों का सारा ज्ञान मिटा दिया—लगभग 20-30% विवरण ही बचा।

डॉक्यूमेंट एंड क्लियर पैटर्न का उपयोग

सबसे अच्छा बचाव है Document & Clear पैटर्न। जब कॉन्टेक्स्ट भारी हो जाए: 

1. अपनी वर्तमान योजना और प्रगति को एक मार्कडाउन फ़ाइल में डंप करें

2. सत्र रीसेट करने के लिए /clear चलाएँ

3. उस फ़ाइल को पढ़वाकर Claude के साथ नया सत्र शुरू करें

इस तरह, आपको पूरे 200K की विंडो केवल उसी सामग्री के साथ मिलती है जिसे आप सुरक्षित रखना चुनते हैं—जो /compact से बेहतर है, क्योंकि आप तय करते हैं कि क्या बचे। 

एक कस्टम /catchup कमांड ट्रांज़िशन को और स्मूथ बनाता है: क्लियर करने के बाद यह वर्तमान git ब्रांच में बदली गई सभी फ़ाइलें पढ़ता है, ताकि पुरानी बातचीत का इतिहास लिए बिना ही Claude वहीं से आगे बढ़ सके जहाँ आप थे।

<!-- .claude/commands/catchup.md -->
Rebuild context after a /clear. Read all files modified on the
current branch compared to main. For each file, understand the
changes made. Then summarize what's been implemented so far and
what work remains.
 
Changed files on this branch:
$ git diff --name-only main

कस्टम Claude Code स्किल्स के साथ कॉन्टेक्स्ट ट्रांसफ़र करना

मैं एक /transfer-context स्किल उपयोग करता/करती हूँ जो इसे और आगे ले जाता है। जब कोई सत्र बिगड़ने लगता है, तो यह कमांड पूर्ण किए गए कार्य, खुले निर्णय, बचने योग्य जाल, और प्रासंगिक फ़ाइल पथों के साथ एक संरचित हैंडऑफ़ फ़ाइल डंप करता है। अगला सत्र उस फ़ाइल को पढ़ता है और पिछली जगह से वहीं से आगे बढ़ता है—केवल आवश्यक जानकारी के साथ, बिना बातचीत के फालतू बोझ के।

कॉन्टेक्स्ट बचाने की अन्य सर्वोत्तम प्रथाएँ

आप टूल्स को लेज़ी-लोड करके भी कॉन्टेक्स्ट पहले से बचा सकते हैं। एक प्रोजेक्ट ने UserPromptSubmit हुक्स का उपयोग करके प्रत्येक सत्र में लगभग 15,000 टोकन रिकवर किए—यूज़र के प्रॉम्प्ट में प्रासंगिक कीवर्ड आने पर ही स्किल डिफ़िनिशन इंजेक्ट किए, स्टार्टअप पर सब कुछ प्रीलोड नहीं किया।

इस सबके नीचे सबसे सरल नियम: एक बातचीत में एक ही कार्य। नया सत्र शुरू करने की कीमत 20K टोकन है, जो प्रदूषित सत्र से होने वाले गुणवत्ता नुकसान की तुलना में कुछ भी नहीं।

निर्धारित गार्डरेल्स के रूप में Claude Code Hooks

अच्छी तरह संरचित CLAUDE.md भी केवल लगभग 70% बार ही फ़ॉलो होती है। कोडिंग स्टाइल प्राथमिकताओं के लिए यह ठीक है। पर "main पर पुश न करें" या "प्रोडक्शन डेटा न मिटाएँ" जैसी सुरक्षा नियमों के लिए नहीं। Hooks उस खाई को 100% तक पाटते हैं—Claude के वर्कफ़्लो के विशेष बिंदुओं पर शेल स्क्रिप्ट्स चलाकर।

दो प्रकार जानना काफ़ी है। Block-at-Submit हुक्स PreToolUse इवेंट के रूप में चलते हैं और कार्रवाइयों को यहीं रोक देते हैं: एग्ज़िट कोड 2 एक्शन ब्लॉक कर देता है और Claude को कुछ और आज़माने के लिए बाध्य करता है। Hint हुक्स नॉन-ब्लॉकिंग फ़ीडबैक देते हैं, जैसे हर एडिट के बाद लिंटर चलाना और आउटपुट को Claude के फ़्लो को बाधित किए बिना वापस फ़ीड करना।

सबसे विस्तृत पब्लिक हुक कॉन्फ़िगरेशन ये काम करता है:

• rm -rf कमांड्स को ब्लॉक करता है (trash सुझाता है), 

• main पर डायरेक्ट पुश रोकता है, 

• सभी म्यूटेशन्स को टाइमस्टैम्प के साथ लॉग करता है, और 

• एंटी-रैशनलाइज़ेशन गेट चलाता है। 

यह गेट Haiku का उपयोग करता है ताकि Claude की प्रतिक्रियाओं में "pre-existing issues" या "out of scope" जैसे बहाने ढूंढे जा सकें। जब यह Claude को अकाल विजय की घोषणा करते पकड़ता है, तो यह प्रतिक्रिया को विशिष्ट फ़ीडबैक के साथ रिजेक्ट करता है और Claude को काम जारी रखने के लिए बाध्य करता है। हल्का सेटअप हर फ़ाइल एडिट के बाद Prettier और TypeScript चेक्स ऑटो-रन कराता है:

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{
        	"type": "command",
        	"command": "prettier --write \"$CLAUDE_FILE_PATHS\""
      	}
    	]
  	}
	]
  }
}

एक जाल जिससे बचें: कभी भी Edit या Write टूल्स को प्लान के बीच में ब्लॉक न करें। राइट टाइम पर ब्लॉक करना मल्टी-स्टेप तर्क को तोड़ देता है क्योंकि Claude ट्रैक खो देता है। इसे लिखना पूरा करने दें, फिर PostToolUse हुक्स या प्री-कमिट चेक्स के ज़रिए वैलिडेट करें। हमारा Claude Code हुक्स ट्यूटोरियल इनसे आगे के और पैटर्न कवर करता है।

एजेंटिक कोडिंग के लिए सर्वोत्तम रणनीति के रूप में टेस्ट-ड्रिवन डेवलपमेंट

बिना टेस्ट के, Claude अपने काम की जाँच केवल अपने ही निर्णय से कर सकता है—जो कॉन्टेक्स्ट भरने के साथ घटता जाता है। टेस्ट एक बाहरी ओरेकल बनाते हैं जो सत्र कितने भी लंबे चलें, सटीक बना रहता है। 

हर रेड-टू-ग्रीन साइकिल Claude को असंदिग्ध फ़ीडबैक देती है—और यह बिना मानव हस्तक्षेप के पूरी सूट पर इटरेट कर सकता है—जिससे टेस्ट-ड्रिवन डेवलपमेंट (TDD) एजेंटिक कोडिंग टूल्स के साथ काम करने का सबसे मज़बूत पैटर्न बन जाता है।

वह वर्कफ़्लो जिसे Anthropic अनुशंसा करता है एक विशिष्ट क्रम का पालन करता है:

1. Write tests first
   > "Write tests for the auth module using pytest.
  	TDD approach, no mock implementations."
 
2. Confirm tests fail
   > "Run the tests. They should all fail."
 
3. Commit the failing tests as a checkpoint
 
4. Implement until green
   > "Write the implementation. Do not modify the tests.
  	Keep going until all tests pass."

आख़िरी निर्देश दिखने से ज़्यादा मायने रखता है। Claude कभी-कभी इम्प्लिमेंटेशन ठीक करने के बजाय टेस्ट ही बदल देता है ताकि वे पास हो जाएँ। पहले से टेस्ट कमिट कर देने से आपके पास सेफ़्टी नेट रहता है: यदि Claude उन्हें बदलता है, तो डिफ़ में ठीक-ठीक दिखेगा कि क्या बदला—और आप रिवर्ट कर सकते हैं।

फ़्रंटएंड कार्य के लिए, इस लूप का विज़ुअल वेरिएंट अच्छा काम करता है: यदि आप Claude को एक डिज़ाइन मॉक और Puppeteer MCP सर्वर दें, तो यह इम्प्लिमेंटेशन के बाद स्क्रीनशॉट लेता है, मॉक से तुलना करता है और इटरेट करता है। जब Claude अपने आउटपुट को विज़ुअल लक्ष्य के साथ जाँच सकता है, तो यह वैरिफ़िकेशन लूप गुणवत्ता में 2-3x सुधार लाता है।

Claude Code लागत अर्थशास्त्र और मॉडल चयन

Anthropic के आधिकारिक आँकड़ों के अनुसार API प्राइसिंग पर Claude Code की औसत लागत प्रति डेवलपर प्रति दिन $6 है, और 90% डेवलपर $12/दिन से कम रहते हैं। मासिक रूप से, यह Sonnet 4.6 पर प्रति डेवलपर लगभग $100-200 बैठता है।

Max सब्सक्रिप्शन प्लान गणित को पूरी तरह बदल देता है। एक डेवलपर ने लगभग 10 बिलियन टोकन के 8 माह के उपयोग को ट्रैक किया और पाया कि API-समतुल्य लागत $15,000 से अधिक होती, जबकि वास्तविक Max सदस्यता लागत लगभग $800 रही—93% की बचत। 

उसके 90% से अधिक टोकन कैश रीड्स थे—इसीलिए मीटर्ड API प्राइसिंग फ़्लैट सब्सक्रिप्शन की तुलना में कहीं अधिक महँगी पड़ती है। Max प्लान का ब्रेकईवन पॉइंट API-समतुल्य उपयोग में लगभग $100-200/माह पर बैठता है—जिसे कोई भी दैनिक उपयोगकर्ता जल्दी पार कर लेता है।

मॉडल चयन स्वयं एक ऑप्टिमाइज़ेशन है। Claude Code का "opusplan" मोड प्लानिंग के लिए Opus 4.6 पर रूट करता है और कोड जेनरेशन के लिए ऑटो-स्विच होकर Sonnet 4.6 पर चला जाता है—जहाँ सबसे अधिक ज़रूरत है वहाँ Opus-स्तरीय रीज़निंग मिलती है, जबकि इम्प्लिमेंटेशन टोकन के लिए Sonnet की 5x सस्ती दरें उपयोग होती हैं। 

Anthropic की आंतरिक टेस्टिंग में 59% Claude Code उपयोगकर्ताओं ने Sonnet 4.6 को Opus 4.5 पर तरजीह दी—यह आम तौर पर कम ओवर-इंजीनियरिंग के साथ अधिक साफ़ कोड देता है। सबएजेंट-प्रधान वर्कफ़्लो के लिए, CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-5-20250929" सबएजेंट्स को Sonnet पर चलाता है जबकि ऑर्केस्ट्रेटर के लिए Opus बरक़रार रखता है।

सुनिश्चित करें कि बर्बाद टोकनों के तीन सबसे बड़े स्रोतों से बचें: 

• कार्यों के बीच कॉन्टेक्स्ट क्लियर न करना 

• ख़राब CLAUDE.md संरचना से होने वाले अनावश्यक फ़ाइल रीड्स

• धुँधले प्रॉम्प्ट्स जो Claude को ट्रायल-एंड-एरर लूप्स में भेज देते हैं

सिर्फ़ इन्हें ठीक करने से टोकन उपयोग सामान्यतः आधा हो जाता है।

Claude Code समस्या निवारण

समाप्त करने से पहले, आइए देखें कि डेवलपर्स Claude Code के साथ काम करते समय किन आम समस्याओं का सामना करते हैं और उन्हें कैसे सुलझाएँ।

कॉन्टेक्स्ट लॉस

सबसे कठिन मार करने वाला फेल्योर मोड है कॉन्टेक्स्ट लॉस। कॉन्टेक्स्ट मैनेजमेंट सेक्शन में बताए गए Document & Clear पैटर्न का अस्तित्व इसी कारण है: कभी भी लंबे सत्र को आपके निर्णयों का एकमात्र रिकॉर्ड मत बनने दें। बार-बार कमिट करें, प्रगति को फ़ाइलों में डंप करें, और हर सत्र को डिस्पोज़ेबल मानें।

निश टेक्नोलॉजीज़ के साथ काम करते समय हॉल्युसीनेशन

Claude उन तकनीकों के लिए भी आत्मविश्वास से भरा, विश्वसनीय दिखने वाला कोड जेनरेट कर देता है जिन्हें वह अच्छी तरह नहीं जानता। यदि आप ऐसी भाषा या फ़्रेमवर्क में काम कर रहे हैं जिसे आप स्वयं सत्यापित नहीं कर सकते, तो हर आउटपुट को अतिरिक्त जाँच की ज़रूरत है। एक डेवलपर के शब्दों में: "अनजान तकनीकों के साथ LLMs का उपयोग करके मैंने खुद को बड़ी मुसीबत में डाल लिया था। लेकिन जिनसे मैं परिचित हूँ, उनमें LLMs ने मेरी रफ़्तार ज़बरदस्त बढ़ा दी है।"

ओवर-इंजीनियरिंग

ओवर-इंजीनियरिंग एक आम प्रवृत्ति है। Claude अतिरिक्त एब्स्ट्रैक्शन्स, बिना माँगे हेल्पर फ़ंक्शंस, और समय से पहले रिफैक्टरिंग लिख देता है जब तक आप उसे मना न करें। अपनी CLAUDE.md में "सबसे सरल संभव अप्रोच अपनाएँ" जोड़ना मददगार होता है, और तकनीकी लेयर्स के बजाय समस्या डोमेन के आधार पर कोडबेस को व्यवस्थित करना Claude और मनुष्यों दोनों के लिए संज्ञानात्मक बोझ घटाता है।

महत्वपूर्ण डेटा का नुकसान

अब तक का सबसे नाटकीय फेल्योर: एक फ़ोनिक्स ऐप बनाते समय, Claude ने हर फ़ोनीम ऑडियो फ़ाइल डिलीट कर दी—जिनके उपयोग के लिए एक डेवलपर ने व्यक्तिगत अनुमति ली थी—और उन्हें AI-जनित ध्वनियों से बदल दिया। इसने फ़ाइलों का नाम बदला, और "यह आश्वस्त हो गया कि उसने गलत लेबलिंग की थी, जबकि स्वयं प्रासंगिक फ़ोनीम्स में भेद करने में सक्षम नहीं था।" 

सीखा गया सबक: Claude को एक्सेस देने से पहले हमेशा अपूरणीय फ़ाइलों को कमिट या बैकअप करें।

अनुत्पादक सत्र

बिगड़ते सत्रों के लिए Anthropic की अपनी सलाह काबिले-तारीफ़ ईमानदार है: Claude को काम पर लगाने से पहले अपनी स्थिति सेव करें, उसे चलने दें, फिर या तो परिणाम स्वीकार करें या सुधारों से जूझने के बजाय नया शुरू करें। 

कमिट्स के साथ Claude पर कितना भरोसा करें, यह आपके टेस्ट कवरेज और जोखिम सहनशीलता पर निर्भर करता है। कुछ डेवलपर रोज़ाना दर्जनों बार स्लैश कमांड के ज़रिए कमिट करते हैं—PR रिव्यू को गेट रखते हुए। पेड यूज़र्स वाले प्रोडक्शन कोडबेस के लिए, हर डिफ़ की समीक्षा करना अतिरिक्त झंझट के क़ाबिल है।

Claude Code के साथ हाथ गंदे करें

विस्तार से जानकारी के लिए, Anthropic का Claude Code ओवरव्यू उनका आधिकारिक अपस्ट्रीम स्रोत है, जिस पर अधिकांश कम्युनिटी सामग्री आधारित है। यदि आप यहाँ कवर की हुई बातों पर आगे बढ़ना चाहते हैं और Claude Code की कई विशेषताओं का अनुभव करना चाहते हैं, तो हमारे ये ट्यूटोरियल पढ़ने लायक हैं:

• Claude Code 2.1 गाइड — संस्करण 2.1 में नया क्या है देखें, Claude Code सेटअप करें, और केंद्रित प्रयोगों का सेट चलाएँ
• Claude Code हुक्स ट्यूटोरियल — हुक-आधारित ऑटोमेशन में गहराई से जाएँ और टेस्टिंग, फ़ॉर्मैटिंग, और नोटिफ़िकेशन्स जैसे कार्यों के लिए उनका उपयोग करना सीखें
• Ollama लोकल मॉडल्स के साथ Claude Code का उपयोग — वेंडर लॉक-इन और क्लाउड को डेटा ट्रांसफ़र से बचने के लिए Claude Code और Ollama के साथ लोकल रूप से GLM 4.7 Flash चलाएँ
• Claude Code प्लगइन्स कैसे बनाएं — एक्सटेंशन्स इंस्टॉल करना, स्किल्स और MCPs के बीच चयन करना, और कस्टम सेशन लॉगर प्लगइन बनाना सीखें
• Claude Code Docker — आइसोलेटेड एनवायरनमेंट्स बनाने के लिए Docker में Claude Code चलाना सीखें, और AI एजेंट्स के लिए सुरक्षित कोडिंग प्रथाएँ सीखें
• Claude Code Router — कई मॉडल प्रदाताओं से कनेक्ट करने और हर कार्य के लिए सही LLM उपयोग करने का तरीका जानें

कई ओपन-सोर्स प्रोजेक्ट्स भी इस लेख में चर्चा की गई प्रथाओं को रेडी-टू-यूज़ कॉन्फ़िगरेशन्स में बाँधकर लाते हैं:

• obra/superpowers — एक कॉम्पोज़ेबल स्किल्स फ़्रेमवर्क जो TDD प्रवर्तन, सोक्रेटिक ब्रेनस्टॉर्मिंग, ग्रैन्युलर प्लानिंग, और कार्यों के बीच स्वचालित कोड रिव्यू के साथ आता है। अब Anthropic के मार्केटप्लेस में आधिकारिक प्लगइन।

• github/spec-kit — GitHub का आधिकारिक Spec-Driven Development टूलकिट। कार्य को Constitution → Specify → Plan → Tasks के रूप में संरचित करता है—किसी भी कोडिंग एजेंट में स्पेस को सिंगल सोर्स ऑफ़ ट्रुथ बनाता है।

• bmad-code-org/BMAD-METHOD — 12+ एजेंट पर्सोना (Architect, QA, Scrum Master) और 34+ वर्कफ़्लोज़ के साथ पूरा एजाइल फ़्रेमवर्क—पूरे डेवलपमेंट लाइफ़साइकल को कवर करता है।

• wshobson/commands — 57 प्रोडक्शन-रेडी स्लैश कमांड जिन्हें आप .claude/commands/ में सीधे डाल सकते हैं—जिनमें 15 मल्टी-एजेंट वर्कफ़्लोज़ शामिल हैं।

• awesome-claude-code — स्किल्स, हुक्स, कमांड्स, एजेंट्स, और प्लगइन्स की इकोसिस्टम डायरेक्टरी। उपलब्ध चीज़ें ब्राउज़ करना चाहें तो यहीं से शुरू करें।

निष्कर्ष

इस लेख के हर पैटर्न का निष्कर्ष एक ही विचार है: निष्पादन से पहले Claude को सख़्ती से सीमाबद्ध करें, फिर उसे अपना आउटपुट जाँचने का तरीका दें। योजना अस्पष्टता को समेट देती है। CLAUDE.md और हुक्स सीमाएँ तय करते हैं। टेस्ट वेरिफ़िकेशन देते हैं। कॉन्टेक्स्ट हाइजीन सत्रों के पार सब कुछ सुचारु रखती है।

यदि आप एक बदलाव से शुरू करना चाहें, तो Document & Clear अपनाएँ। सत्रों के पार कॉन्टेक्स्ट रॉट की कीमत नए सत्र के लिए आवश्यक 20K टोकन से कहीं अधिक है। उसके बाद:

• एक प्री-कमिट हुक जोड़ें जो टेस्ट फेल होने पर कमिट्स ब्लॉक करे

• हर मल्टी-फ़ाइल कार्य कोड छूने से पहले एक प्लान के साथ शुरू करें

• अपनी CLAUDE.md को 100 निर्देशों के भीतर रखें और डोमेन-विशिष्ट नियमों के लिए सबडायरेक्टरी फ़ाइलों का उपयोग करें

हमने हाल ही में AI Engineering with LangChain पर नया स्किल ट्रैक जोड़ा है। इसका कोर्स कंटेंट AI-नेटिव है, ताकि आप अपने पर्सनल ट्यूटर एजेंट के साथ सीख सकें। AI वर्कफ़्लोज़ इंजीनियरिंग में माहिर बनने के लिए इसे देखना मैं सुझाव देता/देती हूँ।