Claude Code का उपयोग करने का तरीका: योजना और निष्पादन का अलगाव

• AI कोडिंग टूल्स के उपयोग के तरीके को बुनियादी रूप से पुनर्गठित करते हुए, कोड लिखने से पहले अनिवार्य स्पष्ट योजना समीक्षा चरण वाले workflow का प्रस्ताव
• मुख्य सिद्धांत है “योजना की मंजूरी से पहले Claude से कोड न लिखवाएँ”, जिससे संरचनात्मक नियंत्रण और token उपयोग की दक्षता हासिल होती है
• पूरी प्रक्रिया Research → Plan → Annotation → Todo List → Implementation → Feedback की चक्रीय संरचना में चलती है
• हर चरण में markdown दस्तावेज़ (research.md, plan.md) को केंद्र में रखकर सहयोग किया जाता है, और टिप्पणियों व संशोधन की पुनरावृत्ति से गुणवत्ता बढ़ाई जाती है
• यह तरीका AI की निष्पादन क्षमता और मानव के निर्णय को अलग भी करता है और जोड़ता भी है, ताकि जटिल सिस्टम में भी स्थिर और सुसंगत परिणाम मिल सकें

---

पूरे workflow का अवलोकन

• लगभग 9 महीनों तक Claude Code को मुख्य development tool के रूप में इस्तेमाल करते हुए, सामान्य “prompt इनपुट → code generation → बार-बार संशोधन” तरीके के बजाय योजना और निष्पादन को अलग करने वाली व्यवस्थित प्रक्रिया बनाई गई
• Claude को कोड लिखने से पहले, उसे केवल लेखक द्वारा समीक्षा और स्वीकृत योजना दस्तावेज़ (plan.md) के आधार पर ही काम करने दिया जाता है
• यह दृष्टिकोण अनावश्यक trial and error को घटाता है, architecture पर निर्णय का नियंत्रण बनाए रखता है, और token उपयोग के मुकाबले गुणवत्ता को अधिकतम करता है

Phase 1: Research

• हर काम की शुरुआत कोडबेस के गहन विश्लेषण से होती है
  • Claude को किसी खास folder या feature को “गहराई से पढ़कर (detailed, intricacies)” विश्लेषण करने का निर्देश दिया जाता है
  • परिणाम को अनिवार्य रूप से research.md फ़ाइल में दर्ज कराया जाता है
• यह दस्तावेज़ Claude की समझ की जाँच करने वाली review surface की भूमिका निभाता है, और यदि कोई गलतफहमी हो तो इसी चरण में सुधारी जाती है
• गलत research आगे चलकर गलत योजना और implementation तक ले जाती है, इसलिए इसे सबसे महँगे failure factor को पहले ही रोकने वाला चरण माना गया है
• उदाहरण के तौर पर caching layer को नज़रअंदाज़ करना, ORM नियमों को शामिल न करना, या duplicate logic बनाना जैसी समस्याओं को रोका जा सकता है

Phase 2: Planning

• research की समीक्षा के बाद, Claude से विस्तृत implementation plan (plan.md) लिखवाया जाता है
  • इसमें वास्तविक code snippets, बदली जाने वाली file paths, trade-offs आदि शामिल होते हैं
  • built-in plan mode के बजाय प्रत्यक्ष रूप से नियंत्रित किए जा सकने वाले markdown फ़ाइल का उपयोग किया जाता है
• यदि open source की reference implementation भी साथ दी जाए, तो Claude की योजना की गुणवत्ता काफी बेहतर हो जाती है
• योजना दस्तावेज़ से भी अधिक महत्वपूर्ण बाद का Annotation cycle है

Annotation Cycle

• लेखक plan.md खोलकर खुद inline टिप्पणियाँ जोड़ता है
  • गलत मान्यताओं को सुधारना, approach को अस्वीकार करना, domain knowledge जोड़ना आदि
  • उदाहरण: “यह PATCH होना चाहिए”, “caching की ज़रूरत नहीं”, “visibility field को list स्तर पर ले जाएँ”
• इसके बाद Claude को निर्देश दिया जाता है कि “टिप्पणियों को शामिल कर दस्तावेज़ अपडेट करो, लेकिन अभी implementation मत करो”
• इस टिप्पणी-अपडेट cycle को 1 से 6 बार दोहराया जाता है, और “don’t implement yet” कमांड से समय से पहले execution रोका जाता है
• markdown दस्तावेज़ साझा की जा सकने वाली state की तरह काम करते हैं, इसलिए वे बातचीत आधारित निर्देशों की तुलना में अधिक स्पष्ट और संरचित होते हैं
• इस पुनरावृत्ति के माध्यम से सामान्य योजना वास्तविक सिस्टम के बिल्कुल उपयुक्त specification में बदल जाती है

Todo List बनाना

• implementation से पहले, Claude से विस्तृत todo list जोड़ने को कहा जाता है
  • इसमें हर चरण के सूक्ष्म task शामिल होते हैं ताकि प्रगति को ट्रैक किया जा सके
  • Claude पूरा हुए आइटम को चिह्नित करता है, इसलिए लंबे session में भी स्थिति समझना आसान रहता है

Phase 3: Implementation

• सभी निर्णय तय हो जाने के बाद, एक standardized prompt से execution का निर्देश दिया जाता है
  • “सभी task पूरे होने तक मत रुको”, “अनावश्यक comments मत जोड़ो”, “any/unknown type का उपयोग मत करो”, “लगातार type-check करते रहो” आदि
• यह निर्देश योजना को उसी रूप में लागू करने वाला यांत्रिक चरण है; रचनात्मक निर्णय पहले ही पूरे किए जा चुके होते हैं
• यदि बिना योजना के सीधे implementation शुरू किया जाए, तो गलत मान्यताओं के ऊपर कोड जमा होने लगता है; इसलिए “don’t implement yet” नियम सबसे अहम safety guard है

Implementation के दौरान Feedback

• execution के दौरान लेखक supervisor की भूमिका में आ जाता है
  • feedback छोटा और स्पष्ट दिया जाता है: “यह function छूट गया”, “इसे admin app में ले जाएँ” आदि
  • frontend संशोधन में “wider”, “2px gap” जैसे छोटे निर्देश या screenshot का उपयोग किया जाता है
• मौजूदा code references का बार-बार उपयोग करके सुसंगत UI/UX बनाए रखा जाता है
• यदि काम गलत दिशा में चला जाए, तो git revert करके scope घटाकर फिर से प्रयास करना क्रमिक सुधार से अधिक प्रभावी होता है

Driver’s Seat में बने रहना

• Claude को पूर्ण स्वायत्तता नहीं दी जाती, अंतिम निर्णय हमेशा इंसान लेता है
• Claude के सुझावों में से कुछ को चुनना, संशोधित करना, हटाना, या तकनीकी विकल्पों को फिर से परिभाषित करना संभव है
  • उदाहरण: “पहले वाले में Promise.all इस्तेमाल करो”, “चौथे और पाँचवें को अनदेखा करो”
  • “download feature हटा दो”, “function signature मत बदलो”, “किसी खास library method का उपयोग करो” आदि
• Claude यांत्रिक निष्पादन संभालता है, जबकि इंसान निर्णय और प्राथमिकता तय करने की जिम्मेदारी लेता है

Single Long Sessions

• research से implementation तक सब कुछ एक ही लंबे session में लगातार किया जाता है
  • session के दौरान Claude लगातार context जमा करता रहता है, और auto-compaction से पर्याप्त संदर्भ बना रहता है
  • plan.md पूरे session में पूर्ण रूप में सुरक्षित रहता है, और कभी भी संदर्भ के लिए देखा जा सकता है

मुख्य सारांश

• “गहराई से पढ़ो, योजना लिखो, टिप्पणियों से उसे निखारो, फिर एक बार में लागू करो।”
• जटिल prompts या system निर्देशों के बिना भी, Thinking और Typing को अलग करने वाली अनुशासित pipeline के जरिए उच्च गुणवत्ता हासिल की जा सकती है
• Research बिना समझ के बदलावों को रोकता है, Plan गलत बदलावों को रोकता है, और Annotation मानव निर्णय को शामिल करता है
• अंतिम execution सभी निर्णय तय होने के बाद एक automated प्रक्रिया के रूप में किया जाता है, जिससे एक कुशल सहयोगी संरचना पूरी होती है

[naka98]

मुझे भी इसी तरह की समस्या बार-बार होती रही है। अगर AI के साथ सिर्फ chat-आधारित तरीके से सहयोग करें, तो work breakdown structure (WBS), प्रगति, और निर्णयों का रिकॉर्ड धुंधला हो जाता है।

[pcj9024]

प्लान फ़ाइल को सीधे repository के अंदर रखकर, और उस प्लान को execute करके जो बदलाव लागू होते हैं उन्हें सेव करने दें, तो context काफ़ी हद तक बना रहता है।

[geekbini]

यह बात केवल Claude तक सीमित नहीं है; लगता है कि इसे सामान्य रूप से दूसरे CLI-आधारित AI services पर भी लागू किया जा सकता है।

[GN⁺]

Hacker News टिप्पणियाँ

• असली मुद्दा यह नहीं है कि “प्लान बनाते हैं या नहीं”, बल्कि यह है कि मॉडल को कोड में जमने से पहले अपनी मान्यताओं को उजागर करने पर मजबूर किया जाए
  LLM व्याकरण से ज़्यादा आर्किटेक्चर या constraints जैसी अदृश्य पूर्वधारणाओं में फेल होते हैं। इसलिए documented plan उन पूर्वधारणाओं को debug करने के लिए एक सतह उपलब्ध कराता है

  • इस नज़रिए से sub-agent संरचना बहुत मददगार है। एक planning करे, एक implementation, और दूसरा review संभाले तो roles साफ़ हो जाते हैं। इसे blue team/red team स्टाइल में भी किया जा सकता है। आखिरकार मकसद यही है कि LLM को ज़्यादा स्पष्ट निर्देश देकर सही reasoning में मदद की जाए
  • अगर पूरे use-case flow को निर्देशों में शामिल किया जाए, तो मॉडल के अजीब या भटके हुए behavior की संभावना कम होती है
  • लेकिन इन मान्यताओं को उजागर करने की प्रक्रिया खुद मॉडल के behavior को बदल भी सकती है। जैसे printf() की एक लाइन डालते ही Heisenbug गायब हो जाए
  • व्याकरण की गलतियाँ लगभग नहीं होतीं? मेरा अनुभव अलग है। एक छोटे Rust प्रोजेक्ट में S3 backend जोड़ते समय Claude API hallucination loop में फँस गया और 30 मिनट में $20 जला दिए। जबकि मामला सिर्फ एक साधारण syntax समस्या का था
  • कहीं यह पोस्ट ChatGPT से लिखी हुई तो नहीं?

• कुछ लोग कहते हैं कि Claude को सतही तौर पर पढ़ने से रोकने के लिए “deeply”, “in detail” जैसे शब्द इस्तेमाल करने पड़ते हैं, लेकिन सच कहूँ तो यह बात सहज रूप से समझ नहीं आती

  • यह attention mechanism की वजह से है। LLM ने पूरे इंटरनेट पर training ली है, और “समस्या के details देखो” जैसे phrases वाले लेखों में आम तौर पर expert-level जवाब होते हैं। इसलिए ऐसे शब्द आने पर मॉडल उस तरह के data को ज़्यादा weight देता है। “MIT professor की तरह behave करो” जैसे prompts काम करने की वजह भी यही है
  • लेकिन इस तरह की व्याख्या अंधविश्वास जैसी लगती है। इसके लिए कोई statistically verified आधार नहीं है, और यह लगभग सूर्यदेव को बलि चढ़ाने जैसी जादुई सोच लगती है। अगर इसका सच में असर है, तो optimization problem के रूप में इसे साबित किया जा सकता है, लेकिन कोई data सार्वजनिक नहीं करता
  • अभी software development वाकई एक अजीब दौर में है। किसी को नहीं पता कि LLM इस तरह क्यों behave करते हैं। हम बस उम्मीद करते हैं कि prompts probability को सही दिशा में धकेल दें। पहले यह क्षेत्र deterministic हुआ करता था, अब हम AGENTS.md फ़ाइल में ऐसे bold निर्देश लिख रहे हैं जैसे माता-पिता बच्चे से बात कर रहे हों
  • यह सब देखकर भी लोग इसे अब तक गंभीरता से लेते हैं, यह हैरान करता है। लगभग engineering वाली astrology जैसा लगता है
  • अगर मॉडल के latent space को एक भू-भाग की तरह सोचो तो समझना आसान है। Prompt उस जगह गेंद गिराने जैसा है, और शब्दों का चुनाव तय करता है कि गेंद किस घाटी में लुढ़केगी। “गहराई से” जैसे phrases उस गेंद को मनचाहे इलाके में टिके रहने में मदद करते हैं। यह शायद पूरी तरह सही व्याख्या न हो, लेकिन इस तरह सोचने पर यह व्यवहार में काम करता दिखा है

• मैं तीन तरह के documents और दो skills वाली एक संरचना इस्तेमाल करता हूँ
  Specs प्रोजेक्ट के static design documents होते हैं, Plans LLM द्वारा बनाए गए execution plans होते हैं, और Working memory फ़ाइल progress को track करती है।
  Gemini Pro की planner skill से नया plan बनाता हूँ, और Codex की implementer skill से उसे execute करता हूँ।
  इससे context हल्का और focused रहता है, इसलिए efficiency बढ़ती है। Codex/Gemini के $20 plan से भी काफ़ी तेज़ी से काम हो जाता है

  • मैं भी मिलती-जुलती approach अपनाता हूँ। paper के आधार पर spec files बनाता हूँ और Claude के साथ interact करते हुए plan को evolve करता हूँ। IEEE स्टाइल system engineering documents की तरह requirements–tests–definitions को manage करता हूँ। Claude को guardrails दिए जाएँ तो वह अच्छी तरह follow करता है। Codex की तुलना में Claude मेरी शैली से ज़्यादा मेल खाता है
  • बढ़िया approach है। लेकिन सोच रहा हूँ कि monorepo AI युग में बेहतर विकल्प है या नहीं। हमारी कंपनी ने Next.js apps को कई repos में बाँट रखा है, और अब सोच रहे हैं कि क्या उन्हें एक में merge करना बेहतर होगा

• Plan document में सीधे comments छोड़ने का विचार काफ़ी ताज़ा लगा। जानना चाहता हूँ कि क्या उन comments को अलग से save या बाद में review करने लायक manage करने का कोई तरीका है

• इस approach में कुछ बातें मुझे पसंद नहीं आतीं
  पहला, एक बार में सारा code generate करने वाला big-bang तरीका समझने में मुश्किल, विशाल code mass बना देता है। मेरा मानना है कि चरणबद्ध plan और execution बेहतर हैं।
  दूसरा, feedback देने के बावजूद knowledge base को update न करना खटकता है। गलती के कारणों को record करना चाहिए ताकि अगली बार वे दोहराए न जाएँ।
  आखिर में, testing का कोई ज़िक्र नहीं है। कम से कम कुछ हद तक test-driven development (TDD) शामिल होना चाहिए। यह देखना दिलचस्प होगा कि AI-assisted development इन methodology के साथ कैसे घुलेगा-मिलेगा

  • मेरा अनुभव भी ऐसा ही रहा है। इसलिए मैं PLAN.md को steps में बाँटता हूँ, और prompts बहुत सावधानी से लिखता हूँ ताकि हर बार सिर्फ वही चरण execute हो। Testing को भी plan का हिस्सा बनाता हूँ, लेकिन अभी भी अक्सर उसे बाद के हिस्से में जोड़ता हूँ

• यह workflow दरअसल Anthropic द्वारा सुझाया गया Claude Code का standard तरीका है। लेकिन इसकी कमी यह है कि अगर plan perfect न हो, तो शुरुआत से फिर करना पड़ सकता है।
  इसलिए मैं design → plan → execute को कई batches में बाँटकर करता हूँ। अगर plan units को 1,500 lines से कम रखा जाए, तो complexity संभालना आसान होता है।
  मेरे 30,000 LOC वाले app के लिए 100,000 lines का plan है। इसे एक बार में बनाना असंभव है

  • मेरा अनुभव भी यही है। इसलिए मैं plans को और छोटे units में तोड़ता हूँ, और feature branches के ज़रिए commits manage करता हूँ। AI की वजह से उल्टा मेरी development habits बेहतर हुई हैं
  • सच कहें तो “radically different” workflow कहकर जो बताया जा रहा है, वह बस default Plan mode का इस्तेमाल ही है, यह थोड़ा awkward है
  • मैं भी मानता हूँ कि incremental execution ही सही जवाब है। किसी विशाल प्रोजेक्ट को एक बार में पूरा कर देना अभी भी सिर्फ मृगतृष्णा है
  • Plan perfect न भी हो तो चलता है। AI द्वारा बदले गए हिस्सों को revert करके पिछले चरण से दोबारा iterate किया जा सकता है। छोटे-छोटे बदलाव के ज़रिए complexity घटाना ही असली कुंजी है
  • 100,000 lines का plan लगभग दस लाख शब्दों के बराबर है। उसे सिर्फ पढ़ने में ही 66 घंटे लगेंगे। व्यवहारिक रूप से यह असंभव है

• मैं plan.md की जगह executable scaffold और validation loop पर केंद्रित होकर काम करता हूँ
  मैंने AI के साथ मिलकर Kolibri Tickets नाम का एक असली payment system बनाया। असली बात यह नहीं है कि मॉडल जल्दी code लिख दे, बल्कि यह है कि validation loop को design किया जाए

  • शुरू में एक executable skeleton बनाए रखो
  • हर बार सिर्फ पतला vertical slice जोड़ो
  • tests, types, state machine जैसी verifiable outputs को अनिवार्य बनाओ
  • refactoring को रोज़मर्रा की प्रक्रिया बनाओ
    ऐसा करने पर “speed का भ्रम” नहीं, बल्कि सच में तेज़ deployment संभव होता है। Plan document shared state बनाए रखने का एक तरीका है, और verifiable harness दूसरा तरीका है
  • मैं भी code सस्ता हो जाने के इस दौर में 100% test coverage को लक्ष्य बना रहा हूँ। Python में static typing, Playwright tests, यहाँ तक कि mutation testing भी ला रहा हूँ। अब agents 1 घंटे का loop चलाकर ऐसा code दे देते हैं जिसमें लगभग कोई manual fix नहीं करनी पड़ती

• मैं Claude Code का इस्तेमाल lecture preparation के लिए करता हूँ
  Quarto में lecture notes लिखता हूँ, और Claude से उन्हें Slidev slides में बदलवाता हूँ। उसके बाद slides पर “इसे दो स्लाइड में बाँटो”, “यहाँ image जोड़ो” जैसी टिप्पणियाँ लिखकर feedback देता हूँ।
  इस तरह का comment-based feedback बहुत शक्तिशाली है। Token distance और context retention, दोनों में बहुत मदद मिलती है

  • Quarto अपने आप भी PowerPoint, PDF, HTML जैसी कई formats को support करता है, फिर Slidev क्यों? क्या Claude से Quarto document दोबारा generate नहीं करवाया जा सकता?
  • जानना चाहूँगा कि feedback inline comments के रूप में छोड़ते हैं क्या। जैसे # इस हिस्से को X में बदलो जैसी शैली में?
  • क्या वह Claude skill open source के रूप में जारी की गई है?

• Amazon का Kiro, Google का Antigravity, GitHub का Spec Kit, और OpenSpec जैसे tools पहले से ऐसी functionality दे रहे हैं

• AI-assisted coding की सबसे महंगी विफलता syntax error नहीं, बल्कि ऐसा implementation है जो कुछ हद तक काम करता है लेकिन पूरे system को तोड़ देता है
  इसलिए मैं शुरुआत में brief.md जोड़ता हूँ, जिसमें problem definition, target metrics, और feature को रोकने की conditions जैसी बातें साफ़ लिखी होती हैं। इससे business goals और technical implementation के बीच mismatch की लागत कम होती है