CLAUDE के साथ सॉफ़्टवेयर बनाना
ब्रेनस्टॉर्म-टू-स्पेक वर्कफ़्लो, टूलचेन, और वह फैसले जो AI नहीं ले सकता। HostList.io, gautamkhorana.com, और Seahawk क्लाइंट प्रोडक्ट्स को शिप करने से सीखे गए।
← Guides All guides in this topic
on this page
- यह गाइड क्यों है
- ब्रेनस्टॉर्म-टू-स्पेक वर्कफ़्लो
- Claude किस चीज़ में बेहतरीन है और किसमें नहीं
- वह टूलचेन जो मैं वास्तव में इस्तेमाल करता हूँ
- Repository discipline जो AI-assisted development में survive करती है
- वे product निर्णय जो AI नहीं ले सकता
- विशिष्ट projects जो मैंने इस तरीके से शिप किए हैं
- निचली पंक्ति
यह गाइड क्यों है
2026 में Claude को प्राथमिक इंजीनियरिंग सहयोगी के रूप में सॉफ़्टवेयर बनाना कॉस्ट कर्व और टीम की शेप बदलता है, अंतर्निहित शिल्प को नहीं। सॉफ़्टवेयर के जज़्मेंट-हेवी हिस्से (क्या बनाना है, क्यों, विफलता के तहत यह कैसे काम करे) को अभी भी मानवीय ध्यान की ज़रूरत है। एक्सीक्यूशन के हिस्से (कोड लिखना, रीफैक्टरिंग, बॉयलरप्लेट जनरेट करना, माइग्रेशन चलाना) नाटकीय रूप से कम हो जाते हैं। यह जानना कि कौन सा कौन सा है — 2026 में पूरी स्किल यही है।
यह गाइड वह वर्कफ़्लो है जो मैं Seahawk Media पर और HostList.io, gautamkhorana.com, और Deluxe Astrology जैसे पर्सनल प्रोजेक्ट्स पर कस्टम प्रोडक्ट्स शिप करने के लिए असली में इस्तेमाल करता हूँ। Claude ट्यूटोरियल नहीं, प्रॉम्प्ट-इंजीनियरिंग मैनुअल नहीं। वह प्रोसेस डिसिप्लिन जो Claude को लोड-बेयरिंग इंजीनियर के रूप में शिप्पेबल सॉफ़्टवेयर देता है।
ब्रेनस्टॉर्म-टू-स्पेक वर्कफ़्लो

स्टेज 1: स्ट्रक्चर्ड ब्रेनस्टॉर्म
किसी भी कोड को लिखने से पहले मैं Claude के साथ एक संरचित ब्रेनस्टॉर्म चलाता हूँ। प्रॉम्प्ट: समस्या को सादी भाषा में बताएँ, Claude को पाँच ऐसे सवाल सामने लाने को कहें जिनके जवाब डिजाइन को बदल देंगे, उन्हें जवाब दें, फिर Claude को 200 शब्दों में उत्पन्न प्रोडक्ट स्पेक को सारांशित करने को कहें। यह स्टेज 30 से 60 मिनट लेता है और एक लिखित स्पेक तैयार करता है जिससे बाकी काम निकलता है।
स्टेज 2: तकनीकी फैसले
स्पेक हाथ में आने के बाद, मैं Claude से कहता हूँ कि वह आर्किटेक्चर के उन चुनावों को पहचाने जिनका डाउनस्ट्रीम में सबसे ज्यादा इस्तेमाल होगा। डेटाबेस शेप, API सरफेस, रेंडरिंग स्ट्रेटेजी, डिप्लॉयमेंट मॉडल। हर एक के लिए Claude दो या तीन विकल्प और उनके ट्रेड-ऑफ्स सुझाता है। मैं चुनता हूँ। फैसले उसी डॉक्यूमेंट में लिख दिए जाते हैं ताकि बिल्ड फेज के पास सच्चाई का एक ही स्रोत हो।
स्टेज 3: स्पेक-संचालित कार्यान्वयन
कोड जनरेशन आखिरी स्टेज है, और यह सबसे तेज़ है क्योंकि स्पेक पहले से पूरा है। Claude स्कीमा, क्वेरीज़, कॉम्पोनेंट, रूट्स, टेस्ट लिखता है, मोटे तौर पर उसी क्रम में। मैं हर कमिट की समीक्षा करता हूँ। ज्यादातर समीक्षाएँ एक छोटे रीफैक्टर या एक मिस्ड एज केस को सामने लाती हैं; पूरे रीराइट दुर्लभ होते हैं जब स्पेक स्पष्ट था।
मुख्य बात: "ब्रेनस्टॉर्म-टू-स्पेक वर्कफ़्लो" को सबसे पहले एक ऑप्स निर्णय मानें। टूलिंग तभी काम करती है जब स्वामित्व ईमानदार हो।
Claude किस चीज़ में बेहतरीन है और किसमें नहीं
बेहतरीन है
ग्रीनफील्ड कोड अच्छी तरह से ज्ञात पैटर्न में: REST APIs, CRUD एडमिन पैनल, ऑथ फ्लोज़, ब्लॉग इंजन, मार्केटिंग साइट्स। मौजूदा कोड का रीफैक्टरिंग जहाँ टार्गेट आकार स्पष्ट रूप से बताया गया हो। उस कोड के लिए टेस्ट जेनरेट करना जिसके स्पष्ट इनपुट और आउटपुट हों। माइग्रेशन स्क्रिप्ट लिखना जब स्कीमा डिफ स्पष्ट हो। दस्तावेज़ीकरण का मसौदा तैयार करना। कोड में डिबग करना जहाँ लक्षण दोहराया जा सकता है और ट्रेस कॉन्टेक्स्ट में हो।
कम बेहतरीन है
अपरिचित डोमेन में आर्किटेक्चरल फैसले। इंटीग्रेशन कोड जहाँ थर्ड-पार्टी API खराब दस्तावेज़ित हो या हाल ही में बदला गया हो। परफॉर्मेंस ऑप्टिमाइज़ेशन जहाँ बॉटलनेक स्पष्ट न हो। कोड जेनरेशन अस्पष्ट भाषाओं या फ्रेमवर्क में जहाँ ट्रेनिंग डेटा कम हो। कुछ भी जहाँ आवश्यकताएँ अस्पष्ट हों और LLM ऐसे प्रशंसनीय-ध्वनि वाले डिफॉल्ट भर देगा जो आपके विशेष मामले के लिए गलत हों।
निर्णय का अंतराल
Claude कोड की अगली लाइन लिखने में माध्य इंजीनियर से लगातार बेहतर है। अगली लाइन कोड को अस्तित्व में आना चाहिए या नहीं, यह तय करने में Claude एक सीनियर इंजीनियर से लगातार खराब है। सीनियर निर्णय परत वह है जो आप लाते हैं। एक्सीक्यूशन की गति वह है जो Claude लाता है। यह संयोजन अकेले किसी को भी हरा देता है।
वह टूलचेन जो मैं वास्तव में इस्तेमाल करता हूँ
प्राथमिक सतह के रूप में Claude Code
Claude Code विकास के लिए AI-असिस्टेड IDE है। प्रोजेक्ट कॉन्टेक्स्ट एक बार लोड होता है, टर्मिनल एक्सेस, फाइल सिस्टम एक्सेस, MCP टूल इंटीग्रेशन। 2025 में मेरे स्टैक में जोड़ा गया सबसे ज्यादा इस्तेमाल होने वाला टूल। अब ज्यादातर इंजीनियरिंग काम Claude Code में होता है, न कि सीधे VS Code या Cursor में।
सीधे एडिटर संपादन के लिए Cursor
Cursor एक बार एक फाइल पर AI के साथ काम करने के लिए अभी भी सबसे अच्छा एडिटर अनुभव है। Tab completion, inline edits, side-by-side diff। मैं Cursor का उपयोग करता हूँ जब काम एक या दो फाइलों पर केंद्रित हो; मैं Claude Code में स्विच करता हूँ जब काम पूरे प्रोजेक्ट में फैला हो।
बैच काम के लिए API के माध्यम से Claude Sonnet
जब मुझे सैकड़ों पृष्ठों को प्रोग्रामेटिकली जनरेट या फिर से लिखना होता है (auto-blog pipeline, content humanisation, schema generation), मैं Claude API को सीधे Sonnet के माध्यम से कॉल करता हूँ। चैट सतह की तुलना में कम latency, अनुमानित लागत, scriptable। विशेष रूप से content pipelines के लिए सही टूल।
प्रॉम्प्ट इंजीनियरिंग के लिए OpenAI GPT-4o
मेरी खोज देर 2025 में यह थी कि Kimi, Minimax, या किसी भी अन्य agent के लिए prompts को Claude या GPT द्वारा लिखा जाना चाहिए, हाथ से नहीं। मैं goal describe करता हूँ, GPT-4o से prompt लिखने के लिए कहता हूँ, फिर वह prompt executor के विरुद्ध चलाता हूँ। output quality hand-prompted equivalents से materially बेहतर है।
Kimi Researcher और Minimax Agent
क्रमशः deep research और full-app design mockups। /blog/kimi-minimax-deep-research-design-mockups/ post पूरे workflow को cover करती है। Seahawk में client research और rapid prototyping के लिए दोनों load-bearing tools हैं।
Repository discipline जो AI-assisted development में survive करती है
छोटे commits, descriptive messages
AI-assisted development बड़े diffs produce करता है क्योंकि एक commit में 800 lines का generated code ship करना आसान है। अपने आप को अनुशासित करें कि छोटे commits करें। एक commit message जो बताती है कि क्या बदला और क्यों, यह एकमात्र artifact है जो future-you के पास regression को debug करने के लिए होगी। इसे readable बनाएँ।
Tests as the contract
Claude ऐसा code लिख सकता है जो compile और run तो करता है लेकिन चुप चाप एक constraint को violate करता है जो spec में implicit था। Tests जो उन constraints को executable contracts के रूप में encode करते हैं, violations को catch करते हैं। test-first discipline AI-assisted era में उससे कहीं अधिक मायने रखती है जब humans हर line लिखते थे।
Code review अभी के लिए human-only है
मैं Claude को अपने pull requests को approve नहीं करने देता। review gate सबसे महत्वपूर्ण quality control है जो humans के पास बचा है, और इसे उसी model को outsource करना जिसने code लिखा था, purpose को defeat करता है। Anthropic SDK और Claude Code workflows AI-assisted review को आसान बनाते हैं, लेकिन final approval मेरी है।
संस्करणित निर्भरताएं और लॉकफाइलें
हर निर्भरता को pin करें। Lockfiles का उपयोग करें। हर बिल्ड पर npm audit चलाएं। Supply-chain attack का सतह वास्तविक है और AI-सहायता प्राप्त विकास में आम तौर पर मानव-लिखित समकक्षों की तुलना में अधिक निर्भरताएं जोड़ी जाती हैं क्योंकि एक पैकेज जोड़ना तेज़ है। Lockfile अनुशासन सतह को auditable रखता है।
मुख्य बात: "रिपॉजिटरी डिसिप्लिन जो एआई-असिस्टेड डेवलपमेंट में टिकी रहे" को सबसे पहले एक ऑप्स निर्णय मानें। टूलिंग तभी काम करती है जब स्वामित्व ईमानदार हो।
वे product निर्णय जो AI नहीं ले सकता
| If this is true | Do this | Avoid |
|---|---|---|
| Team and ops are clear | Pick the boring default for that ops model | Chasing the trend stack |
| Budget is thin over 3 years | Optimise hosting and scope first | Full re-platform for vanity perf |
| Editors ship weekly | Prioritise CMS and workflow fit | Engineer-only content pipelines |
| Product state is real | Choose an app framework with eyes open | Stretching a brochure CMS |
निर्णय की पाँच श्रेणियाँ जहाँ Claude गलत उपकरण है:
बिल्कुल क्या बनाना है। Product निर्णय निर्णय-भारी है, उपयोगकर्ता संदर्भ पर निर्भर है जो Claude के पास नहीं है, और किसी भी product में सबसे महत्वपूर्ण निर्णय है। संस्थापक और PM इसके मालिक हैं; AI सर्वोत्तम रूप से सहायता करता है।
क्या लॉन्च करना है और क्या काटना है। एक बिल्ड के दौरान scope निर्णय हमेशा उन बाधाओं तक आते हैं जो मॉडल नहीं देखता है। समय का दबाव, टीम की मनोबल, भागीदार संबंध, विपणन स्थिति। मानव के रूप में निर्णय लें, तर्क को दस्तावेज़ करें, फिर Claude से निर्णीत scope को निष्पादित करने के लिए कहें।
विफलता मोड डिज़ाइन। सिस्टम को गलत होने पर कैसे व्यवहार करना चाहिए यह शायद ही कभी शुरुआत में निर्दिष्ट होता है और यह वह जगह है जहाँ अधिकांश उत्पादन घटनाएं उत्पन्न होती हैं। विफलता मोड पर अनुपातहीन समय व्यय करें; वे happy-path code generation से स्वाभाविक रूप से नहीं उभरेंगे।
नैतिकता परत। आप जो बनाते हैं उसके निहितार्थ हैं। गोपनीयता, data निवास, सुलभता, पर्यावरणीय लागत। ये मानव निर्णय हैं, अनुकूलन आउटपुट नहीं। डिज़ाइन समय पर प्रश्न को स्पष्ट रूप से पूछें।
दीर्घकालीन रखरखाव। भविष्य-स्व भविष्य-Claude को पढ़ रहा है वर्तमान-Claude के कोड को पढ़ रहा है यह तकनीकी debt का सबसे गहरा संस्करण है। वर्तमान कोड को मानव पहले, AI दूसरे द्वारा पठनीय होने के लिए अनुकूलित करें।
विशिष्ट projects जो मैंने इस तरीके से शिप किए हैं
पिछले बारह महीनों में Seahawk और व्यक्तिगत रूप से मिले ठोस उदाहरण:
HostList.io (Next.js + Supabase पर 28,000 प्रोग्रामेटिक पेज): Claude Code से पाँच दिनों में स्केफोल्ड किया गया, Tavily रिसर्च इंटीग्रेशन के साथ Claude द्वारा लिखा गया कंटेंट पाइपलाइन, FAL से हीरो जनरेशन, ऑटो-जनरेटेड स्कीमा मार्कअप। कुल इंजीनियरिंग टाइम मोटे तौर पर उससे एक तिहाई था जितना मैंने तीन साल पहले अनुमान लगाया होता।
gautamkhorana.com (यह साइट, Astro + Supabase पर): एक 24 घंटे के सप्ताहांत पर Claude Code को प्राथमिक सहयोगी के रूप में पुनर्निर्मित किया गया। साइट एडिटर सरफेस, ब्लॉग सिस्टम, स्कीमा लेयर, i18n, सब कुछ जनरेट, रिव्यू और रीफैक्टर किया गया। इस गुणवत्ता की व्यक्तिगत साइट बनाने की कीमत सप्ताहांत के केंद्रित समय तक गिर गई।
Deluxe Astrology ऑटो-ब्लॉग और ट्रांसलेशन पाइपलाइन: Tavily-रिसर्च-से-Claude-ड्राफ्ट-से-Winston-चेक-से-FAL-हीरो-से-Supabase-पब्लिश लूप 30 भाषाओं में 91,000+ पेजों पर रोज चलता है। पाइपलाइन खुद मोटे तौर पर 800 लाइनें कोड हैं जो Claude ने लगभग 12 घंटे के केंद्रित काम में लिखीं, जिसमें से अधिकांश मानव-केवल टीम के साथ एक हफ्ता लगता।
Seahawk पर आंतरिक एडमिन डैशबोर्ड: Minimax Agent छः-लाइन के विवरण से पहला प्रोटोटाइप बनाता है, Claude इसे परिष्कृत करता है, परिणाम एक घंटे में शिप करने योग्य होता है। "हमें एक आंतरिक टूल चाहिए" से "हम आंतरिक टूल का उपयोग कर रहे हैं" तक का समय दिनों से घटकर एक कामकाजी दिन से कम हो गया।
निचली पंक्ति
2026 में कस्टम सॉफ्टवेयर बनाना एक ऐसी कला है जो एक्जीक्यूशन स्पीड पर एक परिमाण कम हुई है और जज्मेंट कॉम्प्लेक्सिटी पर मोटे तौर पर स्थिर रही है। जो टीमें अनुकूल होती हैं वे अधिक जज्मेंट लाती हैं (बेहतर स्पेक्स, बेहतर आर्किटेक्चरल विकल्प, बेहतर फेलियर-मोड डिज़ाइन) और AI को अधिक एक्जीक्यूशन सौंपती हैं। जो टीमें अनुकूल नहीं होती हैं वे प्रतिस्पर्धी गति पर सॉफ्टवेयर बनाती हैं लेकिन गुणवत्ता पर हार जाती हैं, या इसके विपरीत।
आपको इस गाइड के हर टूल का उपयोग करने की जरूरत नहीं है। आपको यह जानना जरूरत है कि कौन से निर्णय आपके हैं और कौन से सौंपे जा सकते हैं। कौशल सीमा है, टूलचेन नहीं।
अगर आप इस कॉस्ट कर्व पर कस्टम सॉफ्टवेयर प्रोजेक्ट शिप करने में मदद चाहते हैं, तो हम Seahawk Media में प्रोडक्ट बिल्ड चलाते हैं। बातचीत मुफ्त है; प्रोजेक्ट प्राइसिंग AI-असिस्टेड कॉस्ट रिएलिटी को दर्शाती है, न कि 2018 की घंटेदारी कॉस्ट रिएलिटी को।
मुख्य बात: "बॉटम लाइन" को सबसे पहले एक ऑप्स निर्णय मानें। टूलिंग तभी काम करती है जब स्वामित्व ईमानदार हो।