- 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 प्रक्रिया के रूप में किया जाता है, जिससे एक कुशल सहयोगी संरचना पूरी होती है
अभी कोई टिप्पणी नहीं है.