Claude Code से productivity बढ़ाने के तरीके

• AI agent के सरल दोहराव वाले कामों को automate करना, build wait time हटाना, और parallel worktree system बनाना जैसे development infrastructure improvements के ज़रिए 6 हफ्तों में commit की संख्या तेज़ी से बढ़ने के अनुभव का सार
• /git-pr skill से PR बनाने की प्रक्रिया automate करके context switching cost हटाई गई, और agent ने खुद अधिक विस्तृत PR description लिखी
• build tool को SWC पर switch करके server restart समय 1 सेकंड से कम किया गया, जिससे flow टूटे बिना development environment मिला
• Claude Code की preview feature से agent खुद UI verify कर सकता है, जिससे हर बदलाव को developer द्वारा सीधे जाँचने वाली bottleneck समस्या दूर हुई
• हर friction point को क्रम से हटाने पर अगली bottleneck सामने आने वाला Theory of Constraints pattern साफ़ दिखाई देता है
• अब feature implementation से ज़्यादा ध्यान ऐसा infrastructure बनाने और loop speed बढ़ाने पर है जिससे agent अधिक कुशलता से काम कर सके

---

सरल दोहराव वाले कामों का automation

• शुरुआत में changes stage करना, commit message लिखना, PR description लिखना, push करना, और GitHub PR बनाना — यह पूरा process manually किया जाता था
• यह पहचानना कि यह काम सिर्फ़ दोहराव वाला grunt work है, पहला turning point था; भूमिका implementer से agent को manage करने वाले manager में बदल गई
• पहली Claude Code skill /git-pr लिखी गई, जिसने PR creation का पूरा process automate कर दिया
  • agent पूरा diff पढ़कर changes का सही summary बनाता है, इसलिए हाथ से लिखी तुलना में PR description और भी ज़्यादा detailed होती है
  • codebase की CLAUDE.md में Graphite उपयोग का उल्लेख है, लेकिन व्यक्तिगत रूप से plain git पसंद होने के कारण /git-pr का उपयोग किया गया
• समय बचत से भी बड़ा असर था mental overhead हटना: हर PR लिखते समय होने वाला छोटा context switch — यानी "code के बारे में सोचना → code को समझाने के बारे में सोचना" — गायब हो गया

wait time हटाना

• local preview के लिए बार-बार मौजूदा काम से बाहर निकलकर dev server बंद करना और नई branch पर restart करना पड़ता था
• server build में लगभग 1 मिनट लगता था — इतना लंबा कि focus टूट जाए, लेकिन इतना छोटा कि बीच में कोई और काम भी न किया जा सके
• build को SWC पर ले जाने से server restart समय 1 सेकंड से कम रह गया
  • file save करते ही server पहले से चल रहा होता है, इसलिए ध्यान भंग होने की कोई खिड़की नहीं बचती
  • इसे "अजीब ख़ामोशी वाली बातचीत" और "स्वाभाविक रूप से बहती बातचीत" के अंतर से तुलना की गई

agent द्वारा खुद UI verification

• पहले हर UI change को local preview में खुद check करना पड़ता था, इसलिए हर feature का bottleneck developer ही बन जाता था
• Chrome extension के लगातार crash होने के बाद Claude Code की preview feature पर switch किया गया
  • agent preview set up कर सकता है, session data बनाए रख सकता है, और UI वास्तव में कैसा दिखता है यह खुद देख सकता है
• इसे workflow में integrate करके यह नियम बना दिया गया कि agent UI को खुद verify किए बिना किसी काम को "done" नहीं मान सकता
  • verification delegate होने से developer को सिर्फ़ final review में शामिल होना पड़ता है, और agent लंबे समय तक autonomously चल सकता है
  • agent का अपनी गलती खुद पकड़ लेना अपेक्षा से कहीं अधिक महत्वपूर्ण असर साबित हुआ

parallel worktree system

• fast rebuild और automated preview के बाद अगला friction सामने आया: एक समय में आराम से सिर्फ़ एक ही काम किया जा सकता था
• किसी दूसरे agent या team member के PR को review करने के लिए main से PR branch पर checkout करके rebuild और test करना पड़ता था, लेकिन यह uncommitted changes से टकराता था
  • stash → checkout → rebuild → test → switch back → pop stash, या manual worktree बनाकर port conflict झेलना पड़ता था
• app में frontend और backend के लिए अलग-अलग ports चाहिए थे, और सभी worktree same environment variables share करते थे, इसलिए सब एक ही port पर bind होने की कोशिश करते थे
• इसे हल करने के लिए worktree creation के समय हर server को unique port range अपने-आप assign करने वाला system बनाया गया
  • अब एक साथ 10 previews तक चलाए जा सकते हैं
• जहाँ पहले 2 parallel branches भी भारी लगती थीं, वहाँ अब एक साथ 5 worktrees चलाने का स्तर हासिल हो गया
  • कई agents को अलग-अलग worktree में अलग features build करने के लिए चलाया जाता है, और UI self-verification पूरी होने तक वे autonomously चलते रहते हैं
  • planning phase में गहराई से शामिल होने के बाद code review तक बीच में हस्तक्षेप नहीं करना पड़ता
• review भी काफ़ी smoother हो गया: setup work, rebuild, और port conflict के बिना पढ़ो, verify करो, merge करो वाला flow बन गया

असली बात AI नहीं, infrastructure है

• भूमिका बदल गई: जटिल समस्याएँ खुद हल करने और perfect UI बनाने में समय लगाने के बजाय, agent को प्रभावी बनाने वाला infrastructure बनाना ज़्यादा रोचक हो गया
• यह किसी solo developer से बढ़कर 10 लोगों की team के manager बनने जैसा है
• यह चमकदार काम नहीं बल्कि plumbing जैसा काम है, लेकिन यही तय करता है कि आप flow state में रहेंगे या environment से लड़ते रहेंगे
• Tano में सबसे ज़्यादा leverage feature development से नहीं, बल्कि ऐसा infrastructure बनाने से मिला जिसने commits के flow को तेज़ धारा में बदल दिया

loop: Theory of Constraints का उपयोग

• हर चरण अलग तरह के friction को हटाता है:
  • /git-pr: code changes को PR में बदलने वाली formatting friction हटाता है
  • SWC: change के बाद result देखने तक की waiting friction हटाता है
  • preview feature: changes को check करने वाली verification friction हटाती है
  • worktree system: कई work streams के बीच context switching friction हटाता है
• एक friction हटाते ही अगली bottleneck का तुरंत सामने आना, Theory of Constraints का क्लासिक pattern है
• काम की प्रकृति बदल गई: अब यह सिर्फ़ "code लिखने के tools का उपयोग" नहीं, बल्कि task start → agent code लिखे → preview check करे → diff पढ़ा जाए → feedback या merge → अगला task, इस tight feedback loop का संचालन है
• जब loop काफ़ी तेज़ हो जाए, तो ध्यान भटकने की गुंजाइश नहीं बचती और speed improvement खुद एक game बन जाता है
• अंततः development का लक्ष्य feature बनाना नहीं, बल्कि loop speed को और कितना बढ़ाया जा सकता है यह हो जाता है
  • वह चरण जहाँ speed खुद engineering का आनंद बन जाती है

[t7vonn]

रिव्यूअर के तौर पर, मशीन द्वारा लिखा गया PR Description देखने पर मेरा अनुभव खास अच्छा नहीं रहा। हालांकि, ऐसा भी लगता है कि शायद prompt tuning अच्छी तरह कर ली जाए तो बात बन सकती है..

[GN⁺]

Hacker News की राय

• ऐसा लग रहा है जैसे 90 के दशक वाला ‘साप्ताहिक code line count’ मेट्रिक फिर लौट आया हो
  “ज़्यादा PR करना” इस बात का सबूत नहीं है कि AI अच्छा काम कर रहा है, बस इसका मतलब है कि ज़्यादा चीज़ें merge हो रही हैं
  code quality, bug, और maintenance burden को नज़रअंदाज़ करके सिर्फ output के आधार पर performance मापना, पुराने managers के थोपे हुए खराब metrics से अलग नहीं है
  आखिर में लगता है कि हमने खराब metrics का विरोध नहीं किया था, बल्कि मापे जाने की प्रक्रिया ही पसंद नहीं थी

  • मैं भी AI रोज़ इस्तेमाल करता हूँ, लेकिन ‘line count’ की जगह PR comments·iteration·bug minimization को लक्ष्य बनाता हूँ
    असली लक्ष्य ऐसा code है जो simple हो और असरदार नतीजे दे
    मैं कई agents एक साथ चलाकर अलग-अलग implementations आज़माने देता हूँ, फिर उनमें से अच्छे ideas मिलाकर प्रयोग कर रहा हूँ
    साथ ही docs और requirements इकट्ठा करके agent से सवाल पूछता हूँ, और code review feedback को सामान्यीकृत करके checklist बनाता हूँ ताकि अगली review में उसे लागू किया जा सके
  • लेखक ने burnout और anxiety पर भी blog post लिखी थी; लगता है यह productivity obsession उससे जुड़ी हुई है
    बीमार पड़ने की हद तक काम करना गर्व की बात नहीं, बल्कि यह संकेत है कि system में गड़बड़ी है
  • लेख की पहली पंक्ति में भी वह मानता है: “commit एक खराब metric है, लेकिन मेरे पास सबसे दिखने वाला signal यही है”
  • code line count व्यक्ति-स्तर पर बेकार है, लेकिन पूरे system के आकार का अनुमान लगाने में उपयोगी हो सकता है
    उदाहरण के लिए COCOMO model इतना विश्वसनीय माना जाता है कि अदालत में भी system value estimate करने के लिए इस्तेमाल होता है
  • “हमने खराब metrics का विरोध नहीं किया था, बल्कि measurement से ही नफ़रत थी” — यह बात आखिरकार क्या अच्छे metrics जैसी कोई चीज़ होती भी है इस सवाल पर आ टिकती है
    ज़्यादातर developers खुद को numbers में नहीं बाँधना चाहते
    लेकिन AI समर्थकों का मानना है कि improvement साबित करने के लिए measurement ज़रूरी है

• मेरा मानना है कि LLM का इस्तेमाल cognitive load कम करने की दिशा में होना चाहिए
  इंसान multitasking में कमज़ोर होता है, और LLM उसे अपने-आप ठीक नहीं करता
  मैं Claude से implementation करवाने के बजाय, सीधे implementation process में guide लेने के तरीके से काम करता हूँ
  इससे मैं पूरी प्रक्रिया समझते हुए detail और big picture दोनों एक साथ देख पाता हूँ
  दोहराव वाले और mechanical हिस्से ही Claude को सौंपने चाहिए

  • मैं भी POC-केंद्रित workflow इस्तेमाल करता हूँ
    LLM से समस्या समझने के लिए सवाल पूछता हूँ, core code खुद लिखता हूँ, फिर बाकी implementation plan उससे बनवाता हूँ
    LLM code पढ़ने, समझाने और simple tasks में अच्छा है, और मैं problem-solving की दिशा चुनने पर ध्यान देता हूँ
  • यह idea मुझे इतना पसंद आया कि मैं इसे तुरंत आज़माने वाला हूँ
    LLM ने मेरी तरफ़ से कौन-कौन से निर्णय लिए, यह track करने के लिए “assumption list बनाओ” या “plan में न रहे निर्णयों की सूची दो” जैसे prompts पर प्रयोग कर रहा हूँ
  • कुछ लोगों का कहना है कि इस तरह का high-intensity collaboration मज़ेदार और immersive होता है
    Claude की प्रकृति समझ ली जाए तो validation की efficiency भी बढ़ती है, और अनुभव बढ़ने के साथ quality management भी आसान हो जाता है

• कई agents से बड़े features बनवाने पर आखिरकार review time बहुत बढ़ जाने की समस्या आती है
  क्योंकि किसी और (या AI) का लिखा code पढ़ना, खुद लिखने से ज़्यादा मुश्किल होता है
  test automation से इसे कुछ हद तक cover किया जा सकता है, लेकिन पूरी तरह भरोसा करना कठिन है

  • इसलिए मैं planning stage की सख़्ती पर ज़ोर देता हूँ
    scope, test, और documentation plan को साफ़ रखता हूँ, और code review bots (Sourcery, CodeRabbit, Codescene) के साथ सख़्त linting rules लागू करता हूँ
    BDD, property testing, e2e tests, code audit, और mutation/fuzzing tests तक इस्तेमाल करता हूँ
    agent coding का फ़ायदा यह है कि इससे ऐसे quality control पर समय लगाने की गुंजाइश मिलती है
  • bottleneck यह है कि LLM अक्सर बेवजह लंबा-चौड़ा और अनावश्यक बदलाव कर देता है, जिससे review का दायरा बढ़ जाता है
  • लेकिन simple fixes या UI improvements जैसे low-risk changes के लिए automatic deployment भी संभव है
    100 PRs a day जैसी approach से gradual deployment की कोशिश की जा रही है
  • मैं agent द्वारा बनाया गया code सीधे deploy नहीं करता, बल्कि उसके output results का ही उपयोग करता हूँ
  • code review अभ्यास से काफ़ी तेज़ हो सकता है
    काम को छोटे हिस्सों में बाँटकर और tests पर भरोसा करके AI code review भी हल्की हो जाती है
    मैं test cases को ज़्यादा ध्यान से देखता हूँ, और code review जल्दी समाप्त करता हूँ
    मैं कई agents parallel में नहीं चलाता, फिर भी AI की वजह से productivity निश्चित रूप से बढ़ी है

• अगर PR लिखने की प्रक्रिया सिर्फ automation बनकर रह जाए, तो self-validation का अवसर गायब हो जाता है
  मैंने कई बार PR description लिखते समय अपने code की अजीब बातें पकड़ी हैं
  अंग्रेज़ी में उसे समझाने का वही क्षण आख़िरी sanity check होता था

• worktree system की वजह से context switching आसान हुई है, लेकिन साथ ही मानसिक थकान भी बढ़ी है

  • ऐसा लगता है कि कई agents को parallel चलाने से speed या accuracy पर वास्तव में क्या असर पड़ता है, इस पर research की ज़रूरत है
  • मैं एक समय में 1~2 tasks पर ही ध्यान देता हूँ
    काम को छोटे units में बाँटकर और review cycle छोटा रखकर quality management आसान हो जाता है
  • मैं agent से PR बनवाकर बाद में एक साथ review करने वाली queue जमा करने की strategy अपनाता हूँ
  • मैं कई worktree parallel में चलाता हूँ, लेकिन हर समय उन पर नज़र नहीं रखता
    अच्छा यह लगता है कि मेरे flow को तोड़े बिना, अगले दिन लौटने पर भी काम आगे बढ़ा हुआ मिले

• इस धारणा पर संदेह है कि Claude code को बहुत polished तरीके से पूरा कर देता है
  असल में कई बार feedback और fixes की ज़रूरत पड़ती है, और कई कामों को एक साथ parallel manage करना उल्टा inefficient हो सकता है

• Claude Code सीखने के tool के रूप में क्रांतिकारी है, लेकिन code generation quality अस्थिर रहती है
  Flutter/Dart सीखते समय मैंने Claude से concepts पूछकर पढ़ाई की, और किताब के बिना एक हफ़्ते में app बना पाया
  यह किसी interactive encyclopedia जैसा लगा

  • इस उपयोग के लिए मैं भी पूरी तरह सहमत हूँ। यह सचमुच क्रांतिकारी है
  • बहुत से लोग इसे इसी तरह इस्तेमाल करते हैं
    “इस language में X करने का idiomatic तरीका क्या है?” जैसे सवालों पर यह तुरंत उपयोगी जवाब देता है
    लेकिन दुनिया बदल देने वाली चीज़ से ज़्यादा, यह बस बहुत अच्छा tool है
  • AI का इस्तेमाल इंसानों को replace करने के बजाय learning और mastery को तेज़ करने के लिए होना चाहिए
    लेकिन अत्यधिक marketing पूरी economy पर नकारात्मक असर डाल रही है
    AI jobs replace कर देगा, इस भ्रम की वजह से युवा पीढ़ी careers छोड़ने लगे — यह चिंता की बात है

• यह बात आई थी कि “SWC पर build switch करने के बाद server restart 1 second से कम हो गया”,
  SWC का मतलब Speedy Web Compiler है, जो type checking के बिना तेज़ी से transpile करने वाला tool है
  NestJS docs में भी यही समझाया गया है

• LLM इस्तेमाल करने से productivity explosively बढ़ गई — यह कोई शेख़ी की बात नहीं है
  अगर सब लोग वही tools इस्तेमाल करें, तो बस baseline ऊपर चली जाती है
  ऊपर से, अगर AI-generated बड़े codebase की ठीक से review न हो, तो long-term quality अनिश्चित रहती है

  • performance का आकलन simple comparison से नहीं, बल्कि अपने output और value से होना चाहिए
  • आधुनिक compilers (GHC आदि) इस्तेमाल करके productivity बढ़ी कहना भी इसी संदर्भ में आता है

• LLM productivity बढ़ाता है, लेकिन इसे commit count graph से मापना बेमानी है
  यह उतना ही मूर्खतापूर्ण है जितना LOC से quality का फ़ैसला करना

  • Claude की मदद से मैं भी कुछ ऐसे features, जो महीनों से टल रहे थे, कुछ ही दिनों में implement कर पाया
    code मैं खुद लिखते हुए समझता गया, और Claude task decomposition और review partner के रूप में बहुत मददगार रहा
  • codebase improvement का सबसे अच्छा metric है negative LOC, यानी अनावश्यक code हटाना
  • मेरे अनुभव में सबसे बेहतरीन engineers वे थे जो code कम करते थे
    जटिल code को simple abstraction से बदल देने की क्षमता ही असली productivity है