← वापस मैं एक संस्थापक के रूप में Claude Code को रोज़ कैसे इस्तेमाल करता हूँ जो अभी भी Ship करता है -- line-art illustration

मैं Claude Code का उपयोग रोज़मर्रा कैसे करता हूँ, एक संस्थापक जो अभी भी कोड शिप करता है

टूल्स

तीन महीने पहले मैं एक दूसरे बैकएंड डेवलपर को नियुक्त करने वाला था। हमारे पास एक शर्मनाक backlog था, चौदह features जो क्लाइंट्स को promise किए गए थे, दो लोग बुरी तरह stretched थे, और मैं sales calls और pull requests के बीच context-switch कर रहा था जैसे कोई शुद्ध मूर्ख। फिर मैंने Claude Code को सही तरीके से इस्तेमाल करना शुरू किया। बस functions को chat window में paste करने की नहीं। मतलब इसे असली daily flow में integrate करना। हमने वह backlog छह हफ्तों में clear कर दिया। मैंने दूसरे डेवलपर को नियुक्त नहीं किया।

यह एक पिच नहीं है। यह सिर्फ वह है जो हुआ।

"सही तरीके से" का असल अर्थ क्या है

जो लोग मुझसे मीटअप में बात करते हैं उनमें से अधिकांश AI कोडिंग उपकरणों का उपयोग समान आलसी तरीके से कर रहे हैं। एक फंक्शन पेस्ट करते हैं, कुछ वापस पाते हैं, इसे अपने एडिटर में पेस्ट करते हैं, यह टूट जाता है, वे हार मान देते हैं। यह कोई वर्कफ्लो नहीं है। यह निराशा है।

मेरे लिए सही तरीका यह है कि Claude Code मेरे terminal में Claude Code CLI के ज़रिये रहता है, सीधे मेरे असली repo पर काम कर रहा है, असली files को पढ़ रहा है, sanitised snippets नहीं। फर्क बहुत बड़ा है। जब इसके पास एक 4,000-line WordPress plugin का पूरा context हो जो हमने साल भर पहले एक अमेरिकी healthcare क्लाइंट के लिए बनाया था, तो output usable होता है। जब यह 40-line paste से अंधे में काम कर रहा हो, तो यह सिर्फ अनुमान लगा रहा है।

मैं इसे एक MacBook Pro M3 पर चलाता हूँ। मेरा editor अभी भी VS Code है usual suspects के साथ, Prettier, ESLint, GitLens। Claude Code उनमें से किसी को replace नहीं करता। यह उनके साथ-साथ बैठता है।

Setup जो मैं असल में use करता हूँ

  • Claude Code CLI को npm के through globally install किया
  • प्रत्येक प्रोजेक्ट रूट में एक .claude निर्देशिका एक CLAUDE.md फाइल के साथ, यह मूलतः एक संक्षिप्ति है जो मैं Claude के लिए प्रोजेक्ट के बारे में लिखता हूँ: स्टैक, परंपराएँ, क्या नहीं छूना है।
  • iTerm2 split panes: बाईं ओर code, दाईं ओर Claude session
  • Claude द्वारा generate किए गए हर change के बाद Git commits करता हूँ, कोई exception नहीं। मुझे झलक मिल चुकी है।

वह अंतिम बिंदु। 2022 में एक क्लाइंट प्रोजेक्ट, मैनचेस्टर-आधारित फर्नीचर रिटेलर के लिए Shopify माइग्रेशन, मैंने तीन घंटे की AI-सहायता संपादन जमा होने दी बिना कमिट किए। पूरा सेशन खराब हो गया। छह घंटे का काम खो गया। अब मैं जुनून से कमिट करता हूँ, लगभग न्यूरोटिक रूप से। Claude Code हो या नहीं।

Morning Routine (यह जानबूझकर बेहद specific है)

मैं 8:30 तक office में होता हूँ। Exmouth Market की जगह से कॉफ़ी। मैं Notion खोलता हूँ, देखता हूँ कि आज के लिए board पर क्या है, फिर अपना terminal खोलता हूँ।

मैं हर सुबह Claude Code के साथ जो पहली चीज़ करता हूँ वह है जिसे मैंने "कॉन्टेक्स्ट डंप" कहना शुरू किया है। मैं प्रोजेक्ट खोलता हूँ, claude चलाता हूँ और इसे एक पैराग्राफ देता हूँ कि मैंने पिछले दिन कहाँ छोड़ा था। यह हाल की git diff को अपने आप पढ़ता है। इसमें करीब तीन मिनट लगते हैं और इसका मतलब है कि मैं बीस मिनट अपना कोड फिर से पढ़ने में नहीं बिता रहा हूँ यह याद करने के लिए कि मैं क्या कर रहा था। यह अकेले ही सबस्क्रिप्शन की कीमत है।

फिर मैं काम करता हूँ। मैं Claude से features scratch से लिखने के लिए नहीं कह रहा हूँ, हालाँकि कभी-कभी करता हूँ। ज़्यादातर मैं उससे वह चीजें करने के लिए कह रहा हूँ जो मुझे slow down करती हैं लेकिन zero creativity की जरूरत होती है।

जैसे:

  • उन functions के लिए PHPUnit test cases लिखना जो मैंने पहले से लिख दिए हैं
  • एक JSON response से TypeScript interfaces generate करना जो मैं paste करता हूँ
  • एक 300-लाइन कंपोनेंट को रीफैक्टर करना जिसे मैं जानता हूँ कि विभाजित करने की ज़रूरत है लेकिन सोचना नहीं चाहता।
  • Internal APIs के लिए first-draft documentation

इनमें से कुछ भी exciting नहीं है। सब कुछ पहले एक घंटा खा जाता था जो मेरे पास नहीं था।

यह वास्तव में कहाँ समय बचाता है (Numbers के साथ)

Seahawk ने मेरे रहते हुए 5,000 से अधिक साइटें बनाई थीं। इसका एक बड़ा हिस्सा WordPress, थीम, प्लगइन, WooCommerce कस्टमाइजेशन था। WordPress विकास में कार्यों की एक श्रेणी है जो बेहद उबाऊ है लेकिन तकनीकी रूप से सटीक है: कस्टम हुक लिखना, REST API एंडपॉइंट पंजीकृत करना, Settings API के साथ सेटिंग्स पेज बनाना।

मैंने इसे पिछले महीने समय दिया। शून्य से WooCommerce कस्टम शिपिंग मेथड क्लास लिखना: ऐतिहासिक रूप से मुझे परीक्षण सहित लगभग 45 मिनट लगते हैं। Claude Code को scaffold करते समय मैं सादे अंग्रेजी में व्यावसायिक तर्क का वर्णन करता हूँ: 12 मिनट। और scaffold अच्छा है, यह WordPress कोडिंग मानकों का पालन करता है क्योंकि मैंने अपने CLAUDE.md में यह बताया था।

यह 10% बेहतर नहीं है। यह स्पीड की बिल्कुल अलग कैटेगरी है।

असली बचत context-switching की कॉस्ट में है। जब मैं किसी फीचर के बीच होता हूँ और कोई क्लाइंट बिल्कुल अलग प्रोजेक्ट पर बग के बारे में पिंग करता है, तो मैं या तो क्लाइंट को ignore करता था (बुरा) या अपना पूरा focus खो देता था (यह भी बुरा)। अब मैं Claude से कहता हूँ कि एक डिटेल्ड comment block लिखे जो बताए कि हम इस टास्क में कहाँ हैं, फिर बग पर जाता हूँ, उसे fix करता हूँ, वापस आता हूँ, comment पढ़ता हूँ, और करीब चार मिनट में फिर से शुरू करता हूँ। पहले यह रिकवरी मुझे बीस मिनट का नुकसान करती थी।

यह कहाँ टूटता है

ईमानदारी से कहूँ तो। और यह जीत से ज्यादा matter करता है।

Claude Code वाकई किसी भी चीज़ में बुरा है जहाँ किसी निर्णय को ऐतिहासिक रूप से क्यों लिया गया था यह समझना ज़रूरी हो। हमारे पास Seahawk में एक fintech प्रोजेक्ट था, एक London-आधारित payments startup के लिए एक dashboard, जहाँ state management का एक विशेष रूप से जटिल हिस्सा एक ऐसे कारण से मौजूद था जो हमारे involvement से पहले का था। उनके legacy API के batching responses में कोई edge case। Claude इसे लगातार "ठीक" करने की कोशिश कर रहा था। हर सुझाव technically ज़्यादा साफ़ था और पूरी तरह ग़लत था। इसे नहीं पता था कि इसे क्या नहीं पता है।

यह विफलता का तरीका है जिसके बारे में कोई काफ़ी बात नहीं करता। आउटपुट सही दिखता है। यह बुनियादी समीक्षा पास करता है। और फिर यह गुरुवार की शाम को प्रोडक्शन में टूट जाता है जब कोई यूज़र उस एज केस को हिट करता है।

मेरा अब का नियम: Claude Code उन चीजों को नहीं छूता जहाँ comment में "don't change this without asking Ravi" लिखा हो। (Ravi हमारे lead backend dev हैं।) बिल्कुल निश्चित।

इसके अलावा यह badly struggle करता है:

  1. Multi-file refactors में जहाँ dependency chain तीन levels से ज्यादा हो
  2. तीसरे पक्ष के किसी SDK के साथ कुछ भी involve करना जो दो साल से कम पुराना है, यह आत्मविश्वास से method names का hallucinate करता है।
  3. CSS जो डिज़ाइनर के pixel-perfect कंप के साथ match करनी है (बस ज़रा-सी ख़राबी होती है, फिर छोटी-मोटी errors से पागलपन आता है)
  4. Performance optimisation जहाँ bottleneck स्पष्ट नहीं है, यह ग़लत चीज़ को optimize करता है।

विशेष रूप से दूसरे बिंदु पर: मैं जनवरी में एक Next.js प्रोजेक्ट में Resend API को एकीकृत कर रहा था। Claude बार-बार एक .send() मेथड को संदर्भित कर रहा था जो Resend Node SDK में मौजूद नहीं है। Claude की आत्मविश्वासी गलतता को डीबग करने में मुझे उतना ही लंबा समय लगा जितना कि खुद डॉक्स पढ़ने में लगता। सबक सीखा। किसी भी SDK के लिए, मैं पहले असली README को कॉन्टेक्स्ट विंडो में पेस्ट करता हूँ।

वे Prompt पैटर्न जो वास्तव में काम करते हैं

मैंने इस पर महीनों तक काम किया है। ख़राब prompts से ख़राब output मिलता है। यहाँ मेरे निष्कर्ष हैं।

Senior dev बनो, intern नहीं। "मुझे एक function लिखो जो X करे" मत कहो। "मुझे X implement करना है। Constraint ये है: Y। जो चीज़ें मैंने rule out कर दी हैं: Z। तुम्हारा approach क्या है कुछ लिखने से पहले?" कहो। इसे सोचने दो। उस बातचीत के बाद output dramatically बेहतर होता है।

इसे एक persona दो जिसके stakes हों। मैं literally लिखता हूँ: "तुम एक senior WordPress developer हो जो security vulnerabilities introduce न करने की गहरी परवाह करता है। Client एक healthcare company है। Sanitisation और nonce verification को सबसे ऊपर रखो।" क्या ये silly लगता है? हाँ। क्या काम करता है? भी हाँ।

Output का format specify करो। "मुझे सिर्फ function दो, कोई explanation नहीं" या "Function दो, फिर एक bullet list जो मुझे manually verify करना चाहिए।" Unstructured output समय ख़राब करता है।

एक pattern जिसके लिए मैं लगातार reach करता हूँ:

  1. Goal को एक वाक्य में describe करो
  2. प्रासंगिक मौजूदा कोड को एक टिप्पणी के साथ पेस्ट करें जो इसके उद्देश्य की व्याख्या करे
  3. बाधा बताएँ ("PHP 7.4 के साथ backwards compatible होना चाहिए")
  4. पहले approach माँगें, फिर कोड माँगें
  5. दृष्टिकोण की समीक्षा करें, आवश्यकता पड़ने पर असहमति जताएँ, फिर कोड माँगें

पाँच steps। ओवरहेड लगता है। हर बार मुझे पंद्रह मिनट खराब कोड से बचाता है।

यह कैसे बदल गया है कि मैं क्या काम सौंपता हूँ

यह वह हिस्सा है जिसने मुझे सबसे ज्यादा हैरान किया। Claude Code ने सिर्फ मुझे तेज़ नहीं बनाया। इसने बदल दिया कि मैं जूनियर डेवलपर्स को क्या सौंपता हूँ।

पहले, Seahawk में एक junior dev अपने पहले दो हफ्तों में बस हमारे कन्वेंशन और स्टैक से परिचित होने में बिताते थे। बाद में, मैं उन्हें एक अच्छी तरह लिखित CLAUDE.md के साथ एक प्रोजेक्ट देता और उन्हें कहता कि Claude Code का उपयोग करके स्कैफोल्ड कोड जेनरेट करें, फिर इसे कन्वेंशन के विरुद्ध समीक्षा करें। वे तीन हफ्तों की बजाय तीन दिनों में असली काम योगदान दे रहे होते थे।

CLAUDE.md फ़ाइल वह mentoring कर रही है जो मैं hourly walkthroughs में किया करता था। यह एक meaningful shift है। इसलिए नहीं कि मैं mentor नहीं करना चाहता, मैं चाहता हूँ, लेकिन अब mentoring conversations decisions और trade-offs के बारे में हैं, "हर फ़ॉर्म में wp_nonce_field() का उपयोग करना याद रखो" के बारे में नहीं।

Anthropic मॉडल स्पेक डॉक्यूमेंटेशन पढ़ने लायक है अगर आप जानना चाहते हैं कि Claude किन सीमाओं के भीतर काम करता है, इन्हें समझना आपको इसकी प्रवृत्तियों के साथ काम करने में मदद देता है, उनके विरुद्ध नहीं।

संस्थापक-विशिष्ट दृष्टिकोण

AI कोडिंग टूल्स के बारे में ज्यादातर लेख डेवलपर्स के लिए लिखे जाते हैं। ठीक है। लेकिन एक विशिष्ट संस्थापक समस्या है जिसे Claude Code संबोधित करता है और मैंने इसे अच्छी तरह से व्यक्त होते नहीं देखा है।

जब आप एक एजेंसी चलाते हैं और कोड भी शिप करते हैं, तो आपका सबसे बड़ा दुश्मन कौशल की कमी नहीं है। यह re-entry cost है। आप चालीस मिनट की pricing call में फँस जाते हैं, फिर आपको एक CSS regression को ठीक करना है, फिर आपका एक टीम मेंबर के साथ 1-on-1 है। जब तक आप उस feature पर वापस आते हैं जो आप बना रहे थे, आप thread को इतना पूरी तरह खो चुके होते हैं कि शुरू से फिर से करना सँभालना आसान लगता है।

Claude Code, सही तरीके से इस्तेमाल किया जाए तो re-entry cost को नाटकीय रूप से कम कर देता है। मैंने पहले summary comment block ट्रिक का जिक्र किया था। मैं इसे अपने लिए एक जल्दी "हम कहां हैं" Slack मैसेज generate करने के लिए भी इस्तेमाल करता हूं जिसमें बुलेट पॉइंट हों, क्या किया गया है, क्या आगे है, और क्या blocked है। दस सेकंड लगते हैं। दस मिनट की reconstruction बचा लेता है।

यह आपको एक बेहतर manager नहीं बनाएगा। यह आपके calendar को clear नहीं करेगा। लेकिन अगर आप एक founder हैं जो अभी भी ship करता है, और मुझे लगता है कि हम में से ज़्यादा को ऐसा करना चाहिए, तो यह आपके coding time पर एक specific, painful tax को हटा देता है।

FAQ

क्या Claude Code इसके लायक है अगर आप full-time developer नहीं हैं?

ईमानदारी से कहूँ तो शायद कम। यह value compound होता है जब आप tool में हर दिन होते हैं और good context files (CLAUDE.md, clear project briefs, आदि) बनाने में समय invest करते हैं। अगर आप हर हफ़्ते एक बार दखल दे रहे हैं, तो आप context re-establish करने में जितना समय बचाते हैं उससे ज़्यादा time बिताएँगे। GitHub Copilot occasional users के लिए ज़्यादा सूट कर सकता है, यह ज़्यादा ambient है और कम deliberate setup की ज़रूरत है।

Code quality को कैसे handle करते हैं, क्या आप simply जो generate करता है उस पर trust करते हैं?

कभी अँधेपन से नहीं। हर Claude-जेनरेटेड फ़ाइल ESLint और हमारे Prettier config से स्वचालित रूप से गुज़रती है। कुछ भी जो authentication, payments या data handling को छुए, मैं एक manual line-by-line read करता हूँ। Utility functions और tests के लिए, मैं ज्यादा आराम से हूँ। आप जोखिम के आधार पर calibrate करते हैं। OWASP Top Ten एक उपयोगी mental checklist है जब आप user input को handle करने वाले AI-जेनरेटेड कोड की समीक्षा करते हैं।

क्या यह WordPress के साथ विशेष रूप से अच्छी तरह काम करता है?

मेरी expectations से बेहतर, caveats के साथ। यह WordPress को deeply जानता है, hooks, filters, Settings API, WooCommerce internals। लेकिन newer Gutenberg block development का इसका knowledge (विशेषकर Interactivity API) patchy है। मैं block-related किसी भी चीज़ के लिए हमेशा Block Editor Handbook के विरुद्ध verify करता हूँ।

कीमत के बारे में क्या?

मैं Claude Pro के लिए भुगतान करता हूँ, जो $20/month है। जिस स्तर पर मैं इसका उपयोग करता हूँ, समय की बचत सप्ताह में चार से छह घंटे के बीच है। अपनी प्रति घंटा दर पर गणित करें। मेरे लिए यह पूछने लायक सवाल नहीं है।

---

मैं अभी भी खुद plenty of code लिखता हूँ। मैं एक prompt jockey बनने में interested नहीं हूँ जो कभी एक real function को touch नहीं करता। लेकिन जो founder यह pretend करता है कि AI coding tools ने craft को change नहीं किया है वह अपने आप को fool कर रहा है। सवाल यह नहीं है कि उन्हें use करना है या नहीं। सवाल यह है कि क्या आप उन्हें enough rigour के साथ use कर रहे हैं real value पाने के लिए, या बस इतना carelessness के साथ कि real problems introduce करें।

मेरे लिए, इन दोनों के बीच का अंतर Claude Code के साथ एक सक्षम लेकिन junior developer की तरह व्यवहार करने में निहित था। स्मार्ट। तेज़। एक अच्छी brief की ज़रूरत है। समीक्षा की ज़रूरत है। और निश्चित रूप से किसी भी mission-critical चीज़ के पास बिना निगरानी के नहीं छोड़ा जाना चाहिए।

उस दृष्टिकोण ने सब कुछ बदल दिया।

← वापस