Claude Code को बेहतरीन डिज़ाइन पार्टनर बनाना
(betweentheprompts.com)- शुरुआत में Claude Code का उपयोग करते समय तरीका सिर्फ prompt निर्देश और बार-बार संशोधन तक सीमित था, लेकिन जटिल कामों में conversation history पर निर्भरता और context की सीमाओं जैसी समस्याएँ सामने आईं
- इसे हल करने के लिए, feature implementation से पहले plan document लिखवाया गया और उसे नए session के लिए एकमात्र single source of truth (SSOT) बनाया गया
- plan document में requirements को दोबारा व्यवस्थित करना, implementation details, code quality जाँचने के commands आदि शामिल होते हैं, और implementation के दौरान भी यह living document की तरह लगातार अपडेट होता रहता है
- इससे context loss की समस्या हल हो जाती है, और नए session में भी सिर्फ एक दस्तावेज़ के आधार पर प्रोजेक्ट आगे बढ़ाया जा सकता है
- नतीजतन, AI सिर्फ एक execution tool नहीं रहता, बल्कि डेवलपर को डिज़ाइन पर अधिक गहराई से सोचने और उसे दर्ज करने के लिए प्रेरित करने वाला collaborative design partner बन जाता है
समस्या की समझ: साधारण संवाद-आधारित तरीके की सीमाएँ
- Claude Code के साथ conversational तरीके से काम करते समय, यह छोटे कामों के लिए उपयुक्त है, लेकिन जैसे-जैसे काम जटिल होता जाता है, कई गंभीर सीमाएँ सामने आती हैं
- बातचीत ही एकमात्र truth source बन जाती है, इसलिए नया message पहले के निर्देशों को आसानी से ओवरराइड कर सकता है, और यह कब हुआ इसे स्पष्ट रूप से पहचानना कठिन होता है
- AI की context size limit के कारण, बातचीत लंबी होने पर पहले की जानकारी छूट सकती है
- Claude Code में conversation compression feature है, लेकिन यह सीमा पूरी तरह दूर नहीं होती
plan document-केंद्रित तरीके का प्रयोग
- इन समस्याओं को हल करने के लिए plan document आधारित approach अपनाई गई
- शुरुआत में Claude Code को implement किए जाने वाले feature या ठीक किए जाने वाले bug के बारे में यथासंभव विस्तार से बताया जाता है
- reference के लिए मौजूदा source files या पहले लिखे गए plan documents का भी उल्लेख किया जाता है
- बहुत अधिक specific implementation निर्देशों से बचा जाता है, ताकि AI की design suggestion भूमिका को प्रोत्साहित किया जा सके
- जब plan document पर्याप्त संतोषजनक हो जाता है, तब conversation history साफ़ करके उसी plan को context बनाकर नई शुरुआत की जाती है
- plan में feature summary, implementation plan, code और pseudocode, type/lint/test commands आदि शामिल होते हैं
सहयोगी डिज़ाइन प्रक्रिया
- जब AI का सुझाया गया डिज़ाइन पसंद नहीं आता, तो ठोस feedback देकर संशोधित approach की ओर ले जाया जाता है
- चर्चा के दौरान कभी यह भी महसूस होता है कि AI का शुरुआती सुझाव अधिक उपयुक्त था, और यह अपने दम पर डिज़ाइन बनाकर सीधे coding करने की तुलना में अधिक प्रभावी होता है
- व्यवस्थित बातचीत, किसी सहकर्मी डेवलपर के साथ plan पर चर्चा करने जैसे अनुभव देती है
- AI अपने आप पूरी तरह अलग approach नहीं देता, लेकिन पूछने पर दूसरे alternatives सुझा सकता है
living document तरीका
- plan document एक बार लिखकर छोड़ा नहीं जाता, बल्कि feature implementation के दौरान भी लगातार अपडेट किया जाता है
- implementation, type check, lint, और test की प्रक्रिया में सामने आने वाले बदलावों को real time में प्रतिबिंबित किया जाता है
- हर बार code commit करते समय plan की latest स्थिति की जाँच करने की आदत बनाई जाती है
- plan हमेशा up-to-date रहने से, नए conversation session में भी सिर्फ plan जोड़कर बिना context loss के काम आगे बढ़ाया जा सकता है
code review और development आदतों में बदलाव
- implementation शुरू होने के बाद समय-समय पर बदलावों की जाँच की जाती है, और संतुष्ट होने पर AI के काम पर अधिक भरोसा भी किया जाता है
- final code review के समय अपडेट किया गया plan document technical decision-making के आधार को समझने में मदद करता है
- पहले से विस्तार से plan बनाकर उसे document करने से बेहतर डेवलपर के रूप में विकसित होने का अनुभव मिलता है
- क्योंकि AI को समझाना होता है, इसलिए अपनी decision-making प्रक्रिया को अधिक स्पष्ट रूप से व्यवस्थित करना पड़ता है
अव्यवस्था से प्रणाली तक
- यह तरीका plan document को single source of truth बना देता है, context loss की समस्या को दूर करता है, और architectural thinking को बढ़ावा देता है
- plan document में specification और implementation log दोनों शामिल होते हैं, और यह सिर्फ ‘क्या’ नहीं बल्कि ‘क्यों’ और ‘कैसे’ भी दर्ज करता है
- अंतिम परिणाम एक योजनाबद्ध, अच्छी तरह documented और अधिक विश्वसनीय development process होता है
- AI एक साधारण implementer नहीं, बल्कि collaborative design partner के रूप में स्थापित हो जाता है
2 टिप्पणियां
लगता है कि डेवलपर के workflow में PM और architect की भूमिका का महत्व और बढ़ता जा रहा है।
Hacker News टिप्पणी
पिछले 2 हफ़्तों से मैं हर शाम claude code का इस्तेमाल करके ऐसे "परफ़ेक्ट प्रॉम्प्ट" पर बहुत फ़ोकस कर रहा था, जिससे प्रोजेक्ट एक ही बार में पूरा हो सके। आख़िर में मैंने ऐसा स्ट्रक्चर बनाया जिसमें एक CLAUDE.md प्रोजेक्ट आर्किटेक्चर, मॉडल स्पेक, बिल्ड ऑर्डर, टेस्ट लेयर्स, सीनारियो वगैरह के लिए 8 अलग-अलग Markdown फ़ाइलों को रेफ़र करे। यह प्रोजेक्ट Databricks Unity Catalog की model-based governance के लिए है; इस क्षेत्र में मेरा काफ़ी अनुभव है, लेकिन मुझे लगा कि मौजूदा टूल्स काफ़ी flexible नहीं हैं। अंत में मुझे 3 sub-agents से मदद मिली—Databricks expert, Pydantic expert, और prompt expert—जो असली planning फ़ाइलों पर काम करने में सहायक रहे। इसकी वजह से Markdown फ़ाइलों की quality कई पहलुओं में बहुत बेहतर हुई, Pydantic के पुराने version की समस्याओं से लेकर Unity Catalog को लेकर मेरी ग़लतफ़हमियों तक। कल मैंने इसे सच में चलाकर देखा, और मेरे कुछ बार tool-use approvals देने के अलावा, 2 घंटे में ज़्यादातर tools और tests तैयार हो गए। यह तरीका पहले से इतना अलग लगा कि हैरानी हुई; मुझे सच में लगा कि तकनीकी दस्तावेज़ बहुत सावधानी से लिखने और सभी को एक दिशा में align करने में भविष्य है। मुझे यह भी लगता है कि सीधे कोड में खोदने की तुलना में productivity बेहतर है। हालाँकि, कोड पर काम करते समय immersion ज़्यादा होता था, लेकिन कई Markdown दस्तावेज़ों के साथ काम करने पर ध्यान ज़्यादा आसानी से बिखर जाता है। सच में दिलचस्प दौर है
ऐसा लग रहा है कि Test-Driven Development की तरह, पहले से system design करवाने वाले patterns फिर से उभर रहे हैं। पहले हम कोड बनाते हुए system को धीरे-धीरे आकार देते थे, लेकिन इस तरह के AI-based development में domain को पहले से design और map किया जाता है, और असली code बस design को लागू करने वाला boilerplate काम बन जाता है। AI ऐसे boilerplate में सच में बहुत मज़बूत है
मैं भी बिल्कुल यही महसूस कर रहा हूँ कि productivity बढ़ी है, लेकिन focus ज़्यादा बिखर रहा है। थोड़ा अजीब है, लेकिन फ़िलहाल असरदार है। लंबे समय में शायद इसका हल ढूँढना पड़ेगा। अभी मेरे लिए सबसे अच्छा तरीका यह है कि कई agents को प्रोजेक्ट के अलग-अलग repositories में अलग tasks करने दिए जाएँ, और मैं लगातार approvals देता रहूँ। यह किसी बड़े team को lead करने वाले project manager जैसा लगता है। फिर भी, सच में दिलचस्प दौर है
यह सच में एक ताज़ा तरीका है। मैं जानना चाहूँगा कि असली प्रयोग में agents चलाने वाला framework क्या है
आजकल मैं भी product details, user journeys वगैरह को voice में रिकॉर्ड करता हूँ, और उसी से technical documentation process शुरू करता हूँ। कम-से-कम CLAUDE.md, software development के लिए Github workflows का उपयोग, लेकिन अच्छा CI workflow बनाना मुश्किल है। मेरी playbook है https://nocodo.com/playbook/
"पहले योजना बनाओ तो नतीजे बेहतर आते हैं"—इस दावे से मैं ख़ास जुड़ नहीं पाता। मैं तो पहले से ही बड़े features या projects के लिए, चाहे दिमाग़ में हो, कागज़ पर हो, Confluence में हो या whiteboard पर, पहले structure, कारण और तरीका सोचता आया हूँ। software engineering का 80% हिस्सा यही है कि ‘क्या, क्यों, और कैसे’ करना है, इस पर सोचना और तय करना। stakeholders के साथ ideas और goals verify करना, research करना—यही सब। आख़िरी 20% ही असली coding है। यह पहले भी ऐसा ही था, और मुझे नहीं पता कि ठीक-ठाक planning या goal definition के लिए AI ज़रूरी भी है या नहीं
बड़े teams या जहाँ culture स्थापित हो, वहाँ ऐसा हो सकता है, लेकिन काफ़ी development individual projects, छोटे teams, side projects, तेज़ POC, और one-off automation tools पर केंद्रित होता है। ऐसे काम अक्सर शुरुआत से documentation/specs/tests के साथ नहीं चलते, बल्कि code, thinking और implementation को मिलाकर आगे बढ़ते हैं। कुछ जगह TDD उपयुक्त है, लेकिन हर जगह ज़रूरी नहीं। लेकिन AI coding agents आने के बाद ideas को स्पष्ट रूप से define करना और specs में बदलना बहुत ज़्यादा महत्वपूर्ण हो गया है। मेरे दिमाग़ में जो कुछ है, उसे शब्दों में उतारना अब उतना ही ज़रूरी हो गया है। आजकल सबसे hot programming language अंग्रेज़ी है
मैं development और design को मिलाकर चलता हूँ। पहले coding शुरू करता हूँ, फिर लगातार refine और evolve करता हूँ। ज़्यादातर मामलों में हल का मोटा तरीका स्पष्ट होता है, इसलिए मुझे नहीं लगता कि गहरी planning पर बहुत समय लगाना ज़रूरी है
पहले prompt engineering मज़ाक की चीज़ थी, लेकिन अब मैं इसे सच में महसूस कर रहा हूँ। cloud code को व्यवस्थित तरीके से इस्तेमाल करने के लिए कभी-कभी मैं 10~20 मिनट तक बहुत सावधानी से prompts और शुरुआती planning पर समय लगाता हूँ। OP की तरह मैं भी plans को files में save करता हूँ और नए context में उन्हें चलाता हूँ। मेरी असली इच्छा एक अच्छे CLI की है (अभी charm और cc इस्तेमाल कर रहा हूँ)। अगर implementation, planning, और हर sub-agent के लिए अलग-अलग models इस्तेमाल किए जा सकें, तो और भी अच्छा हो। जैसे implementation local model से हो, planning cloud model से, या ज़रूरत पड़ने पर swap करके पैसे बचाए जा सकें। Charm अब तक जो मैंने इस्तेमाल किया है, उनमें context loss के बिना आगे-पीछे जाने में सबसे अच्छा है। parallel sub-agents फीचर भी claudecode की सबसे बेहतरीन खूबियों में से एक है। (CCR आज़माया था, लेकिन base model से आगे नहीं जा पाया, इसलिए निराशा हुई)
prompt engineering अभी मुद्दा इसलिए बना है क्योंकि ट्विटर hot takes और content production में यह दिख रहा है। लेकिन असल में prompt engineering पहले से ही महत्वपूर्ण थी। GIGO ("Garbage In, Garbage Out") हर machine learning project का सिद्धांत है। इसलिए मैं सहकर्मियों और दोस्तों से हमेशा कहता रहता हूँ कि “खुद इस्तेमाल करके देखो।” जो 6 महीने पहले नहीं चलता था, वह आज चल सकता है। चीज़ों को हाथ से आज़माने पर ही समझ आता है कि क्या बदला है और क्या संभव है। मुझे negativity से ज़्यादा असली success stories, blog posts, gists और examples ज़्यादा क़ीमती लगते हैं। सिर्फ़ बहुत simple calculations या typos पकड़ने के लिए नहीं, बल्कि तब ज़रूरत है जब यह मेरे workflow को बेहतर बनाए और मेरी मदद करे। prompt engineering वैसा ही है जैसे 10~15 साल पहले Google search में माहिर बनने के लिए लगातार नई चीज़ें और असरदार patterns सीखना
AI के साथ collaborate करना है तो prompt engineering सच में core है
जिन projects में मैंने AI इस्तेमाल किया, वे मेरे सबसे अच्छे documented और tested projects निकले। LLM से performance निकलवाने के लिए context ज़रूरी होता है, इसलिए documentation बेहतर होती है; और test बनाने की लागत कम हो गई है, इसलिए tests ज़्यादा हो गए हैं। कोड quality गिरने की जो भविष्यवाणी की जाती थी, उसके उलट, यह शायद बेहतर ही होगी
ईमानदारी से कहूँ तो "prompt engineering" शब्द नए media का इस्तेमाल करके architecture design करने जैसा है। पहले जिस तरह "diagram design" एक अहम skill हुआ करती थी, उसी तरह अब यह architecture करने का नया तरीका है
मैंने हाल ही में थोड़ी देर Claude Code इस्तेमाल किया और सुझाया गया workflow आज़माने वाला हूँ। तरीका काफ़ी अच्छा लगता है। लेकिन CC की लागत उम्मीद से ज़्यादा है। एक simple refactoring के लिए 5 मिनट का काम और 15 मिनट की review में ही 4 डॉलर लग गए। अगर मैं खुद करता तो 15~20 मिनट में हो जाता। आम तौर पर एक feature पर CC से कितना खर्च आता है, यह जानना चाहता हूँ। कोई pricing की बात नहीं करता
subscription लेने पर $20~$200 का flat charge होता है, और उसके साथ daily/weekly token usage limits मिलती हैं। https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
AI investors जिस दिशा की उम्मीद कर रहे हैं, वह यह है कि labor market को AI 15% margin पर replace करे। ऐसा दौर आ सकता है जहाँ developer budget और AI budget 1:1 हो जाएँ। उदाहरण के लिए, 100k डॉलर सालाना कमाने वाले एक senior developer की जगह 100k डॉलर का AI budget ले ले। AI budget development cost से निकलेगा, senior salaries नीचे जा सकती हैं, और development teams का आकार तेज़ी से घट सकता है। अभी तो यह VC द्वारा पूरी तरह subsidized 'territory capture' phase है, लेकिन ट्विटर VC माहौल देखकर लगता है कि यह चरण जल्द ख़त्म हो सकता है। 9 महीने की runway के लिए 500 million डॉलर बार-बार जुटाने की भी एक सीमा है
Cursor से Claude Code पर कुछ काम shift करने के बाद costs बहुत बढ़ गई हैं। कंपनी में ज़्यादातर इस्तेमाल करने से boss को मनाना आसान था, लेकिन side projects में सोचना पड़ता है। मज़े-मज़े में app bootstrap करने पर हर बार 20 डॉलर खर्च नहीं करना चाहता
आप Sonnet (€20/माह) और Opus (€100/माह) इन दो models में से चुनकर subscribe कर सकते हैं। मैंने Sonnet से शुरू किया था और बाद में Opus पर गया। Sonnet भी काफ़ी usable है। token limits के भीतर मेरे use case के लिए यह अभी तक पर्याप्त रहा है। लेकिन आगे भी ऐसा रहेगा या नहीं, इसका भरोसा नहीं
आपने कहा, "अगर मैं खुद करता तो 15~20 मिनट में हो जाता"—तो क्या यह नहीं हो सकता कि वे 15~20 मिनट आप किसी और काम में लगा सकें?
Visual Studio Code/ChatGPT5 preview का combination इस्तेमाल करने का तरीका मेरे workflow से मिलता-जुलता है {शायद मैं Github Copilot subscription के ज़रिए भुगतान कर रहा हूँ, लेकिन आजकल पक्का नहीं हूँ}। मुझे लगता है कि non-agent LLMs में code जल्दी बिगड़ने की प्रवृत्ति ज़्यादा होती है। agent mode इस्तेमाल करने पर code construction पूरी तरह बदल जाता है। मैं Python developer नहीं हूँ, लेकिन LLM को नया code dump बनाते देखकर सच में काफ़ी प्रभावित हुआ। पूरा होने के बाद मैं BitGrid में छोटे LLMs चलाकर बाद में code को पूरी तरह समझने का सोच रहा हूँ। मेरा तरीका यह है कि छोटे-छोटे exploratory steps दोहराऊँ, और पूरी design को अपने मनमुताबिक बनाए रखने के लिए सिर्फ़ कुछ edits करूँ। इसने मुझे यक़ीन दिलाया है कि भविष्य में LLMs programming partner बनेंगे। क्या और लोग भी Visual Studio Code/ChatGPT5 combination इस्तेमाल कर रहे हैं?
यह दिलचस्प है कि AI tools को optimize करते-करते developers शायद 'अच्छी communication' और 'expectation setting' की value फिर से खोज रहे हैं। अब तक की 10x developer वाली छवि—यानी अकेला, अजनबी या सनकी genius—पर दोबारा सोचने का समय है
Replit में भी मेरा ऐसा ही अनुभव रहा है। जैसे-जैसे app का आकार बढ़ता है, अगर design docs tasks और source of truth नहीं बनते, तो सब जल्दी बिखर जाता है। OpenAI में chat धीमी हो जाती है और जल्दी अटक जाती है, इसलिए documents अलग से बनाकर नए chat में import करना मददगार होता है। इंसानी स्तर पर भी मुझे लगता है कि हमें भी ऐसा ही करना चाहिए। खुद पर reflection करके documentation करना और 'memory' को design docs में दर्ज करना, हम और LLM—दोनों को ज़्यादा स्वतंत्र बना सकता है
मैंने भी हाल ही में यह workflow खोजा और बहुत हैरान हुआ। अहम बात यह है कि claude को सिर्फ़ minimum requirements दें और plan mode को खुलकर चलने दें। अगर मामला sales metrics report का हो, तो सिर्फ़ "Ultrathink relevant sales metrics" कहने पर भी यह तरह-तरह के metrics सुझा देता है और उन्हें rank करके चुनने में मदद करता है। हर नए feature के लिए अलग directory बनाओ, और उस feature की plan फ़ाइल लिखवाओ। उसके बाद implementation plan, ज़रूरी data queries, असली implementation, tests, user docs—सब कुछ step-by-step करवाओ, और फिर QA को भेजो। पहले sales forecasting feature जैसा कुछ बनाने के लिए बड़ी टीम और काफ़ी समय चाहिए होता था, लेकिन claude ने आधे दिन में इसे docker container के रूप में बना दिया। इस बदलाव से software को लेकर मेरा नज़रिया बदल रहा है। पहले NDA, IP वगैरह के कारण कंपनियाँ source code कभी बाहर नहीं आने देती थीं। लेकिन अब 20 साल में बने complex ERP systems भी claude तेज़ी से फिर से implement कर सकता है और उनके साथ docs व tests भी जोड़ सकता है। व्यवहार में यह अभी परफ़ेक्ट नहीं है, लेकिन progress सच में बहुत तेज़ है
Claude Code से अच्छे features निकलवाने के लिए पहले सही plan लिखना ही कुंजी है। हाल में मैं Cursor में GPT-5 High से plan बनवाता हूँ, फिर उसे Claude Code में डालकर implement करवाता हूँ। अगर codebase में किन हिस्सों को बदलना है, इसे पहले document करवा लें, तो 15~20% तक और अच्छे नतीजे मिल सकते हैं। अगर plan model working methods, architecture, patterns, और feature design तक को document करे, तो output बेहतर आता है। और अंत में, docs और plans को खुद review और edit करना भी बहुत मददगार है
क्या किसी ने इस process में frontend design को सुंदर तरीके से शामिल करने का अच्छा तरीका खोजा है? ज़्यादातर लोग बस frontend frameworks का नाम लेते हैं या figma images तक सीमित रहते हैं। उससे integrated design solution जैसी भावना नहीं आती