- 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 का आनंद बन जाती है
अभी कोई टिप्पणी नहीं है.