Claude Code से अच्छे नतीजे पाना

• पिछले कुछ महीनों में कई LLM programming agents को आज़माने के बाद Claude Code सबसे संतोषजनक टूल लगा
• Claude Code की मदद से कम समय में लगभग 12 प्रोग्राम और प्रोजेक्ट बनाए, और ऐसे काम भी कर पाए जिन्हें आम तौर पर समय की कमी के कारण शुरू नहीं किया जाता
• इसे सफलतापूर्वक इस्तेमाल करने के लिए स्पष्ट specification लिखना, प्रोजेक्ट structure, build और lint चलाने के तरीकों वाला documentation देना, AI से अपनी ही code review करवाना, और personalized global agent guide चलाना अहम है
• AI द्वारा लिखा गया code अक्सर गलत या अप्रभावी हो सकता है, इसलिए हर code और test case को खुद ज़रूर review करना चाहिए, और कमज़ोर tests को या तो खुद जोड़ना चाहिए या AI से लिखवाकर फिर दोबारा जांचना चाहिए
• परिशिष्ट के रूप में साझा की गई global agent guide में step-by-step implementation plan, test-driven development, simplicity, clarity और practicality पर आधारित सोच, quality standards, problem-solving process जैसी विस्तृत development guidelines शामिल हैं

---

Claude Code के उपयोग का अनुभव और प्रभाव

• पिछले कुछ महीनों में कई LLM programming agents को आज़माया, और खास तौर पर Claude Code का अनुभव सबसे बेहतर रहा
• यह पूरी तरह समस्या-मुक्त नहीं है, फिर भी कम समय में 12 से अधिक प्रोग्राम और प्रोजेक्ट पूरे किए जा सके
• Claude Code के बिना उसी अवधि में यह सब करना लगभग असंभव होता
• कई काम ऐसे थे जिन्हें समय लगने की वजह से शायद शुरू भी नहीं किया जाता

Claude Code उपयोग की रणनीति

• स्पष्ट specification लिखना
  • प्रोजेक्ट शुरू करने से पहले requirements और context को साफ़-साफ़ document करके agent को देना
  • इससे code लिखने की दिशा और सीमा स्पष्ट होती है
• प्रोजेक्ट structure का documentation
  • build, lint और test चलाने के तरीकों वाला दस्तावेज़ तैयार रखना
  • इससे agent codebase को अधिक प्रभावी ढंग से explore करके काम कर सकता है
• agent से code review करवाना
  • Claude Code से उसके बनाए गए code का खुद review करवाकर अप्रत्याशित improvements या bugs खोजे जा सकते हैं
• व्यक्तिगत global guide का उपयोग
  • problem-solving approach, TDD का उपयोग, simplicity और clarity बनाए रखना, प्रयासों की सीमा (3 बार) जैसी व्यक्तिगत rules वाली ~/.claude/CLAUDE.md के जरिए एक consistent development process बनाए रखना

LLM द्वारा लिखे गए code का validation

• AI-generated code में अक्सर logical errors, performance issues, अधूरे tests जैसी समस्याएँ होती हैं
• लेखक हर code को मैन्युअली review करता है और उसका व्यवहार जांचता है
  • छूटे हुए test cases को खुद जोड़ता है
  • या AI से लिखवाकर code और tests को फिर से review करता है
• प्रोफेशनल माहौल में, PR पर अपना नाम होने का मतलब है कि अंतिम गुणवत्ता की ज़िम्मेदारी आपकी ही है

व्यक्तिगत “global” agent guide की मुख्य बातें

यह guide ~/.claude/CLAUDE.md फ़ाइल में manage की जाती है

• दर्शन और मुख्य सिद्धांत

  • क्रमिक प्रगति: छोटे-छोटे बदलाव, और हर बार compile तथा tests pass होना
  • मौजूदा code से सीखना: implementation से पहले code patterns का विश्लेषण और planning
  • practicality पहले: प्रोजेक्ट की स्थिति के मुताबिक लचीला approach
  • clarity पहले: पढ़ने में आसान और इरादे को साफ़ दिखाने वाला code, अनावश्यक tricks से बचाव

• simplicity की परिभाषा

  • functions और classes की एक ही ज़िम्मेदारी हो
  • समय से पहले abstraction से बचें
  • complexity घटाएँ और ऐसे code की ओर बढ़ें जिसे अलग से समझाने की ज़रूरत न पड़े

• काम की प्रक्रिया

  • 1. planning और चरण तय करना:
    • जटिल कामों को 3~5 चरणों में बाँटकर IMPLEMENTATION_PLAN.md में लिखना
    • हर चरण का लक्ष्य, success criteria, test cases, और progress status दर्ज करना
  • 2. implementation flow:
    • समझना → test लिखना (red) → न्यूनतम implementation (green) → refactoring → commit
  • 3. 3 प्रयासों की सीमा के बाद पुनर्मूल्यांकन:
    • असफल होने पर प्रयासों का विवरण, errors और कारण दर्ज करना
    • alternatives खोजना (2~3 approaches)
    • मूल design और problem breakdown की फिर से समीक्षा
    • अलग patterns या features आज़माना

• तकनीकी standards

  • composition पहले, और dependency injection का उपयोग
  • interfaces का उपयोग, ताकि testing आसान हो
  • स्पष्ट data flow
  • TDD की सिफारिश, tests को disable करना मना

• code quality rules

  • हर commit में compile सफल हो, tests pass हों, नई functionality के tests शामिल हों, और code style का पालन हो
  • commit से पहले formatter और linter चलाना, changes की self-review करना, और "क्यों" समझाने वाला commit message लिखना

• error handling

  • जल्दी fail होना और स्पष्ट messages देना
  • debugging के लिए ज़रूरी context देना
  • सही स्तर पर exceptions handle करना, exceptions को छिपाना नहीं

• decision-making criteria

  • 1. testing की आसानी
  • 2. 6 महीने बाद भी समझ में आने वाली readability
  • 3. प्रोजेक्ट patterns के साथ consistency
  • 4. simplicity
  • 5. बदलाव की आसानी

• प्रोजेक्ट integration

  • समान functionality वाले 3 या अधिक उदाहरणों का विश्लेषण
  • मौजूदा patterns और libraries का पुन: उपयोग
  • वही test utilities इस्तेमाल करना
  • नया tool लाने के लिए मज़बूत कारण होना

• quality gates

  • सभी tests pass हों
  • प्रोजेक्ट rules का पालन हो
  • linter warnings न हों
  • commit message स्पष्ट हो
  • implementation plan के अनुरूप हो
  • TODO में issue number शामिल हो

• testing guidelines

  • implementation नहीं, behavior-केंद्रित tests
  • जहाँ संभव हो, हर test में एक assertion
  • scenario बताने वाले स्पष्ट नाम
  • मौजूदा test utilities का पुन: उपयोग
  • tests deterministic होने चाहिए

• पूरी तरह निषिद्ध

  • --no-verify से hooks को bypass करना
  • tests disable करना
  • compile न होने वाला code commit करना
  • verification के बिना अनुमान लगाना

• अनिवार्य रूप से करना है

  • क्रमिक commits
  • documentation को लगातार update करना
  • मौजूदा implementation से सीखना
  • 3 बार असफल होने के बाद approach का पुनर्मूल्यांकन

Claude Code से बनाए गए open source projects

• HTML/XML-aware reverse proxy (cdzombak/xrp)
• VS Code Solarized theme (light/dark) (cdzombak/dzsolarized-vscode)
• Flickr photostream RSS generator (cdzombak/flickr-rss)
• Lychee photo library metadata tool (cdzombak/lychee-meta-tool)
• macOS screen lock status MQTT reporting (cdzombak/macos-screenlock-mqtt)
• Lychee Bird Buddy photo title auto-setting (cdzombak/lychee-birb-title)
• local LLM-based photo auto-organization (cdzombak/lychee-ai-organizer)
• macOS के लिए software bulk-install automation (cdzombak/mac-install)
• RSS service project (cdzombak/rss.church)
• Flickr photos का full/selective export और metadata preservation (cdzombak/flickr-exporter)
• static HTML gallery generator (cdzombak/gallerygen)

[wedding]

अच्छे नतीजे आए, इसका मतलब क्या यह है कि किसी ने पहले से बनाए गए कोड को अच्छी तरह रेफर किया था?

[aeolian21]

लेखक जो कुछ कर रहे हैं, वह तो सब लोग बहुत पहले से कर रहे हैं, इसलिए बेकार की शेखी बघारने के बजाय
जब LLMs के बीच तुलना की गई, तब आपको क्यों लगा कि Claude सबसे बेहतर था, उसके कारण लिखना कहीं ज़्यादा सार्थक लेख होगा
जैसे कि वास्तव में generated code की तुलना, compile error की आवृत्ति, context समझने की स्थिरता वगैरह
असल में context समझने की क्षमता सबसे बेहतरीन Gemini की है (10 लाख टोकन)

[zxcv123]

बस बेकार चीज़ें ही बनाई हैं और ऊपर से लिखाई भी बेवजह बहुत लंबी कर दी है।

[knunu]

किसी के लिए यह काम का हो सकता है, हाहा

[GN⁺]

Hacker News राय

• आज पहली बार Claude और coding agent के साथ सच में अच्छा सफलता अनुभव हुआ। इससे पहले Cursor इस्तेमाल किया था, लेकिन अब Claude और कुछ अन्य टूल्स भी साथ में आज़मा रहा हूँ। लेख में कहा गया है कि साफ़ specification लिखना ही सबसे अहम है। मैंने 2 घंटे में खुद 12-step document लिखा, जिसमें implementation का तरीका व्यवस्थित किया और background information भी शामिल की। Claude ने उसी procedure को follow करते हुए क्रम से code generate किया। मेरे हिसाब से इससे लगभग 6~10 घंटे बचे। अब मैं इसे review, test और धीरे-धीरे adjust करके features जोड़ने वाला हूँ। इस सफलता की बुनियाद यह थी कि Claude को क्या-क्या करना है, उसके सारे steps मैंने खुद साफ़-साफ़ लिखे थे। यानी पूरा flow मैंने design किया और Claude सिर्फ़ instructions follow कर रहा था। इस process से मुझे और यक़ीन हुआ कि mid-level या उससे ऊपर के developers को अभी कुछ समय तक AI replace नहीं करेगा। लेकिन Claude को spec पढ़कर साफ़-सुथरा documented code निकालते देखना सच में हैरान करने वाला अनुभव है। यह कमाल है कि मुझे खुद coding नहीं करनी पड़ी

  • मुझे इतनी तैयारी के बिना भी Claude से अच्छे results मिलते हैं। मैं लगभग वैसे ही उससे step-by-step काम करवाता हूँ जैसे खुद code लिखता। हर बार बदला हुआ हिस्सा तुरंत apply और commit करता हूँ, फिर diff review करता हूँ। अगर Claude कोई अजीब result देता है, तो तुरंत correction माँगता हूँ। और जो existing code या function references इस्तेमाल करवाने हों, वे भी सीधे बता देता हूँ। इस तरीके से बहुत कम typing और समय में शानदार results मिल सकते हैं

  • Naur का “Programming as Theory Building” पढ़ने की सलाह दूँगा। इससे मैंने सीखा कि problem को theoretical तरीके से कैसे समझना और खुद model करना चाहिए। वरना LLM अपनी (गलत) theory बना सकता है
    “Programming as Theory Building” - Naur पढ़ें

  • लेख की तरह ही clear specification सच में बहुत ज़रूरी है। मैं Claude से एक programming language बना रहा हूँ और इसे सीधे महसूस कर रहा हूँ। Programming असल में बहुत सारे छोटे-छोटे decisions की लगातार श्रृंखला है। अगर आप साफ़ guidance नहीं देंगे, तो LLM ज़्यादातर अनुमान से काम करेगा, और अक्सर गलत choice कर लेगा। ये छोटी गलतियाँ मिलकर बड़े गलत result तक ले जा सकती हैं

  • अगर कोई ऐसे specification document का example सीधे share कर सके, तो बहुत अच्छा होगा। मैं self-taught development करते हुए Claude Code के साथ experiments कर रहा हूँ, इसलिए असल में किस तरह की information और कितनी depth मदद करती है, यह समझने में बहुत फ़ायदा होगा

  • सच कहें तो बहुत से mid-level और senior developers भी ठीक से specification documents नहीं लिख पाते। आप जो कहना चाहते हैं, उसकी भावना से सहमत हूँ

• ~/.claude/CLAUDE.md बनाकर उसमें rules डालना शायद उतना असरदार नहीं होगा। Claude इंसान नहीं है, और code की हर line पर बहुत सोच-समझकर reasoning नहीं करता। subjective और vague instructions आमतौर पर code में वास्तविक बदलाव नहीं लाते। और context rot जैसी समस्या भी होती है
  (context rot का मतलब: लंबे conversation या काम के दौरान LLM का context खो देना या उसे बिगाड़ देना। संदर्भ लिंक: https://news.ycombinator.com/item?id=44564248)
  व्यवहारिक रूप से एक ही file में ढेर सारे rules भरकर यह उम्मीद करना कि AI खुद सब मानेगा, संभव नहीं है। ऐसा करना हो तो हर rule के लिए अलग sub-agent बनाना होगा और AI की जगह सामान्य pipeline में उन्हें अलग करना होगा। लेकिन इससे cost exponential तरीके से बढ़ जाएगी

  • अगर मुद्दा cost का है, तो workflow stable होने के बाद सस्ते LLM इस्तेमाल किए जा सकते हैं (हालाँकि operating cost फिर भी ऊँची हो सकती है)। fine-tuning, prompt optimization, specialized distillation techniques वगैरह से cost कम की जा सकती है। इस क्षेत्र में पहले से काफ़ी research हो रही है

  • जानना चाहूँगा कि CLAUDE.md में क्या-क्या शामिल करना अच्छा रहता है

• पेज के नीचे दिए sample projects देखें तो ज़्यादातर software किसी एक खास उद्देश्य के लिए optimized है। आगे चलकर open source projects भी शायद ऐसे ही evolve होंगे—किसी एक व्यक्ति की ज़रूरत पूरी करने वाले बेहद specialized रूप में। मुझे लगता है कि इस तरह का software (utility) धीरे-धीरे ऐसा disposable code बन जाएगा जिसे LLM एक ही बार में generate कर दे

• Claude Code के लिए मेरा approach लगातार बदल रहा है। अभी तक मैं कंपनी के बड़े web app में Claude Code के ज़रिए सीधे कोई meaningful feature contribute कराने में सफल नहीं हुआ हूँ। specifications कुछ हद तक मदद करती हैं, लेकिन आख़िर में flow अजीब दिशा में मुड़ जाता है और गलत decisions की repeated loop में फँस जाता है। यह Claude की limitation हो सकती है, या शायद मेरी spec अभी पर्याप्त सटीक नहीं है। मैंने बहुत experiments किए, लेकिन ‘challenging या domain expertise ज़्यादा माँगने वाली चीज़ों’ में failures ज़्यादा रहे, इसलिए अब उन्हें ज़्यादा नहीं आज़माता। इसके बजाय एक दोस्त की सलाह पर मैं Claude को ऐसे backlog tasks में लगाने लगा हूँ जिनमें मानसिक बोझ लगभग नहीं होता। उदाहरण के लिए, मैंने उससे एक नए workspace में Playwright tests बनवाए, जिनसे मुझे ज़्यादा लगाव भी नहीं था। यह बहुत सफल रहा। मैंने उसे वैसे समझाया जैसे किसी इंसान को user experience समझाते हैं, और dev server का path दिया। फिर Playwright MCP की मदद से यह पता लगाने को कहा कि किस feature को कैसे इस्तेमाल करना है, execution process document करना है, tests लिखने हैं और errors debug करने हैं। साथ ही project के UI code में जाकर data-testid selectors जोड़ने का काम भी कराया। पूरे process को master task.md में व्यवस्थित किया, और हर feature के लिए अलग task markdown files भी बनवाए। यह तरीका बहुत असरदार रहा। यहाँ तक कि 2 browser users के non-intuitive interaction वाले complex feature में भी इसे इस्तेमाल किया। 100% perfect तो नहीं था, लेकिन complexity बढ़ने पर बस थोड़ा extra context correction और code fixes चाहिए थे। कुल मिलाकर कई दिनों के झंझट वाले काम एक ही झटके में निपट गए

• CLAUDE.md को जितना हो सके 100 lines से कम का minimal file रखना सबसे अच्छा रहा,

  • project का essential context और उद्देश्य का summary
  • types, interfaces और helpers समझने के लिए project structure का minimum विवरण
  • package.json को बार-बार parse करने की ज़रूरत न पड़े, इसलिए सिर्फ़ मुख्य commands implementation/test flow में मेरे अनुभव से Claude कभी-कभी सारे tests पहले से एक साथ लिखने की कोशिश करता था, या import fail होने पर सब implementation पहले कर देता था (जो सही TDD तरीका नहीं है)। इसलिए मैंने TDD-Guard नाम का hook बनाया, जो एक बार में सिर्फ़ एक test pass कराए, test सही वजह से fail हो, और उसे pass कराने के लिए minimum code ही implement किया जाए—यह enforce करता है। code quality के लिए husky, lint-staged, commitlint वगैरह automate करके बहुत अच्छे results मिले। ऐसा करने से ज़्यादा महत्वपूर्ण information के लिए context बचाया जा सकता है। मैं इससे सहमत हूँ कि जब Claude Code अटक जाए, तो आख़िर में developer का सीधे दखल देना ही सबसे अच्छा तरीका है। बस अफ़सोस यह है कि सलाह अक्सर बहुत generic रह जाती है,
  • अगर automation approach में रुचि हो:
    • tdd-guard और example setup
    • husky
    • commitlint
    • lint-staged

• एक महीने से ज़्यादा समय से मैं रोज़ Claude Code के साथ काम कर रहा हूँ। Cursor, Q वगैरह इस्तेमाल किए, लेकिन Claude Code कहीं बेहतर है। लेख में बताए गए tips मेरी अपनी समझ से काफ़ी मेल खाते हैं।
  कुछ अतिरिक्त बातें साझा करूँ तो:

  • web console में Claude के साथ idea session से शुरुआत करता हूँ। project का goal समझाता हूँ, domain modeling और milestones का बड़ा खाका बनाता हूँ। अगर project छोटा हो, तो कुछ घंटों की back-and-forth discussion में चीज़ें साफ़ हो जाती हैं। यहीं से CLAUDE.md का पहला version निकलता है

  • असली project शुरू करते समय Claude मेरे global CLAUDE.md और project CLAUDE.md दोनों पढ़कर शुरू करता है। हर session में यही तरीका रहता है

  • काम चलते रहने पर भी मैं Claude Code से project CLAUDE.md लगातार update करवाता हूँ। plan के हिसाब से progress mark करवाता हूँ, और session के अंत में उससे project summary, यह कैसे काम करता है, code navigate कैसे करें, जैसी बातें लिखवाता हूँ। यह एक तरह की long-term memory का काम करता है, और अच्छा असर दिखा

  • guideline कितनी भी अच्छी हो, Claude में पहले से आगे बढ़ने की tendency रहती है। इसलिए जिन tasks में मैं खुद शामिल होता हूँ, उनमें उसे छोटे increments में step-by-step focus करवाता हूँ। लेकिन अगर काम one-off या prototype हो, तो उसे खुलकर implementation करने देता हूँ

    • क्या $20 subscription, Cursor की तुलना में value-for-money है? जानना चाहूँगा कि क्या इसे justify करने के लिए रोज़ इस्तेमाल ज़रूरी है

• project-level CLAUDE.md को बहुत लंबा नहीं, बल्कि concise रखना बेहतर है। ज़्यादा detailed चीज़ों को subfolders में ले जाएँ। top-level file को एक तरह के map की तरह इस्तेमाल करें। हर बार जब किसी feature की planning करें, Claude को सही folder देखने दें, ज़रूरी context refer करने दें, और step-by-step implementation plan बनवाएँ। हर phase के अंत में Claude से नए context के हिसाब से implementation plan update करवाएँ। इससे context स्वाभाविक रूप से अगले phase तक पहुँच जाता है, और window reset करके भी नए मन से अगला चरण शुरू किया जा सकता है

• मैं Claude Code से Factorio-जैसा ASCII game बना रहा हूँ। शुरुआती दौर में मैंने उसे लगभग बिना निगरानी के code लिखने दिया, और उसने ज़्यादातर major features (save/load, options, debug, map generation, construction, belts, crafting, QoL वगैरह) एक ही बार में implement कर दिए। लेकिन जब details ठीक करनी शुरू कीं, तो जैसे movement बदलो तो belts टूट जाएँ—ऐसी समस्याएँ आने लगीं। इसलिए मैंने उससे Playwright automation भी जोड़ने को कहा, लेकिन tests की quality कमज़ोर थी और हर जगह sleep calls भरे पड़े थे। code को ध्यान से देखा तो पता चला कि structure React frontend और useEffect पर आधारित था, किसी ठीक-ठाक game engine जैसा नहीं। hook rules का पालन भी ढंग से नहीं था और timing की समझ भी कमज़ोर थी। इसलिए इस बार मैंने tick-based game engine डालकर सब कुछ शुरू से फिर बनाना शुरू किया, और code review भी जोड़ा। प्रगति की रफ़्तार धीमी हुई है, लेकिन development अब कहीं ज़्यादा solid है। जब अच्छा demo तैयार हो जाएगा, तो Show HN पर शेयर करने का इरादा है

  • शुरुआती foundational skeleton तैयार होने तक इंसान का सीधा योगदान सच में बहुत क़ीमती होता है। एक बार refactoring का दौर निकल जाए, उसके बाद थोड़ी राहत मिलती है

• अगर मेरी तरह कोई Claude के work और personal दोनों subscriptions इस्तेमाल करता है, तो alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude" जैसे तरीके से account switching आसान बना सकता है
  कई Claude accounts को efficient तरीके से इस्तेमाल करने का ब्लॉग

• सब लोग कहते हैं कि ‘पहले से साफ़ specification लिखकर context देना ही कुंजी है’, लेकिन मेरे अनुभव में यह हमेशा काम नहीं करता। मैंने एक असली expert के साथ बैठकर Opus 4 & Sonnet 4 में CC sessions किए। सामने वाले ने बहुत clear spec तैयार की थी, लेकिन मेरी शैली—यानी feature सूझते ही, बिना CLAUDE.md के, हर बार अलग context के साथ सीधा request करना—उससे कोई खास बेहतर result नहीं मिला। specification-based workflow में या तो ज़रूरी बातें बार-बार भूल जाती थीं, या context document में न होने वाली चीज़ें मनगढ़ंत जोड़ दी जाती थीं (यहाँ तक कि वे चीज़ें भी जो मना थीं)। जबकि मेरे लिए जैसे “invoice के लिए crud page जोड़ो, पहले codebase analyze करो” जैसी तत्काल instructions ज़्यादा बेहतर रहीं। यह सिर्फ़ मेरा अनुभवजन्य किस्सा है, लेकिन Claude के साथ 100 से ज़्यादा projects करने के बाद भी, Claude को overstep करने से रोकने वाले अलग hooks के अलावा मैं भरोसे से नहीं कह सकता कि कोई एक खास तरीका बेहतर है। बहुत लोग कहते हैं कि ‘spec-based तरीका बेहतर है’, लेकिन जब उनसे असल उदाहरण दिखाने को कहो, तो अक्सर वे साफ़ तौर पर गलत हिस्सों को बार-बार सुधारने में ही बहुत समय खर्च करते दिखते हैं। यहाँ तक कि CLAUDE.md में ‘यह चीज़ कभी मत करना’ लिख देने पर भी Claude बार-बार वही करता था