AI को senior engineer की तरह सोचना सिखाना

• AI coding tools में कोड लिखने से पहले planning करवाने की methodology से गलत implementation रोकी जा सकती है और development की speed बढ़ाई जा सकती है
• 8 planning strategies को कठिनाई के स्तर के अनुसार लागू किया जाता है, और हर strategy में खास agent parallel में research करता है, जिसके बाद developer judgement और decision-making करता है
• हर strategy में bug reproduction, best practice search, existing codebase analysis, git history investigation आदि शामिल हैं, और agent द्वारा सीखी गई preferences और patterns अपने-आप जमा होती जाती हैं
• open source के रूप में जारी इस system को Claude Code में install किया जा सकता है, या single feature से शुरू करके धीरे-धीरे developer की सोचने की शैली AI को सिखाई जा सकती है

---

AI planning-केंद्रित development तरीका

• AI के कोड लिखने से पहले उसे plan बनाने देने वाला approach परिचित कराया गया है
  • यह तरीका केवल code लिखवाने की तुलना में feature implementation की speed बढ़ाता है और errors कम करता है
• उदाहरण के तौर पर, email management app Cora के ‘email bankruptcy’ feature के development process को दिखाया गया है
  • 53,000 emails को महत्वपूर्ण mail खोए बिना साफ़ करने वाला feature बनाते समय, AI research agent ने पहले से analysis किया
  • Gmail की 2,000-item limit, system timeout, और user wait time issues पहले ही खोज लिए गए, जिससे गलत implementation रोकी जा सकी

8 planning strategies

Strategy 1: bug reproduction और documentation

• उद्देश्य: fix से पहले bug को reproduce करना और step-by-step guide बनाना
• कब उपयोग करें: Fidelity 1~2, खासकर bug fix के समय
• email bankruptcy feature release के तुरंत बाद 19 users एक failed-job state में फँस गए
  • AppSignal logs की जाँच से पता चला कि Gmail rate-limit errors production में ignore हो रहे थे
  • एक batch fail होने पर पूरा job रुक जाता था, लेकिन user को बताया नहीं जाता था, इसलिए user को बस endless loading spinner दिखता था
• reproduction process के दौरान batch processing और job resume functionality की ज़रूरत सामने आई, और यह स्पष्ट हुआ कि simple retry काफ़ी नहीं है
• compound effect: @kieran-rails-reviewer agent की checklist में यह item जोड़ दिया गया: "external API call करने वाले background jobs में rate limiting handle हो रही है या नहीं, retry है या नहीं, partial state छोड़ी जा रही है या नहीं"

Strategy 2: best practices की जाँच

• उद्देश्य: web पर मिलते-जुलते problem-solving cases ढूँढना
• कब उपयोग करें: हर difficulty level पर, खासकर unfamiliar patterns में
• 2 versions पीछे चल रहे gem को upgrade करते समय agent ने "version X से Y तक upgrade path", "versions के बीच breaking changes", और "common migration issues" खोजे
  • official upgrade guide और वही upgrade करने वाले engineers के 3 blog posts मिले
  • 3 मिनट की research से घंटों के trial-and-error debugging से बचाव हुआ
• non-technical decisions में भी उपयोगी: "SaaS pricing tier best practices", "email drip campaign conversion copy", "background job retry strategy" आदि
• compound effect: उपयोगी patterns मिलने पर वे अपने-आप `docs/*.md` files में save हो जाते हैं, ताकि अगली बार मिलते-जुलते सवाल पर web search से पहले वही देखे जाएँ

Strategy 3: codebase investigation

• उद्देश्य: existing code में similar patterns खोजना
• कब उपयोग करें: हर उस काम में जहाँ existing functionality से overlap होने की संभावना हो
• किसी नए feature में event tracking जोड़ने से पहले agent ने codebase में खोजा: "अभी event tracking कैसे handle होती है?", "analytics call pattern क्या है?", "events कहाँ भेजे जाते हैं?"
  • helper methods के साथ मौजूदा tracking system मिल गया (जिसे लेखक खुद भूल चुका था)
  • अगर AI codebase को reference न करे, तो वह अक्सर शुरुआत से नया system बनाने की कोशिश करती है
• नया tracking system बनाने के बजाय existing pattern को extend करके काम हुआ, जिससे incompatible दूसरे system के बनने से बचाव हुआ
• compound effect: "@event-tracking-expert" agent बनाया गया, जो tracking की ज़रूरत वाली हर feature planning में अपने-आप चलता है

Strategy 4: library source code investigation

• उद्देश्य: installed packages और gems का source code सीधे पढ़ना
• कब उपयोग करें: तेज़ी से बदलती या कम-documented libraries के साथ
• RubyLLM gem में नए models, parameters और features लगातार जुड़ते रहते हैं, लेकिन documentation पीछे रह जाती है
  • agent ने RubyLLM source code का analysis किया: "कौन से model options उपलब्ध हैं?", "कौन से parameters pass किए जा सकते हैं?", "latest version में undocumented features क्या हैं?"
  • इसने बताया: "version 1.9 में streaming support जोड़ी गई है, लेकिन documentation नहीं है। test suite में parameter names और usage examples मौजूद हैं"
• compound effect: dependency update होने पर knowledge भी अपने-आप update हो जाती है, इसलिए पुरानी जानकारी पर काम नहीं करना पड़ता

Strategy 5: git history research

• उद्देश्य: commit history का analysis करके पुराने decisions के पीछे की मंशा समझना
• कब उपयोग करें: refactoring, काम आगे बढ़ाने, या "क्यों" समझने की ज़रूरत हो तब
• पुराना EmailClassifier version इस्तेमाल होता मिला, तो upgrade की कोशिश से पहले git history में खोजा गया: "हम v1 क्यों इस्तेमाल कर रहे हैं?", "क्या v2 upgrade पहले कभी try किया गया था?"
  • 3 महीने पहले का दूसरे teammate का PR मिला: v2 पर upgrade करने के बाद inbox emails archive में जा रहे थे, और archive emails inbox में आ रहे थे
  • PR discussion में विस्तार से कारण लिखा था और यह भी दर्ज था कि rollback जानबूझकर किया गया था
• compound effect: institutional memory सुरक्षित और searchable हो जाती है, और नए team members पुराने decisions की reasoning विरासत में पाते हैं

Strategy 6: prototyping से requirements स्पष्ट करना

• उद्देश्य: अलग environment में तेज़ prototyping से requirements स्पष्ट करना
• कब उपयोग करें: Fidelity 3, UX uncertainty, exploratory work
• email Brief interface को redesign करते समय 5 अलग layout prototypes Claude में, हर एक 5 मिनट में बनाए गए
  • उन्हें खुद click करके असुविधाएँ समझी गईं, और कुछ users को best version दिखाया गया
  • एक user feedback: "layout बहुत overwhelming है और email archive कैसे करना है, समझ नहीं आ रहा"
• यह insight बाद में वास्तविक plan की requirement बन गई: "archive button को top-left corner में रखना ज़रूरी है—user की muscle memory Gmail में वही जगह expect करती है"
• compound effect: prototyping uncertainty को concrete specification में बदल देती है और user reactions को document कर देती है

Strategy 7: options के साथ synthesis

• उद्देश्य: सारी research को trade-offs वाले एक plan में समेटना
• कब उपयोग करें: research stage खत्म होने के बाद, implementation से पहले
• Strategy 1~6 के बाद agent ने synthesis किया: "इस research के आधार पर समस्या सुलझाने के 3 तरीके बताओ। हर approach की implementation complexity, performance impact, maintenance burden, और matching existing patterns समझाओ"
• Gmail inbox sync उदाहरण:
  • Option A—existing sync system का उपयोग: implementation तेज़, लेकिन code duplication और concern separation कमजोर
  • Option B—real-time sync: architecture साफ़, लेकिन धीमा और reliability issues की संभावना
  • Option C—mirror caching system बनाना: लंबे समय के लिए सबसे अच्छा solution, सबसे साफ़ separation, लेकिन शुरुआती काम सबसे ज़्यादा
• तुलना देखने के बाद 30 सेकंड में informed choice की जा सकती है
• compound effect: चुना गया option preferences दिखाता है; अगर "compatibility first" preference दी जाए, तो अगली बार system वैसी decisions में compatibility को ज़्यादा weight देता है

Strategy 8: style agent review

• उद्देश्य: तैयार plan को developer preferences check करने वाले specialized reviewer को देना
• कब उपयोग करें: final planning stage, implementation से पहले
• अपने-आप चलने वाले 3 review agents:
  • simplification agent: overengineering flag करता है, "क्या इस feature के लिए सचमुच 3 database tables चाहिए? type field वाली 1 table से काम नहीं चल सकता?"
  • security agent: सामान्य vulnerabilities check करता है, "यह plan user input को database query में सीधे जाने देता है—input sanitization जोड़नी होगी"
  • Kieran style agent: personal preferences लागू करता है, "यहाँ complex join इस्तेमाल हो रही है; Kieran simple queries पसंद करता है, denormalization पर विचार करो"
• compound effect: agents समय के साथ developer की पसंद जमा करते जाते हैं; "यह पसंद नहीं" या "अच्छा पकड़ा" जैसे feedback से system सीखता है

शुरुआत कैसे करें

आज ही आज़माने का तरीका

• Every का Github marketplace पर planning system open source के रूप में जारी है
• Claude Code में install करने पर /plan slash command और research agents तुरंत इस्तेमाल किए जा सकते हैं
• Claude Code या Droid में plugin का उपयोग किया जा सकता है

सरल शुरुआत

• इस हफ़्ते बन रही किसी एक Fidelity 2 feature को चुनें: ऐसा काम जो कई files में फैला हो और जिसका scope साफ़ हो (नई view जोड़ना, feedback system बनाना, component refactoring)
• Claude Code या Cursor से build करवाने से पहले 15~20 मिनट research करें:
  1. best practices: दूसरे लोग इसे कैसे हल करते हैं? web पर blog posts, Stack Overflow, documentation खोजें
  2. अपने patterns: आप खुद इसे कैसे हल करते हैं? अपने existing codebase में similar features खोजें
  3. library capabilities: जिन tools का उपयोग हो रहा है वे वास्तव में क्या support करते हैं? AI से documentation या source code पढ़वाएँ
• AI से इस research को ऐसे plan में synthesize करवाएँ जिसमें ये शामिल हों:
  1. हल की जाने वाली समस्या (एक साफ़ वाक्य में)
  2. 2~3 solution approaches (हर एक के ईमानदार pros/cons)
  3. existing code patterns जिनसे match होना चाहिए
  4. edge cases या security considerations
• plan को review करें और अपनी reaction देखें: अगर मन में आए "यह बहुत complex है" या "इससे बेहतर तरीका पहले से है", तो सिर्फ plan न बदलें, बल्कि आप ऐसा क्यों सोचते हैं उसे पकड़कर लिखें
• plan के आधार पर feature release करें, फिर final implementation की original plan से तुलना करें—कहाँ deviation हुआ? क्यों? plan को और बेहतर क्या बना सकता था?
• 10 मिनट लगाकर एक learning को formalize करें: उसे CLAUDE.md file में जोड़ें, जैसे "X type के काम में Y check याद रखें" या "कारण C की वजह से approach B की जगह A पसंद है"
• learning जमा होने के बाद specialized research agents या commands बनाएँ: "Event Tracking Expert" (आपके patterns जानता हो), "Security Checker" (common mistakes flag करता हो)
• अगले हफ़्ते दोहराएँ, notes देखें, जाँचें कि दूसरा plan पहले से बेहतर है या नहीं, और कुछ महीनों में ऐसा system बनाएँ जो developer की सोच को जानता हो