तीन महीने पहले मैं एक दूसरे बैकेंड डेवलपर को नियुक्त करने वाला था। हमारे पास एक शर्मनाक बैकलॉग था — क्लाइंट को चौदह फीचर का वादा किया गया, दो लोग पूरी तरह खिंचे हुए थे, और मैं सेल्स कॉल और पुल रिक्वेस्ट के बीच कॉन्टेक्स्ट-स्विच कर रहा था जैसे पूरी तरह बेवकूफ। फिर मैंने Claude Code को सही तरीके से इस्तेमाल करना शुरू किया। बस चैट विंडो में फ़ंक्शन पेस्ट नहीं करना। मेरा मतलब है इसे असली रोज़मर्रा के काम में एकीकृत करना। हमने छह हफ़्तों में वह बैकलॉग साफ़ कर दिया। मैंने दूसरे डेवलपर को नहीं नियुक्त किया।using Claude Code properly. Not just pasting functions into a chat window. I mean integrating it into the real daily flow. We cleared that backlog in six weeks. I didn't hire the second developer.
यह एक पिच नहीं है। यह सिर्फ वह है जो हुआ।
"सही तरीके से" का असल अर्थ क्या है
जो लोग मैं मीटअप्स में मिलता हूँ वह सभी लोग AI कोडिंग टूल्स को उसी आलसी तरीके से उपयोग कर रहे हैं। वह एक फंक्शन पेस्ट करते हैं, कुछ वापस पाते हैं, इसे अपने एडिटर में पेस्ट करते हैं, यह टूट जाता है, वह हार मान जाते हैं। यह एक वर्कफ़्लो नहीं है। यह निराशा है।
मेरे लिए सही तरीका — Claude Code मेरे टर्मिनल के अंदर Claude Code CLI के ज़रिए रहता है, सीधे मेरे असली रेपो पर काम कर रहा है, असली फाइलें पढ़ रहा है, शुद्ध स्निपेट नहीं। फर्क़ भारी है। जब इसके पास एक 4,000-लाइन WordPress प्लगइन का पूरा कॉन्टेक्स्ट है जो हमने पिछले साल एक अमेरिकी हेल्थकेयर क्लाइंट के लिए बनाया था, तो आउटपुट इस्तेमाल की लायक़ होता है। जब यह 40-लाइन के पेस्ट से अंधे में काम कर रहा हो, तो यह अनुमान लगा रहा होता है।Claude Code CLI, working directly on my actual repo, reading real files, not sanitised snippets. The difference is enormous. When it has full context of a 4,000-line WordPress plugin we built for a US healthcare client last year, the output is usable. When it's working blind off a 40-line paste, it's guessing.
मैं इसे MacBook Pro M3 पर चलाता हूँ। मेरा एडिटर अब भी VS Code है आम जनों के साथ — Prettier, ESLint, GitLens। Claude Code इनमें से किसी को रिप्लेस नहीं करता। यह इनके साथ-साथ बैठता है।alongside it.
Setup जो मैं असल में use करता हूँ
- Claude Code CLI को npm के through globally install किया
- हर प्रोजेक्ट रूट में एक .claude डायरेक्टरी और एक CLAUDE.md फाइल — यह मूल रूप से Claude के लिए एक brief है जो मैं प्रोजेक्ट के बारे में लिखता हूँ: स्टैक, कन्वेंशन, क्या न छुएँ।
.claudedirectory in each project root with aCLAUDE.mdfile -- this is basically a brief I write for Claude about the project: stack, conventions, what not to touch - iTerm2 split panes: बाईं ओर code, दाईं ओर Claude session
- Claude द्वारा generate किए गए हर change के बाद Git commits करता हूँ, कोई exception नहीं। मुझे झलक मिल चुकी है।
वह आखिरी पॉइंट। 2022 में एक क्लाइंट प्रोजेक्ट था — Manchester के एक फर्नीचर रिटेलर के लिए Shopify माइग्रेशन — मैंने AI-असिस्टेड एडिट्स को तीन घंटे तक जमा होने दिया कोई कमिट किए बिना। पूरा सेशन corrupt हो गया। छह घंटे का काम गायब। मैं अब neurotically कमिट करता हूँ, लगभग पागलपन के साथ। Claude Code हो या न हो।
Morning Routine (यह जानबूझकर बेहद specific है)
मैं 8:30 तक office में होता हूँ। Exmouth Market की जगह से कॉफ़ी। मैं Notion खोलता हूँ, देखता हूँ कि आज के लिए board पर क्या है, फिर अपना terminal खोलता हूँ।
मैं हर सुबह Claude Code के साथ जो पहली चीज़ करता हूँ वह है जिसे मैंने "कॉन्टेक्स्ट डंप" कहना शुरू किया है। मैं प्रोजेक्ट खोलता हूँ, claude चलाता हूँ और इसे एक पैराग्राफ देता हूँ कि मैंने पिछले दिन कहाँ छोड़ा था। यह हाल की git diff को अपने आप पढ़ता है। इसमें करीब तीन मिनट लगते हैं और इसका मतलब है कि मैं बीस मिनट अपना कोड फिर से पढ़ने में नहीं बिता रहा हूँ यह याद करने के लिए कि मैं क्या कर रहा था। यह अकेले ही सबस्क्रिप्शन की कीमत है।claude and give it a paragraph of where I left off the previous day. It reads the recent git diff automatically. This takes about three minutes and means I'm not spending twenty minutes re-reading my own code to remember what I was doing. That alone is worth the subscription.
फिर मैं काम करता हूँ। मैं Claude से फीचर पूरी तरह से scratch से लिखने के लिए नहीं कह रहा हूँ — हालाँकि कभी-कभी मैं करता हूँ। ज़्यादातर मैं इससे उन चीजों को करने के लिए कह रहा हूँ जो मुझे slow down करती हैं लेकिन शून्य creativity चाहिए।
जैसे:
- उन functions के लिए PHPUnit test cases लिखना जो मैंने पहले से लिख दिए हैं
- एक JSON response से TypeScript interfaces generate करना जो मैं paste करता हूँ
- एक 300-लाइन कंपोनेंट को रीफैक्टर करना जिसे मैं जानता हूँ कि विभाजित करने की ज़रूरत है लेकिन सोचना नहीं चाहता।know needs splitting but don't want to think about
- Internal APIs के लिए first-draft documentation
इनमें से कुछ भी exciting नहीं है। सब कुछ पहले एक घंटा खा जाता था जो मेरे पास नहीं था।
यह वास्तव में कहाँ समय बचाता है (Numbers के साथ)
Seahawk ने इस बिंदु पर 12,000 से ज़्यादा साइट बनाई हैं। इसका एक बड़ा हिस्सा WordPress है — थीम, प्लगइन, WooCommerce customisations। WordPress डेवलपमेंट में कार्यों की एक कैटिगरी है जो mind-numbing लेकिन technically precise है: कस्टम हुक लिखना, REST API एंडपॉइंट रजिस्टर करना, Settings API के साथ settings pages बनाना।
मैंने पिछले महीने इसे समय दिया। एक WooCommerce कस्टम शिपिंग method class को scratch से लिखना: ऐतिहासिक रूप से मुझे testing सहित लगभग 45 मिनट लगते हैं। Claude Code scaffold करते समय मैं business logic को सादा अँग्रेज़ी में describe करता हूँ: 12 मिनट। और scaffold अच्छा है — यह WordPress coding standards का पालन करता है क्योंकि मैंने इसे अपने CLAUDE.md में बताया था।good -- it follows WordPress coding standards because I told it to in my CLAUDE.md.
यह 10% बेहतर नहीं है। यह स्पीड की बिल्कुल अलग कैटेगरी है।
असली बचत context-switching की कॉस्ट में है। जब मैं किसी फीचर के बीच होता हूँ और कोई क्लाइंट बिल्कुल अलग प्रोजेक्ट पर बग के बारे में पिंग करता है, तो मैं या तो क्लाइंट को ignore करता था (बुरा) या अपना पूरा focus खो देता था (यह भी बुरा)। अब मैं Claude से कहता हूँ कि एक डिटेल्ड comment block लिखे जो बताए कि हम इस टास्क में कहाँ हैं, फिर बग पर जाता हूँ, उसे fix करता हूँ, वापस आता हूँ, comment पढ़ता हूँ, और करीब चार मिनट में फिर से शुरू करता हूँ। पहले यह रिकवरी मुझे बीस मिनट का नुकसान करती थी।
यह कहाँ टूटता है
ईमानदारी से कहूँ तो। और यह जीत से ज्यादा matter करता है।
Claude Code वास्तव में किसी भी ऐसी चीज़ में बुरा है जिसमें यह समझने की ज़रूरत हो कि ऐतिहासिक रूप से एक निर्णय क्यों लिया गया था। हमारे पास Seahawk में एक fintech प्रोजेक्ट था -- एक London-based payments startup के लिए एक dashboard -- जहाँ state management का एक खासा जटिल हिस्सा था जिसका कारण हमारे शामिल होने से पहले का था। उनके legacy API के बारे में कुछ edge case थी कि कैसे वह responses को batch करता था। Claude हमेशा इसे "fix" करने की कोशिश करता रहा। हर सुझाव technically ज़्यादा साफ़-सुथरा और पूरी तरह से गलत था। वह नहीं जानता था कि वह क्या नहीं जानता है।why a decision was made historically. We had a fintech project at Seahawk -- a dashboard for a London-based payments startup -- where a particularly gnarly bit of state management existed for a reason that predated our involvement. Some edge case in how their legacy API batched responses. Claude kept "fixing" it. Every suggestion was technically cleaner and completely wrong. It didn't know what it didn't know.
यह विफलता का तरीका है जिसके बारे में कोई काफ़ी बात नहीं करता। आउटपुट सही दिखता है। यह बुनियादी समीक्षा पास करता है। और फिर यह गुरुवार की शाम को प्रोडक्शन में टूट जाता है जब कोई यूज़र उस एज केस को हिट करता है।looks correct. It passes basic review. And then it breaks in production on a Thursday evening when a user hits that edge case.
मेरा अब का नियम: Claude Code उन चीजों को नहीं छूता जहाँ comment में "don't change this without asking Ravi" लिखा हो। (Ravi हमारे lead backend dev हैं।) बिल्कुल निश्चित।
इसके अलावा यह badly struggle करता है:
- Multi-file refactors में जहाँ dependency chain तीन levels से ज्यादा हो
- किसी भी third-party SDK जो दो साल से कम पुरानी है -- यह confidently method names को गलत बताता है।
- CSS जो डिज़ाइनर के pixel-perfect कंप के साथ match करनी है (बस ज़रा-सी ख़राबी होती है, फिर छोटी-मोटी errors से पागलपन आता है)
- Performance optimisation जहाँ bottleneck स्पष्ट नहीं है -- यह गलत चीज़ को optimize करता है।
विशेष रूप से दूसरे बिंदु पर: मैं जनवरी में एक Next.js प्रोजेक्ट में Resend API को एकीकृत कर रहा था। Claude बार-बार एक .send() मेथड को संदर्भित कर रहा था जो Resend Node SDK में मौजूद नहीं है। Claude की आत्मविश्वासी गलतता को डीबग करने में मुझे उतना ही लंबा समय लगा जितना कि खुद डॉक्स पढ़ने में लगता। सबक सीखा। किसी भी SDK के लिए, मैं पहले असली README को कॉन्टेक्स्ट विंडो में पेस्ट करता हूँ।Next.js project in January. Claude kept referencing a.send()method that doesn't exist in the Resend Node SDK. Took me longer to debug Claude's confident wrongness than it would've taken to just read the docs myself. Lesson learned. For any SDK, I paste the actual README into the context window first.
The Prompt Patterns That Actually Work
मैंने इस पर महीनों तक काम किया है। ख़राब prompts से ख़राब output मिलता है। यहाँ मेरे निष्कर्ष हैं।
Senior dev बनो, intern नहीं। "मुझे एक function लिखो जो X करे" मत कहो। "मुझे X implement करना है। Constraint ये है: Y। जो चीज़ें मैंने rule out कर दी हैं: Z। तुम्हारा approach क्या है कुछ लिखने से पहले?" कहो। इसे सोचने दो। उस बातचीत के बाद output dramatically बेहतर होता है।Don't ask "write me a function that does X." Ask "I need to implement X. Here's the constraint: Y. Here's what I've already ruled out: Z. What's your approach before you write anything?" Make it think first. The output after that conversation is dramatically better.
इसे एक persona दो जिसके stakes हों। मैं literally लिखता हूँ: "तुम एक senior WordPress developer हो जो security vulnerabilities introduce न करने की गहरी परवाह करता है। Client एक healthcare company है। Sanitisation और nonce verification को सबसे ऊपर रखो।" क्या ये silly लगता है? हाँ। क्या काम करता है? भी हाँ।I literally write: "You're a senior WordPress developer who cares deeply about not introducing security vulnerabilities. The client is a healthcare company. Prioritise sanitisation and nonce verification above everything." Does this feel silly? Yes. Does it work? Also yes.
Output का format specify करो। "मुझे सिर्फ function दो, कोई explanation नहीं" या "Function दो, फिर एक bullet list जो मुझे manually verify करना चाहिए।" Unstructured output समय ख़राब करता है।"Give me just the function, no explanation" or "Give me the function, then a bullet list of what I should manually verify." Unstructured output wastes time.
एक pattern जिसके लिए मैं लगातार reach करता हूँ:
- Goal को एक वाक्य में describe करो
- प्रासंगिक मौजूदा कोड को एक टिप्पणी के साथ पेस्ट करें जो इसके उद्देश्य की व्याख्या करे
- बाधा बताएँ ("PHP 7.4 के साथ backwards compatible होना चाहिए")
- पहले approach माँगें, फिर कोड माँगें
- दृष्टिकोण की समीक्षा करें, आवश्यकता पड़ने पर असहमति जताएँ, फिर कोड माँगेंthen ask for the code
पाँच steps। ओवरहेड लगता है। हर बार मुझे पंद्रह मिनट खराब कोड से बचाता है।
यह कैसे बदल गया है कि मैं क्या काम सौंपता हूँ
यह वह हिस्सा है जिसने मुझे सबसे ज्यादा हैरान किया। Claude Code ने सिर्फ मुझे तेज़ नहीं बनाया। इसने बदल दिया कि मैं जूनियर डेवलपर्स को क्या सौंपता हूँ।me faster. It changed what I hand off to junior developers.
पहले, Seahawk में एक जूनियर डेव अपने पहले दो हफ़्तों में बस हमारे कन्वेंशन्स और हमारे स्टैक से परिचित होने में लगाता था। अब मैं उन्हें एक अच्छी तरह लिखी हुई CLAUDE.md फ़ाइल के साथ एक प्रोजेक्ट सौंपता हूँ और उन्हें कहता हूँ कि Claude Code का उपयोग करके scaffold code जेनरेट करें, फिर इसे कन्वेंशन्स के विरुद्ध समीक्षा करें। वे तीन सप्ताह की जगह तीन दिन में असली काम करने लगते हैं।CLAUDE.md and tell them to use Claude Code to generate scaffold code, then review it against the conventions. They're contributing real work in three days instead of three weeks.
CLAUDE.md फ़ाइल वह mentoring कर रही है जो मैं पहले hourly walkthroughs में किया करता था। यह एक meaningful shift है। सिर्फ इसलिए नहीं कि मैं mentor नहीं करना चाहता -- मैं चाहता हूँ -- बल्कि इसलिए कि अब mentoring conversations decisions और trade-offs के बारे में हैं, न कि "हर form में wp_nonce_field() लगाना याद रखो" के बारे में।CLAUDE.md file is doing the mentoring I used to do in hourly walkthroughs. That's a meaningful shift. Not because I don't want to mentor -- I do -- but because now the mentoring conversations are about decisions and trade-offs, not "remember to use wp_nonce_field()in every form."
Anthropic model spec documentation एक read के लायक है अगर आप curious हो कि Claude कौन सी guardrails के अंदर काम करता है -- उन्हें समझना आपको उसके tendencies के साथ काम करने में मदद देता है, उसके खिलाफ़ नहीं।Anthropic model spec documentation is worth a read if you're curious about the guardrails Claude operates within -- understanding them helps you work with its tendencies rather than against them.
संस्थापक-विशिष्ट दृष्टिकोण
AI कोडिंग टूल्स के बारे में ज्यादातर लेख डेवलपर्स के लिए लिखे जाते हैं। ठीक है। लेकिन एक विशिष्ट संस्थापक समस्या है जिसे Claude Code संबोधित करता है और मैंने इसे अच्छी तरह से व्यक्त होते नहीं देखा है।
जब आप एक एजेंसी चलाते हैं और कोड भी शिप करते हैं, तो आपका सबसे बड़ा दुश्मन कौशल की कमी नहीं है। यह re-entry cost है। आप चालीस मिनट की pricing call में फँस जाते हैं, फिर आपको एक CSS regression को ठीक करना है, फिर आपका एक टीम मेंबर के साथ 1-on-1 है। जब तक आप उस feature पर वापस आते हैं जो आप बना रहे थे, आप thread को इतना पूरी तरह खो चुके होते हैं कि शुरू से फिर से करना सँभालना आसान लगता है।re-entry cost. You get pulled into a pricing call for forty minutes, then you need to go fix a CSS regression, then you have a 1-on-1 with a team member. By the time you get back to the feature you were building, you've lost the thread so completely that starting again feels easier than picking up.
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 नहीं हैं?
ईमानदारी से, शायद कम। मूल्य तब compound होता है जब आप tool में हर दिन होते हैं और अच्छी context files (CLAUDE.md, clear project briefs, आदि) बनाने में समय लगाते हैं। अगर आप हफ़्ते में एक बार आते हैं, तो आप context को फिर से स्थापित करने में उतना ही समय खर्च करेंगे जितना आप save करते हैं। GitHub Copilot occasional users के लिए बेहतर हो सकता है -- यह ज़्यादा ambient है और कम deliberate setup की ज़रूरत है।CLAUDE.md, clear project briefs, etc.). If you're dipping in once a week, you'll spend more time re-establishing context than you save. GitHub Copilot might suit occasional users better -- it's more ambient and requires less deliberate setup.
आप code quality को कैसे handle करते हैं -- क्या आप सिर्फ़ इस पर trust करते हैं कि यह generate करता है?
कभी अँधेपन से नहीं। हर 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-जेनरेटेड कोड की समीक्षा करते हैं।OWASP Top Ten is a useful mental checklist when reviewing AI-generated code that handles user input.
क्या यह WordPress के साथ विशेष रूप से अच्छी तरह काम करता है?
मेरी expectations से बेहतर, कुछ caveats के साथ। यह WordPress को deeply जानता है -- hooks, filters, Settings API, WooCommerce internals। लेकिन newer Gutenberg block development (विशेषकर Interactivity API) का इसका ज्ञान patchy है। मैं हमेशा Block Editor Handbook के विरुद्ध किसी भी block-related चीज़ को verify करता हूँ।Block Editor Handbook for anything block-related.
कीमत के बारे में क्या?
मैं Claude Pro के लिए भुगतान करता हूँ, जो $20/month है। जिस स्तर पर मैं इसका उपयोग करता हूँ, समय की बचत सप्ताह में चार से छह घंटे के बीच है। अपनी प्रति घंटा दर पर गणित करें। मेरे लिए यह पूछने लायक सवाल नहीं है।
---
मैं अभी भी खुद काफ़ी code लिखता हूँ। मैं एक prompt jockey बनने में interested नहीं हूँ जो कभी real function को touch नहीं करता। लेकिन जो founder यह नाटक करता है कि AI coding tools ने craft को नहीं बदला, वह अपने आप को धोखा दे रहा है। सवाल यह नहीं है कि इन्हें use करें या नहीं। सवाल यह है कि क्या आप इन्हें इतनी rigour के साथ use कर रहे हैं कि real value मिले -- या सिर्फ़ इतनी carelessness के साथ कि real problems introduce हों।
मेरे लिए, इन दोनों के बीच का अंतर Claude Code के साथ एक सक्षम लेकिन junior developer की तरह व्यवहार करने में निहित था। स्मार्ट। तेज़। एक अच्छी brief की ज़रूरत है। समीक्षा की ज़रूरत है। और निश्चित रूप से किसी भी mission-critical चीज़ के पास बिना निगरानी के नहीं छोड़ा जाना चाहिए।
उस दृष्टिकोण ने सब कुछ बदल दिया।