Claude Code के 6 हफ़्तों के इस्तेमाल का अनुभव

• Claude Code अपनाने के बाद बड़े पैमाने पर कोड लिखने और मेंटेनेंस का तरीका काफी बदल गया—इसे “कोडिंग की दुनिया में फोटोग्राफी के आगमन” जैसा कहा जा सकता है, क्योंकि अब तेज़ implementation और अभिव्यक्ति की अधिक स्वतंत्रता संभव हो गई है
• दोहराए जाने वाले और ‘technical debt’ माने जाने वाले कामों (migration, framework replacement आदि) को अकेले भी तेज़ी से समानांतर रूप से संभालना संभव हुआ, और मुख्य काम के साथ करने पर भी बोझ लगभग नहीं रहा
• “पहले इस्तेमाल करो, बाद में निर्णय लो” वाले experimental development pattern में test/abstraction/experimental code को आसानी से generate और delete करते हुए development productivity और insight हासिल हुई
• game prototyping, collaboration, experimental deployment में बड़ी तेजी आई—game designer बिना code लिखे idea से execution तक कुछ घंटों में पहुँच सके
• monorepo, स्पष्ट tech stack, आधुनिक codebase जैसे Claude Code-अनुकूल माहौल में वास्तविक development work की speed और flexibility में बड़ा सुधार हुआ

---

परिचय: Claude Code अपनाने के बाद के बदलाव

• पिछले 6 हफ़्तों में Claude Code का उपयोग करते हुए कोड लिखने और उसका रखरखाव करने के तरीके में बड़ा बदलाव महसूस हुआ
• ऐसा लगता है कि अब हर कोड खुद लिखना ज़रूरी नहीं रहा, यानी "अभिव्यक्ति की स्वतंत्रता" मिली है
• Claude Code के साथ एक बार में पूरे structure की कल्पना करके review और editing क्षमता के जरिए परिणाम तैयार किया जा सकता है
• जैसे फोटोग्राफी आने के बाद हाथ से चित्र बनाने का आकर्षण कम हुआ था, वैसे ही अब programming में input और production की प्रक्रिया भी तेज़ी से बदल रही है
• यह बदलाव अस्थिर करने वाला लग सकता है, लेकिन LLM-आधारित tools का आगमन programming में paradigm shift ला रहा है

1. Claude Code ने कोड लिखने और मेंटेनेंस का तरीका कैसे बदला

• पहले जिन migration, refactoring, technical debt reduction जैसे कामों में कई हफ़्ते या महीने लगते थे, Claude Code अपनाने के बाद 6 हफ़्तों में उन्हें समानांतर रूप से पूरा किया गया
• उदाहरण: सैकड़ों React Native components को React में बदलना, RedwoodJS system replacement, Jest→Vitest migration, server-side rendering, design system refactoring, Node 22 upgrade आदि
• पहले जिन side project/backlog tasks के लिए अलग से समय निकालना पड़ता था, अब उन्हें मुख्य नौकरी के साथ खाली समय में भी संभालना संभव हो गया, और काम का बोझ लगभग नहीं बढ़ा
• पहले का यह फ़ॉर्मूला कि “technical debt के लिए पहले schedule बनाओ, फिर बड़ा निवेश करो” टूट गया, और तुरंत शुरू करो→आगे बढ़ाओ→पूरा करो वाली तात्कालिकता संभव हुई

2. “पहले इस्तेमाल करो, बाद में निर्णय लो” वाली experimental development culture

• कोई idea आते ही Claude Code से पहले उसे आज़माया जाता है, और test code आदि को शुरुआती चरण में बार-बार auto-generate और delete करते हुए सीखा जाता है
• भले ही frontend testing strategy तय न हो, Claude Code से हर PR पर अलग-अलग तरह के tests तुरंत बनाकर और हटाकर अनुभव इकट्ठा किया जा सकता है, जिससे overall direction तय करने में मदद मिलती है
• ideas और abstraction पर विचार भी “खुद आज़माओ→fail होने पर भी नुकसान कम” वाले तरीके से जल्दी validate और explore किए जा सकते हैं
• विफलता की लागत बहुत कम हो जाने से experiment-learning-decision cycle काफी तेज़ हो गई

3. parallel development और collaboration के तरीके में बदलाव

• दो git clone/VSCode profiles का उपयोग करके, हर clone में अलग-अलग काम (जैसे एक में PR लिखना, दूसरे में experimental development) किया गया
• जब Claude Code एक clone में काम कर रहा हो, तब दूसरे clone में parallel काम किया जा सकता है, और हर clone के theme/port को अलग रखकर स्पष्ट अंतर बनाए रखा जा सकता है
• इससे Pull Request parallel रूप से तैयार करना, development server port conflicts से बचना और work efficiency बढ़ाना संभव हुआ

4. game prototype और experimental development process में बदलाव

• पहले जिन game prototype creation→internal deployment→feedback→public release/discard प्रक्रियाओं में कई हफ़्ते या महीने लगते थे, Claude Code के बाद designer भी कुछ घंटों में खुद code लिखकर site पर deploy कर सके
• idea→execution→team feedback→experiment समाप्त/production conversion (rewrite) जैसे deployment cycle बहुत छोटे हो गए
• हालांकि, temporary games के management, formalization या discard criteria जैसी नई operational चुनौतियाँ भी सामने आईं

5. रोज़मर्रा की coding और collaboration में Claude Code का उपयोग

• साप्ताहिक triage के दौरान Claude Code GitHub Action का उपयोग करके तुरंत PR बनाना और experiment करना संभव हुआ, और छोटे issues को तुरंत लागू किया जा सका
• ऐसे team members जिनमें product और technical दोनों क्षमता तथा ownership हो, वे Claude Code का सबसे प्रभावी उपयोग कर सकते हैं—यानी ‘full-breadth developer’
  • "Full-breadth developers": एक developer को पूरे काम के flow को स्वतंत्र रूप से lead करने में मदद करता है
• जब code review, context देना, correction और decision की भूमिका इंसान के पास रहती है, तब पूरी team की productivity और creativity बढ़ती है

6. Claude Code-अनुकूल codebase environment

• monorepo: पूरा code/DB schema/API/UI logic एक जगह होने से Claude Code के लिए context समझना और automation करना आसान होता है
• standardized tech stack (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap आदि) अपनाने से LLM के लिए समझना और automate करना आसान होता है
• codebase को up-to-date रखना और legacy को कम करना LLM उपयोग की दक्षता को अधिकतम करता है

7. Claude Code की सीमाएँ और वास्तविक अनुभव में बदलाव

• PR/commit count जैसे quantitative metrics में बहुत बड़ा बदलाव नहीं दिखा, लेकिन काम की महसूस होने वाली गति, flexibility और productivity में बड़ा सुधार हुआ
• Claude Code एक ‘अनुभवी junior+ स्तर’ के pair programmer जैसा है—अगर engineer code quality, logic और context संभाले तो यह बेहतरीन partner बनता है
• दोहराए जाने वाले काम, technical debt reduction और तेज़ side project execution जैसे मामलों में यह गुणात्मक रूप से अलग काम का अनुभव देता है

8. junior developers और learners के लिए सुझाई गई ‘parallel implementation’ strategy

• LLM ecosystem के हर नए trend पर ज़रूरत से ज़्यादा अटकने की आवश्यकता नहीं है
• शुरुआती developers के लिए सलाह है कि पहले खुद code लिखें, फिर उसी task को Claude Code से करवाएँ, और उसके बाद तुलना व विश्लेषण करके सीखें
  • Claude Code के solution को देखकर अलग-अलग abstraction और practical patterns जल्दी सीखे जा सकते हैं
  • LLM को ‘प्रतिद्वंद्वी + mentor’ की तरह इस्तेमाल करते हुए practical skills और आधुनिक ecosystem sense दोनों विकसित किए जा सकते हैं
• Claude Code mobile phone की तरह है, जिसे हमेशा on रखना ज़रूरी नहीं
  • अंततः नियंत्रण अपने हाथ में रखकर इसका कुशल उपयोग करना महत्वपूर्ण है

9. side project और short-term experiments में विस्फोटक बढ़ोतरी

• पहले समय और ऊर्जा की कमी के कारण कठिन लगने वाले छोटे experiments, tools development, blog improvements को अब Claude Code के साथ कुछ घंटों में किया जा सकता है
• idea→तुरंत implementation→fail होने पर भी कम नुकसान—इससे production work से अलग creative experiments और personal projects साथ-साथ चलाना आसान हो गया

10. Claude Code के वास्तविक संवाद और code review के उदाहरण

• DB cleanup script, puzzle REPL, crossword PDF layout जैसी ठोस जरूरतों से code generation, execution, correction और review तक की प्रक्रियाओं के वास्तविक उदाहरण दिए गए
• LLM में errors (reasoning issues, exaggeration, hardcoding आदि) आ सकते हैं—इसलिए engineer को logic verification और quality responsibility ज़रूर निभानी होगी, तभी वास्तविक मूल्य मिलेगा

11. engineering में Claude Code की भूमिका और निष्कर्ष

• Claude Code reference code, screenshots और अतिरिक्त विवरण जैसे विस्तृत context को समझने में बहुत सक्षम है
• Claude Code एक 'Post-Junior (कुशल junior से ऊपर)' स्तर का सहायक programmer है—असीम patience और speed के साथ यह practical partner के रूप में बहुत प्रभावी है
• design, quality और final control इंसानी engineer के पास रहते हैं, जबकि Claude Code implementation, experimentation और automation की सीमा और गति को बहुत बढ़ा देता है
• “हर लाइन खुद लिखनी ही होगी” जैसी बाध्यता से बाहर आकर, design, quality control और innovation पर अधिक ध्यान देने वाला development environment संभव होता है

[benjamin]

मैं भी Claude Code का बहुत संतोष के साथ उपयोग कर रहा हूँ.
अब मुझे भी इसे इस्तेमाल करते हुए लगभग 6 हफ्ते हो गए हैं.
ज़्यादातर बातों से मैं सहमत हूँ.

https://jeho.page/essay/2025/07/15/claude-code.html

[zxavi]

मेरी भावना भी बिल्कुल मूल पोस्ट लिखने वाले जैसी ही है, हाहा
$200 पेमेंट करके मैंने सिर्फ एक घंटे में 4 साल पुरानी मुश्किल समस्या हल कर ली।
शायद मैं अकेला नहीं हूं... Cursor से तो इसे बिल्कुल भी हल नहीं कर पाया था।

[beoks]

क्या कोई बता सकता है कि Claude Code और Cursor + Claude LLM इस्तेमाल करने पर क्या फर्क पड़ता है?
मैं अभी Cursor इस्तेमाल कर रहा हूँ, लेकिन Claude Code पर स्विच करने को लेकर सोच रहा हूँ।

[zxavi]

जब आप Claude LLM कहते हैं, तो क्या आपका मतलब API key से है?
या फिर चैट विंडो के नीचे मौजूद Agent models की बात कर रहे हैं?

मैं Cursor से भी काफ़ी संतुष्ट था और उसे इस्तेमाल करता था, लेकिन usage limit बार-बार लग जाती थी, इसलिए $60 वाला प्लान इस्तेमाल करते हुए भी हर समय इस चिंता में रहता था कि कहीं फिर से limit न लग जाए।
इसी वजह से मैं gemini cli को बारी-बारी से इस्तेमाल करता था और काफ़ी stress रहता था।

Cursor + Claude 4 sonnet भी काफ़ी अच्छा है, लेकिन एक दिन बीतते ही limit लग जाना, और limit लगने पर एक महीने तक इस्तेमाल न कर पाना, यही सबसे बड़ी समस्या थी।

Cursor + Claude 4 opus को तो आज़माने की हिम्मत भी नहीं हुई।

Claude Code आख़िरकार cli-आधारित है, और IDE की विशेषताओं पर निर्भर नहीं करता, इसलिए मैंने इसे आज़माने का फ़ैसला किया।

शुरुआत में $20 खर्च किए, लेकिन इसमें भी opus नहीं है।

इसलिए जब लगा कि फिर से limit लगने वाली है, तो सोचा एक महीने के लिए ही सही, $200 देकर इस्तेमाल करके देखता हूँ।

और फिर जैसे एक नई दुनिया खुल गई। opus .. इसकी class ही अलग है...

अभी $200 वाला इस्तेमाल किए 4 दिन हुए हैं, और मैं लंबे समय से पड़े मुश्किल मसलों को एक-एक करके हल कर रहा हूँ haha

[zxavi]

लगता है पोस्ट एडिट नहीं हो रही है

Cursor + Claude 4 sonnet भी काफ़ी अच्छा है, लेकिन एक दिन बाद limit लग जाना, और limit लगने पर एक महीने तक इस्तेमाल न कर पाना, यही सबसे बड़ी समस्या थी।

एक महीना नहीं, शायद एक दिन था। पूरे महीने भर इसी बात की चिंता लगी रहती थी।
और Cursor के साथ मेरी काफ़ी लड़ाई हुई,
लेकिन Claude Code के साथ उतनी लड़ाई नहीं होती।

[beoks]

ओह, इतने विस्तार से जवाब देने के लिए धन्यवाद।
मैं भी limit लग जाने की वजह से मजबूरी में Cursor को Auto mode में इस्तेमाल कर रहा हूँ, लेकिन लगता है अब मुझे भी आगे बढ़ जाना चाहिए।

[GN⁺]

Hacker News राय

• लगभग 2 हफ्तों तक Claude Code इस्तेमाल करने के बाद, मैं आम तौर पर AI coding को लेकर संदेहपूर्ण था, लेकिन यह सच में हैरान करने वाला निकला। इसका अनुभव जमा करने के लिए थोड़ी learning curve है, और सही context देना तथा काम को हिस्सों में बाँटना ज़रूरी है। बेशक programming skill चाहिए, और जो चीज़ खुद नहीं जानते उसे पूरी तरह AI पर छोड़ दें तो समस्या तय है। मेरे पास 25 साल से ज़्यादा का अनुभव है, इसलिए Claude Code जो भी नतीजा दे, मैं उसे review करके गलत होने पर तुरंत सुधार सकता हूँ। लगभग 10~15 साल पहले मैं ऐसे neural interface का सपना देखता था जिसमें कोड खुद न लिखना पड़े, और Claude Code कुछ हद तक वही सच करता हुआ लगता है। कभी-कभी daily usage limit लगने पर मैंने ज़्यादातर Gemini CLI 2.5 pro model को विकल्प के रूप में इस्तेमाल किया, लेकिन उसकी Claude Code से तुलना ही नहीं हो सकती। Gemini इतना frustrating है कि इस्तेमाल करना मुश्किल है। पहले कभी सोचा भी नहीं था कि महीने में 100 डॉलर से ज़्यादा किसी dev tool पर खर्च करूँगा, लेकिन अब Max plan में upgrade करने पर गंभीरता से सोच रहा हूँ.

  • अगर कोई senior developer किसी junior developer को सलाह और guidance दे सकता हो, तो मुझे लगता है कि यह tool उस स्थिति में अच्छी तरह फिट बैठता है। आसपास के senior developers से सुनने पर लगता है कि junior लोग उल्टे LLM से और अजीब code, धीमा code, security के लिहाज़ से कमजोर या पूरी तरह बेतरतीब code बनाकर, उसे समझे बिना PR में डाल देते हैं—इसकी शिकायत बहुत है। मेरे लिए सबसे उपयोगी चीज़ें हैं boilerplate generation (सिर्फ़ description देने पर class design तक निकाल देना), JSON को class या दूसरे format में बदलना, और ऐसे सवाल जैसे “इस code में समस्या क्या है? Staff level engineer इसे कैसे बदलेगा?”। वास्तव में, मैंने खुद टाइप किए हुए code में भी Claude Code से पहले ही bug पकड़वाए हैं.

  • दिलचस्प बात यह है कि “vibe coding” को लेकर संदेह रखने वाले लोग अक्सर tool को वास्तव में आज़माने से पहले उसकी अपेक्षा बहुत कम रखते हैं। बहुत लोग मानते हैं कि LLM जो code देगा वह कूड़ा होगा, और कुछ चरम उदाहरणों को ही औसत समझ लेते हैं। लेकिन जब खुद इस्तेमाल करते हैं, तो यह देखकर खुद चकित हो जाते हैं कि यह उम्मीद से बेहतर है। बेशक Claude Code से 10 लोगों की टीम की जगह बैठकर 1 billion dollar valuation वाला SaaS नहीं बना सकते, लेकिन फिर भी बहुत लोग इसकी असली ताकत को कम आँकते हैं.

  • सख्ती से कहें तो आप वास्तव में vibe coding नहीं कर रहे। यह AI का उपयोग करके software engineering करने के ज़्यादा करीब है। vibe coding का मतलब है कि AI जो code दे, उसे बिना समझे वैसे का वैसा स्वीकार करते जाना। चूँकि इस शब्द की परिभाषा हर व्यक्ति के लिए अलग है, इसलिए vibe coding जैसी terminology पर बहुत भरोसा नहीं करना चाहिए.

  • कुछ ही महीने पहले तक मैं किसी भी subscription service के लिए 20 डॉलर से ज़्यादा नहीं देता था, लेकिन अब हर महीने Max 20 plan के 200 डॉलर दे रहा हूँ। मैं अमेरिका में रहने वाला स्लोवाक मूल का developer हूँ और 20 साल का अनुभव रखता हूँ, इसलिए मुझे भी यह बात हैरान करती है। दूसरे tools भी इस्तेमाल किए, लेकिन इतनी सीधी productivity और efficiency शायद ही कभी महसूस हुई। Claude Code सचमुच अलग स्तर का है। हाँ, इसे लगातार बारीकी से देखना पड़ता है, लेकिन मेरा तरीका यह है कि Plan Mode में requirements और code change plan को बहुत ध्यान से बनवाता हूँ, और जब उस पर 100% सहमत हो जाता हूँ तभी execute कराता हूँ, फिर उसके नतीजे का code review करता हूँ। (compiler error, unit test, lint issues AI खुद ठीक कर लेता है।) यह कुछ वैसा है जैसे थोड़ा अजीब लेकिन बहुत जानकार और बेहद तेज़ junior engineer साथ हो। software development की दिशा साफ़ तौर पर उधर ही जा रही है, और यही भविष्य है.

  • हाल में मुझे लगने लगा है कि Claude model की SQL लिखने/सुधारने में reliability कम है। उदाहरण के लिए condition clause तो सही बनाता है, लेकिन AND/OR को parentheses में नहीं बाँधता, और Gemini pro इस बात को सही bug के रूप में पकड़ लेता है.

• मैं इस बात से गहराई से सहमत हूँ कि Claude Code सभी competing tools से स्पष्ट रूप से आगे है। 2023 से मैं AI code generation के लिए अपना cli tool बना रहा हूँ, और कह सकता हूँ कि लगभग सभी बड़े विकल्प आज़मा चुका हूँ। लेखक के कई तरीकों से गहरी सहमति हुई:

  1. monorepo बहुत समय बचाता है
  2. स्पष्ट spec से शुरुआत करें, और उस spec पर पर्याप्त समय लगाएँ। अच्छा outline हो तो AI ज़्यादातर spec खुद लिख सकता है
  3. शुरुआत से ही tests ज़रूर रखें। यही सबसे महत्वपूर्ण है। अच्छे tests और spec होने चाहिए ताकि AI recursively बेहतर solutions तलाश सके। ऐसा लगता है जैसे TDD वापस आ गया हो
  4. types और linter बहुत बड़ा सहारा हैं
  5. external docs को project के अंदर अलग directory में व्यवस्थित रखना अच्छा है (उदाहरण: docs/external-deps)
  6. हर tool की तरह, अपने लिए काम करने वाली techniques सीखने में थोड़ा समय लगता है। पहले से आसान हुआ है, लेकिन अभी भी सीखना पड़ता है। हर व्यक्ति का workflow थोड़ा अलग होता है, इसलिए यह प्रक्रिया coding जैसी ही महसूस होती है हाल ही में मैंने Permiso(https://github.com/codespin-ai/permiso) नाम का एक बेहद सरल GraphQL RBAC server भी vibe coding से बनाया। यह अभी कोई स्थिर रूप से tested/reviewed project नहीं है, लेकिन जिन्हें कुछ आसान चाहिए उनके लिए यह पहले से उपयोगी हो सकता है.

  • दूसरे बिंदु (अच्छे spec से शुरुआत) पर, मैं जानना चाहता हूँ कि आप practically spec कैसे तैयार करते हैं। क्या उसे अलग Markdown document में रखते हैं, कितनी detail तक जाते हैं वगैरह? साथ ही “शुरुआत से tests तैयार रखें” वाली सलाह से सहमत हूँ, लेकिन व्यवहार में कभी-कभी Claude, test hooking मौजूद होने पर, test code पहले बनाने की प्रक्रिया छोड़ देता है और सिर्फ़ bug/assumption validation के बिना edits दोहराता रहता है। इसलिए मैं कभी-कभी test-related behavior के लिए on/off flag बनाकर इस्तेमाल करता हूँ.

  • monorepo आपका समय बचाता है, लेकिन Claude के tool calls और token usage को बहुत बढ़ा देता है। मुझे लगता है कि Aider की तरह सिर्फ़ ज़रूरी files चुनकर AI को देना बेहतर तरीका है। Claude इतना popular क्यों है, यह मुझे ठीक से समझ नहीं आता। Aider लगभग हर पहलू में बेहतर tool है, और उसमें कई LLM जोड़कर भी इस्तेमाल कर सकते हैं.

  • CC को ठीक से इस्तेमाल करने के लिए project structure अच्छी तरह बना होना चाहिए। Django project में tests, types, docs सब अच्छे से मौजूद हों तो CC ने लगभग सब कुछ ठीक किया, लेकिन बीच-बीच में guidance चाहिए थी। हाल में मैं CC को offline local model के साथ चलाने वाला side project भी कर रहा हूँ। पहला version ChatGPT की मदद से अच्छी तरह बना, लेकिन CC पर आने के बाद CC उल्टा core issues के आसपास घूमता रहता है, गलतियों को bypass करता है, और existing code को refactor या bug fix करने के बजाय बार-बार नई files/scripts बनाने की आदत दिखाता है.

  • क्या आप external docs को सीधे project के अंदर format करके रखते हैं? ज़्यादातर projects की docs तो सिर्फ़ website पर होती हैं, इसलिए जानना चाहता हूँ कि क्या आप अलग से साफ़-सुथरी Markdown files बनाने में समय लगाते हैं.

• Claude Code की असली ताकत सिर्फ़ coding से आगे बढ़कर पूरे computer को control कर पाने में है। अगर कोई CLI tool है, तो Claude उसका इस्तेमाल कर सकता है, और अगर नहीं भी है, तो भी Claude से पूछने पर अक्सर चौंकाने वाले नतीजे मिलते हैं। उदाहरण के लिए image crop/resize, YouTube video से mp3 निकालना, audio files से silent parts हटाना जैसे तरह-तरह के काम मैंने उसे सौंपे हैं। इसकी वजह से बहुत समय बच रहा है। पहले कैसा था, यह भी याद नहीं रहता। अब पुराने तरीके पर वापस जाना शायद मुमकिन नहीं लगेगा.

  • Claude को अपने असली computer से जोड़ने के बजाय (और हमेशा अपने ही computer पर नहीं), उसे एक अलग computer देना बेहतर है। मेरे मामले में cloud VM पर IDE चलता है, और उसी से Claude को जोड़कर browser से access करता हूँ (https://brilliant.mplode.dev)। मेरे हिसाब से agent operation के सबसे करीब और सबसे बेहतर UX यही है। terminal, ssh की तैयारी के बिना सिर्फ़ login करना होता है, और instance अपने-आप create/pause हो जाता है। नतीजा यह है कि Claude + personal Linux instance + IDE को बस एक link से तुरंत खोल लेते हैं। आगे मैं कई instances मनचाहे रूप में चलाने और permissions/filesystem/container permissions (JWT आदि) को बारीकी से control करने की योजना बना रहा हूँ। अगर कोई outage या review की ज़रूरत वाली स्थिति आती है, तो सीधे IDE में घुसकर हल किया जा सकता है। अलग UI की भी ज़रूरत नहीं, IDE के अलग panels में देख सकते हैं या सीधे container में web app चला सकते हैं। काफी समय बाद किसी तकनीकी प्रगति को लेकर इतना उत्साहित हूँ.

  • सब कुछ अच्छा दिखे, फिर भी अगर सिर्फ़ actual code output की बात करें तो data के हिसाब से पहले और बाद में लगभग कोई फर्क नहीं है। Claude के साथ काम करने पर भी commits, PRs, code lines में पहले की तुलना में बहुत बड़ा अंतर नहीं दिखता। यानी AI coding से “productivity बढ़ी है” और “बिना हाथ लगाए कुछ बन गया, अच्छा लग रहा है” जैसी भावना आती है, लेकिन असल में बड़े पैमाने पर review, fixes, re-prompting की ज़रूरत पड़ती है, और कुल output लगभग वैसा ही रहता है। और मुश्किल हिस्से AI को सौंपते-सौंपते अपनी design capability और thinking ability धीरे-धीरे कमजोर होने लगती है। एक महीने तक Claude जैसे LLM ही इस्तेमाल करने के बाद अगर खुद अपनी ताकत से छोटा app बनाना चाहो, तो सिर्फ़ code ही नहीं, overall architecture design भी मुश्किल लगने लगती है। लंबी अवधि में codebase धीरे-धीरे बिगड़ सकता है और आखिरकार नकारात्मक असर भी हो सकता है (कम-से-कम मौजूदा पीढ़ी के LLM में).

  • पहले मैं ImageMagick के mogrify command जैसी चीज़ें पुराने तरीके से एक-एक करके खुद बनाता था। AI tools की मदद से बेहिसाब समय बच रहा है.

  • मेरे Linux PC में बार-बार crash होने की वजह Claude से diagnose करवाई, उसने journalctl से logs खंगालकर root cause तक निकाल दिया, और बहुत मदद मिली। समस्या समाधान में भी इसका सीधा फायदा मिला.

  • एक और उदाहरण यह है कि static site generation बहुत आसान हो गया है। किसी भी syntax में लिखो, Claude Code से कहो कि इस post को blog format में बदल दो, तो वह खुद कर देता है। उदाहरण के लिए सिर्फ़ “image.jpeg जोड़ दो” लिखने पर भी तुरंत कर देता है। Markdown या Hugo format की पाबंदी न होने से सुविधा रहती है.

• Claude code को दिन में 12~16 घंटे इस्तेमाल करने के अनुभव से, मैंने ये tips निकाले हैं:

  1. शुरू होते ही model को sonnet में बदल दें (opus के साथ quality difference काफ़ी है)
  2. compacting (conversation log compression) चलते-चलते quality बहुत गिरा देता है, इसलिए सही timing चुननी चाहिए
  3. पहला prompt बेहद महत्वपूर्ण है, session का character वहीं तय हो जाता है। अगर Claude instance हिचकिचाने लगे या unfriendly लगे, तो session खत्म करके नया खोलना बेहतर है
  4. “शायद यह खराब idea हो, लेकिन मैं ~ implement करना चाहता हूँ” जैसी विनम्र भाषा में कहने पर यह ज़्यादा सक्रिय मदद करता है
  5. Docker orchestration Claude को सौंपने पर productivity 10 गुना बढ़ी हुई लगी। container दोबारा उठाना, error logs देखना, delete/rebuild करना—पूरा flow Claude को सौंपकर एक prompt में पूरे service stack को खड़ा कर सकता हूँ

  • 5वाँ बिंदु Docker के अलावा playwright MCP server से जोड़ने पर UI और requests भी तुरंत verify करवाने में काम आ सकता है। 6. plan mode से शुरू करें और जब तक plan पसंद न आए, iteration करते रहें 7. slash commands (/commands) का आक्रामक उपयोग करें—mini prompts के रूप में लगातार सुधार, context देना, और gh जैसे external tools के इस्तेमाल के निर्देश तक। compacting कभी भी अचानक 0% पर नहीं करना चाहिए, बल्कि बीच के सही समय पर लगाना बेहतर है। 1वाले बिंदु (sonnet recommendation) से हर कोई सहमत हो, यह ज़रूरी नहीं.

  • मैं आम तौर पर Docker से बचने की कोशिश करता हूँ, लेकिन 5वाँ tip (Claude से Docker orchestration कराना) बहुत दिलचस्प लगा। जानना चाहता हूँ कि आप किस तरह का prompt format इस्तेमाल करते हैं.

  • मैंने एक बहुत detailed plan.md file (systems के बीच connections, overall structure आदि) से शुरुआत करके claude-loop(https://github.com/DeprecatedLuke/claude-loop) जैसे tools से उसे रात भर चलने दिया, और सुबह manual patch करके भी अच्छा अनुभव पाया है.

  • जानना चाहता हूँ कि आप Claude Code को दिन में 16 घंटे कैसे इस्तेमाल करते हैं.

  • कभी-कभी Claude container के अंदर बहुत ज़्यादा छेड़छाड़ करता है। मैं सिर्फ़ उसे code समझाना चाहता था, लेकिन वह container के अंदर कई तरह से code run करने की कोशिश करता रहा और उल्टा चीज़ें बिगड़ गईं। पहले भी उसने file को cli command में pipe करके कुछ न करने वाला behavior दिखाया था, यानी उसमें कुछ हद तक compulsive execution tendency है.

• Claude Code वास्तव में कितना अच्छा है, यह मैं नहीं जानता (मैंने खुद नहीं इस्तेमाल किया), लेकिन एक व्यक्तिगत दुविधा है। मैं बहुत धीमे और बिखरे हुए gdscript (Python-जैसी भाषा) को C# में refactor करना चाहता हूँ। यह एक personal project है जिसे मैं अधिक साफ़ और तेज़ बनाना चाहता हूँ। यह काम मेरे लिए नया challenge भी है और educational भी। Claude का इस्तेमाल करूँ तो लगता है कि सीखने का कीमती मौका खुद से छीन रहा हूँ (और long term growth में वह मददगार हो सकता है), और न करूँ तो ऐसा लगता है कि कीमती समय एक उबाऊ काम में बर्बाद कर रहा हूँ, जो वैसे भी आगे चलकर automate हो जाएगा। यही dilemma बार-बार लौटता है.

  • 35 साल के development experience में, मैं किसी भी LLM को वही काम देता हूँ जो मैं खुद कर सकता हूँ लेकिन करना नहीं चाहता—यानी boring या repetitive चीज़ें। उदाहरण के लिए Open API 3.0 schema को ठीक करना अगर मैं खुद करूँ तो उसमें मेरे लिए कोई learning नहीं है, इसलिए Claude को दे दिया। example code generation भी AI से कराता हूँ। लेकिन जहाँ कुछ नया सीखने जैसा हो, उसे मैं Anki SRS जैसे app में flashcards के रूप में लिखता हूँ या TIL blog में नोट करता हूँ। या फिर examples को कई बार खुद implement करके उसे experience में बदलता हूँ। मूल बात यह है कि नई learning को दिमाग से कम-से-कम दो बार जोड़ना ज़रूरी है, तभी effective learning होती है। जैसे कोई नया natural language word सीखते समय उसे 3 वाक्यों में इस्तेमाल करके देखना.

  • अगर generated code का खुद review नहीं करेंगे (यानी C# को पर्याप्त रूप से नहीं सीखेंगे), तो codebase बहुत जल्दी बिगड़ जाएगा। LLM coding में errors accumulate होने की प्रवृत्ति है, इसलिए इसमें सुधार ज़रूरी है; नहीं तो यह maintain न हो सकने वाला कूड़ा बन जाता है। मेरे कुछ दोस्त कहते हैं कि AI से पर्याप्त test code generate करवाकर problems जल्दी पकड़ सकते हैं, लेकिन मैंने अभी तक वह तरीका नहीं अपनाया। मेरा code algorithms से ज़्यादा logic-heavy है, इसलिए tests लिखना भी थोड़ा अस्पष्ट लगता है.

  • 16 साल तक professional developer के रूप में काम करते हुए, मुझे लगा कि Claude Code ने उन चीज़ों को भी काफ़ी आसान बना दिया जिन पर पहले सिर पटकना पड़ता था। नई चीज़ें जल्दी सीखने के लिए AI tools—खासकर सवाल-जवाब वाले "ask" mode—काफ़ी प्रभावी हैं; मैं analogy, cases, memory tricks का सक्रिय उपयोग करता हूँ। अगर लक्ष्य धीमी रफ्तार से गहरी learning है, तो भले धीरे हो, खुद से पारंपरिक तरीका बेहतर है। लेकिन अगर जल्दी सीखना लक्ष्य है, तो AI का उपयोग बुरा नहीं। अगर सिर्फ़ result चाहिए, तो spec अच्छी तरह लिखना और tests पर्याप्त रखना महत्वपूर्ण है। आखिरकार किसी भी तरीके से, लगातार कुछ बनाते रहना ही मायने रखता है.

  • पहले एक blog trend था—“अपनी खुद की x library बनाओ”। किसी चीज़ को खुद implement करने की प्रक्रिया में सबसे ज़्यादा सीख मिलती है। उदाहरण के लिए अगर client-side router समझना है, तो खुद router बनाओ। LLM युग में हर चीज़ library code से replace हो सकती है, लेकिन अगर मैं सच में C# सीखना चाहता हूँ, तो खुद port करना बेहतर है। अगर सिर्फ़ output चाहिए और ध्यान किसी दूसरी चीज़ पर लगाना है, तो Claude को सौंप सकते हैं। सीखने में दर्द का हिस्सा अनिवार्य है; अगर बहुत आसान लगे, तो शायद वास्तव में कुछ सीखा ही नहीं.

  • AI से पहले copy-paste ही मुख्यधारा थी। Stackoverflow से code बिना वजह समझे उठा लेने वाले दोस्त आखिर कुछ नहीं सीख पाए। सलाह या concept explanation AI से माँगने में मुझे कोई समस्या नहीं लगती। लेकिन अगर हर चीज़ उससे लिखवाएँगे, तो सीखना नहीं होगा। फिर भी, developer के रूप में अपना समय बचाना भी समझदारी है। सीखने के लिए बेहिसाब चीज़ें हैं, इसलिए अगर लक्ष्य game development है, तो GDscript porting शायद अनिवार्य अनुभव न हो। हाँ, उसमें कुछ सीख ज़रूर है.

• लगभग 3 हफ्तों तक Claude Code से coding करने के अनुभव में, मैं 10 साल के अनुभव वाला Python ML/data engineering-केंद्रित व्यक्ति हूँ। इसके कई कारण हैं:

  1. यह शुरुआत की पीड़ा हटा देता है, इसलिए पहली लाइन लिखने की बाधा नहीं रहती
  2. जब यह चलता रहता है, तब दिमाग को पूरी तरह thinking के लिए इस्तेमाल किया जा सकता है
  3. एक साथ कई tasks parallel में चलाए जा सकते हैं
  4. अगर बीच में लगे कि “एक और चीज़ ध्यान रखनी थी”, तो तुरंत नई Claude session में आज़मा सकता हूँ (अब TODO नहीं छोड़ता)
  5. analysis/visualization, plotting वगैरह के scripts भी आसानी से auto-run करवा सकता हूँ
  6. साधारण lint/type/test issues यह खुद ही ठीक कर देता है कुल मिलाकर, अब code के सार पर ध्यान देना संभव होता है—क्या करना है, output सही है या नहीं, और इसे बेहतर कैसे बनाया जा सकता है.

  • शुरुआत की पीड़ा हट जाना सच में बहुत बड़ी बात है। पहले जो चीज़ें “समय मिला तो करूँगा” के स्तर पर थीं, अब कुछ prompts में शुरू हो जाती हैं। मैंने वास्तव में NYT Connections game को terminal में बनाना चाहा था, और वह 3 prompts में तैयार हो गया (https://github.com/jleclanche/connections-tui)

  • 4वाँ बिंदु खास तौर पर असरदार लगा। पहले tests या technical debt छोड़ देना सामान्य बात थी, लेकिन अब test suite भी सिर्फ़ “ज़रूरत है” कहने पर काफ़ी ठीक-ठाक generate हो जाता है। यह भले perfect न हो, लेकिन मध्यम कठिनाई के काम अब निश्चित रूप से संभाले जा सकते हैं.

• agent-based coding को लगातार आज़माने वाले एक जिज्ञासु अल्पसंख्यक के रूप में, मैं सोचता रहा हूँ कि मेरा अनुभव मुख्यधारा से अलग क्यों है। शायद नीचे का वर्णन इसमें सबसे महत्वपूर्ण है:

  "Claude Code के साथ हम ‘photography के आने के समय वाली programming’ में हैं। हाथ से चित्र बनाने वाला mood इसलिए गायब हो जाता है क्योंकि एक idea को तुरंत reality में बदला जा सकता है, और अपनी code review व editing skill से उसे इच्छित रूप में तराशा जा सकता है" यह analogy ठीक लगती है, फिर भी लोग आज भी painting करते हैं, कुछ लोग painting खरीदने के लिए पैसा देते हैं, और कुछ लोग coding को खुद एक कला की तरह enjoy करते हैं। मेरे लिए खुद coding करना hobby है, और code review मुझे पसंद नहीं, लेकिन मजबूरी में करता हूँ। अगर चुनाव दिया जाए, तो मैं खुद बनाने वाला रास्ता चुनूँगा (शायद इसी वजह से IC बना हुआ हूँ)। लोग AI coding agents को बहुत junior developer intern जैसा बताते हैं, लेकिन मुझे यह थोड़ा डरावना लगता है.

  • मैं पूछना चाहता हूँ कि क्या आज भी ऐसा वातावरण बना हुआ है जहाँ लोग चित्र बनाते हैं और चित्रों पर पैसा खर्च करते हैं। ज़्यादातर हस्तशिल्प अब modular, mass-production processes से पीछे छूट चुके हैं, और लगता है कि अब वस्तु से ज़्यादा महत्व producer और consumer के बीच imagination के सह-अनुभव का है। सिर्फ़ Amazon से चीज़ मँगाना नहीं, बल्कि कारीगर से रिश्ता और creation process की कहानी भी उपभोग का हिस्सा बनती है। coding को भी आगे टिके रहने के लिए शायद इसी दिशा में जाना होगा.

  • मैं भी इस दृष्टिकोण को बहुत अच्छी तरह समझता हूँ। छोटे tasks, bug fixes, और drafts के लिए agent coding की उपयोगिता मानता हूँ। लेकिन कुछ ही models को wrap करने वाली अलग-अलग interfaces को लेकर support/opposition की इतनी तीखी बहस मुझे समझ नहीं आती। और junior devs पर उसका impact क्या होगा, यह अभी भी सोचने की बात है। अगर AI code review तक automate कर दे, तो मेरी ज़िंदगी और भी आसान हो जाएगी.

  • मुझे नहीं लगता कि वह analogy पूरी तरह सही है। ऐतिहासिक रूप से painting वास्तविक दुनिया को reproduce करने का एकमात्र माध्यम थी, लेकिन art सिर्फ़ imitation नहीं, creator की interpretation भी है। लोग आज भी painting इसलिए करते हैं। अगर coding को भी art मानें, तो उसे करते रह सकते हैं। लेकिन बहुत लोगों का लक्ष्य product development है, और product खुद भी एक कला हो सकता है। अगर AI से उस लक्ष्य तक जल्दी पहुँचा जा सकता है, तो AI चुनना स्वाभाविक नहीं होगा क्या? दूसरी ओर, कभी-कभी “code monkey” वाले दिन भी याद आते हैं, जब सिर्फ़ coding करनी होती थी। अब लगता है सबको lead developer की तरह direction, code review, और technical decisions पर जाना होगा। production coding में हाथ कम लगने वाला यह बदलाव थोड़ा खलता भी है.

  • ज़्यादा उचित analogy hand-tools से power tools की ओर बदलाव वाली है। painting-photography analogy एक नए medium के आगमन जैसी बात थी, इसलिए यहाँ उसे कुछ ज़्यादा खींचा जा रहा है। agent coding उतनी revolutionary नहीं है.

• मैंने Claude Code को बहुत इस्तेमाल करने की कोशिश की, लेकिन यह बहुत धीमा है और हमेशा कुछ न कुछ गलत दिशा में चला जाता है, जिससे झुंझलाहट होती है। ज़्यादातर tasks में ऐसा नहीं लगा कि यह mental energy बचाता है। कुछ कामों में मदद मिली, लेकिन कई बार उल्टा धोखा भी मिला, इसलिए इसे बार-बार इस्तेमाल करने का मन नहीं करता। उदाहरण के लिए मैंने उससे nushell में .zshrc convert करने को कहा, लेकिन 30 मिनट जूझने के बाद भी कुछ runnable नहीं निकला, जबकि मैं खुद official docs देखकर 10 मिनट में कर सकता था। ऐसे निराशाजनक अनुभवों की वजह से Claude दोबारा इस्तेमाल करने की इच्छा कम हो गई है.

  • यह अनुभव मेरा भी कुछ ऐसा ही है। test code लिखवाने वगैरह में मदद लेने की कोशिश की, लेकिन अक्सर अंत में सब मुझे ही दोबारा लिखना पड़ा। debugging में मुझे एक बार भी सफलता नहीं मिली। बहुत साधारण script conversion (जैसे command output parsing) या नया project scaffolding ही कुछ काम का लगा (लेकिन ऐसे काम कितनी बार आते हैं)। साधारण code porting में ठीक था, लेकिन असफलताएँ कहीं ज़्यादा रहीं.

  • क्या आपने context7 MCP जैसी चीज़ आज़माई है? कम लोकप्रिय languages या अपरिचित domains में LLM अक्सर कमजोर पड़ते हैं। context7 की तरह सीधे up-to-date source से references लाने का तरीका ज़्यादा बेहतर लगता है.

• RSI और carpal tunnel syndrome की वजह से मैंने coding कम कर दी थी, लेकिन Claude की वजह से (दर्द 10वें हिस्से तक घट जाने से) मैं फिर से programming कर पा रहा हूँ। यह ऐसी technology थी जिसे मैं शायद ठुकराना चाहता था, लेकिन career जारी रखना है तो अब यह ज़रूरी लगती है.

  • मैंने ऐसे बहुत लोगों की बातें सुनी हैं। RSI वाले लोगों के लिए Claude जैसे tools सचमुच game changer हैं। सबसे कठिन और उबाऊ boilerplate जैसी repetitive work को ये बहुत आसान बना देते हैं। पहले repeat code देखते ही कलाई और mental state दोनों दुखती थीं, लेकिन अब उस पर ध्यान देने की ज़रूरत नहीं, और abstract/नए problems पर focus कर पाने से programming खुद अधिक enjoyable हो गई है। “ऐसे tools की वजह से career खत्म हो जाएगा” जैसी चिंता भी सुनते हैं, लेकिन मुझे उल्टा लगता है कि यही मेरी career बचाएँगे.

  • Claude इस्तेमाल करना शुरू करने के बाद RSI का दर्द लगभग गायब हो गया। खासकर बहुत precise commands और वाक्यों से repetitive काम replace किए जा सकते हैं। voice recognition के कई use cases भी सुने हैं, और लगता है इससे accessibility का रास्ता खुल रहा है.

  • अगर Claude Code को सीधे voice से इस्तेमाल किया जा सके, तो शायद और मदद मिले। MacOS पर free TTS/ASR options हैं, और BYOK के साथ दूसरे voice engines भी जोड़े जा सकते हैं (https://github.com/robdmac/talkito)

  • अगर पर्याप्त accurate और convenient STT/voice recognition app हो, तो Claude Code को detailed context देना भी प्रभावी होता है। कई voice recognition apps आज़माने के बाद, keyboard shortcut-based hands-free mode, accuracy और speed—तीनों में Wispr Flow सबसे अच्छा लगा। बस इच्छा है कि local app support भी मिले.

  • क्या आप text input भी voice से ही करते हैं?

• maintainability के नज़रिए से मैं लेखक की बात से गहराई से सहमत हूँ। पहले जिन refactoring/reminder TODOs या tickets को बस लिखकर छोड़ देते थे, Claude की वजह से अब उन्हें तुरंत implement कर देते हैं। इससे repetitive मेहनत बहुत कम हो जाती है। refactoring ideas को जल्दी आज़माकर, पसंद न आए तो तुरंत छोड़ देना भी आसान हो गया है। इस तरह के कामों के लिए activation energy काफ़ी कम हो गई है। मैं इस बात से भी सहमत हूँ कि अगर AI agents को parallel/offline अंधाधुंध चलाया जाए, तो वह burnout और code quality गिरने का कारण बन सकता है, इसलिए इसे human supervision mode में ही रखना चाहिए। इस पर मैंने एक अतिरिक्त लेख भी लिखा है: https://www.modulecollective.com/posts/agent-assisted-coding...