Compound Engineering : AI-नेेटिव इंजीनियरिंग दर्शन

• सभी इंजीनियरिंग कार्य-इकाइयों को आगे के काम को और आसान बनाने वाली चक्रवृद्धि-आधारित software development methodology के रूप में परिभाषित किया गया है, जिसका मूल 4-स्टेप लूप (योजना → निष्पादन → रिव्यू → चक्रवृद्धिकरण) है जो AI एजेंटों के साथ सहयोग को व्यवस्थित करता है
• दोहराए जाने वाले लूप में इंजीनियर के समय का 80% योजना और रिव्यू पर, और 20% निष्पादन और चक्रवृद्धिकरण पर लगाया जाना चाहिए
• यह plugin फ़ॉर्म में वितरित होता है, जिसमें 26 विशेषज्ञ एजेंट, 23 workflow commands, और 13 skills शामिल हैं, और इसे Claude Code·OpenCode·Codex पर इंस्टॉल किया जा सकता है
• मौजूदा software development की 8 धारणाएँ (जैसे कोड हाथ से लिखा जाना चाहिए, हर लाइन का मैन्युअल रिव्यू होना चाहिए आदि) त्याग देने योग्य विश्वास के रूप में प्रस्तुत की गई हैं, और सिस्टम में अपनी पसंद को encode करने वाले नए सिद्धांत अपनाने की बात कही गई है
• डेवलपर्स के AI अपनाने के स्तर को स्तर 0 (मैन्युअल डेवलपमेंट) से स्तर 5 (parallel cloud execution) तक विभाजित किया गया है, और हर स्तर के लिए level-up करने के तरीके, साथ ही team collaboration, design, research, और marketing तक फैला हुआ व्यापक framework दिया गया है

---

मुख्य दर्शन

• मूल सिद्धांत यह है कि हर इंजीनियरिंग कार्य-इकाई आगे आने वाले काम को और आसान बनाए
• पारंपरिक codebase में हर नई feature जोड़ने के साथ जटिलता बढ़ती जाती है, जिससे 10 साल बाद सिस्टम से जूझने में अधिक समय खर्च होता है
• Compound Engineering में feature सिस्टम को नई क्षमता सिखाते हैं, bug fix भविष्य के पूरे bug वर्ग को समाप्त करते हैं, और patterns tools में बदल जाते हैं, जिससे codebase समय के साथ समझने, संशोधित करने और उस पर भरोसा करने में आसान होता जाता है

मुख्य लूप: Plan → Work → Review → Compound

• Every टीम अपने 5 products (Cora, Monologue, Sparkle, Spiral, Every.to) को मुख्यतः एक-व्यक्ति इंजीनियरिंग टीमों के रूप में चलाती है, और इसे संभव बनाने वाला यही 4-स्टेप लूप है
• पहले 3 चरण (योजना, निष्पादन, रिव्यू) सामान्य हैं, लेकिन चौथा Compound चरण वह मुख्य अंतर है जहाँ चक्रवृद्धि लाभ जमा होते हैं
• चाहे 5 मिनट का bug fix हो या कई दिनों का feature development, वही लूप इस्तेमाल होता है; केवल हर चरण में लगाया गया समय बदला जाता है

• चरण 1: Plan (योजना)

  • requirements को समझना: क्या बनाना है, क्यों बनाना है, और कौन-सी constraints हैं, यह समझना
  • codebase की जाँच: मिलते-जुलते features कैसे काम करते हैं और मौजूदा patterns क्या हैं, इसका विश्लेषण
  • बाहरी रिसर्च: framework docs और industry best practices की जाँच
  • solution design: approach तय करना और किन files में बदलाव होगा यह निर्धारित करना
  • योजना का सत्यापन: पूरी योजना की completeness और consistency की जाँच

• चरण 2: Work (निष्पादन)

  • isolated environment सेट करना: Git worktree (repository की isolated copy) या branch के ज़रिए काम को अलग करना
  • योजना का निष्पादन: एजेंट चरण-दर-चरण implementation करते हैं
  • validation चलाना: हर बदलाव के बाद tests, linting (automated code checks), और type check चलाना
  • प्रगति को ट्रैक करना और issue आने पर योजना को संशोधित करना
  • अगर योजना पर भरोसा है, तो कोड की हर लाइन पर नज़र रखने की ज़रूरत नहीं

• चरण 3: Review (रिव्यू)

  • कई एजेंट parallel में code review करते हैं
  • निष्कर्षों को P1 (अनिवार्य सुधार), P2 (सुझावित सुधार), P3 (सुधार के अवसर) के रूप में प्राथमिकता दी जाती है
  • एजेंट review feedback के आधार पर issues ठीक करते हैं और सुधार के परिणाम को validate करते हैं
  • patterns का रिकॉर्ड: क्या गलत हुआ, इसे दस्तावेज़ित कर दोबारा होने से रोकना

• चरण 4: Compound (चक्रवृद्धिकरण) — सबसे महत्वपूर्ण चरण

  • पारंपरिक development चरण 3 पर समाप्त हो जाता है, लेकिन Compound चरण में सिस्टम सुधार जमा होते रहते हैं
  • अगर पहले 3 चरण features बनाते हैं, तो चरण 4 ऐसा सिस्टम बनाता है जो features को और बेहतर बनाता है
  • किए जाने वाले काम:
    • क्या प्रभावी रहा और क्या नहीं, तथा कौन-सी insights दोबारा इस्तेमाल की जा सकती हैं, इसे दर्ज करना
    • YAML frontmatter के साथ metadata, tags, और categories जोड़कर उसे searchable बनाना
    • नए patterns को CLAUDE.md में जोड़ना, और ज़रूरत पड़ने पर नए agents बनाना
    • यह जाँचना कि “अगली बार सिस्टम इस समस्या को अपने-आप पकड़ सकता है या नहीं?”

plugin संरचना

• 26 विशेषज्ञ एजेंट: review (14), research, design, workflow, documentation आदि, और हर एक किसी विशेष काम में विशेषज्ञ
• 23 workflow commands: मुख्य लूप + utilities
• 13 skills: agent-native architecture, style guide आदि के माध्यम से domain expertise प्रदान करते हैं
• Claude Code, OpenCode (experimental), और Codex (experimental) पर zero-configuration install संभव है

• फ़ाइल संरचना

  • CLAUDE.md: सबसे महत्वपूर्ण फ़ाइल, जिसे एजेंट हर session की शुरुआत में पढ़ते हैं; इसमें preferences, patterns, और project context सहेजे जाते हैं
  • docs/solutions/: हल की गई समस्याएँ searchable documents के रूप में जमा होती हैं, जिससे institutional knowledge बनता है
  • docs/brainstorms/: brainstorm command का output स्टोर होता है
  • docs/plans/: plan command का output स्टोर होता है
  • todos/: priority और status के आधार पर tasks को ट्रैक करता है

मुख्य commands

• /workflows:brainstorm

  • यह command तब इस्तेमाल होती है जब क्या बनाना है, यह स्पष्ट न हो
  • हल्की repo research के बाद, उद्देश्य, उपयोगकर्ता, constraints, और edge cases को एक-एक करके पूछकर स्पष्ट किया जाता है
  • AI approach सुझाता है, और परिणाम docs/brainstorms/ में सेव होकर /workflows:plan को handoff किया जाता है

• /workflows:plan

  • आप जो चाहते हैं उसे समझाने पर यह implementation plan लौटाता है
  • 3 parallel research agents चलते हैं: repo-research-analyst (codebase patterns), framework-docs-researcher (documentation), best-practices-researcher (industry standards)
  • spec-flow-analyzer agent user flow और edge cases का विश्लेषण करता है
  • ultrathink mode सक्षम होने पर /deepen-plan अपने-आप चलता है और 40 से अधिक parallel research agents सक्रिय होते हैं

• /workflows:work

  • यह वह चरण है जहाँ एजेंट वास्तव में code लिखते हैं
  • 4 phases: quick start (Git worktree बनाना और branch setup) → execute (progress tracking के साथ task-by-task implementation) → quality check (वैकल्पिक रूप से 5 से अधिक reviewer agents सक्रिय) → ship it (linting चलाना, PR बनाना)

• /workflows:review

  • PR का 14 से अधिक विशेषज्ञ एजेंट parallel में एक साथ review करते हैं
  • इनमें security (security-sentinel), performance (performance-oracle), architecture (architecture-strategist), data integrity (data-integrity-guardian), code quality (code-simplicity-reviewer), framework-specific reviewers (DHH-rails, Kieran-rails/python/typescript), deployment validation, frontend race conditions, और agent-native reviewer शामिल हैं
  • output को P1 (critical), P2 (important), P3 (minor) के रूप में वर्गीकृत एक single prioritized list में दिया जाता है
  • /resolve_pr_parallel command से findings को अपने-आप ठीक किया जा सकता है (P1 पहले, हर fix isolated execution में)
  • /triage command के ज़रिए findings को एक-एक करके approve/skip/customize कर फ़िल्टर किया जा सकता है

• /workflows:compound

  • हल की गई समस्याओं को भविष्य के reference के लिए दस्तावेज़ित करता है
  • 6 parallel sub-agents चलते हैं: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • YAML frontmatter के साथ searchable Markdown तैयार होता है

• /lfg

  • feature का विवरण देने पर एजेंट योजना, implementation, और review सब करके merge करने योग्य PR सबमिट करता है
  • यह plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound की पूरी pipeline को chain करता है
  • योजना के approval पर pause के बाद यह स्वायत्त रूप से चलता है, और पूरे चरणों में 50 से अधिक एजेंट सक्रिय होते हैं

छोड़ने लायक 8 मान्यताएँ

• "कोड हाथ से लिखना चाहिए"

  • असली ज़रूरत यह है कि maintainable और सही समस्या को हल करने वाला अच्छा कोड लिखा जाए, कौन टाइप कर रहा है यह महत्वपूर्ण नहीं है

• "हर लाइन को मैन्युअल रूप से रिव्यू करना चाहिए"

  • मैन्युअल line-by-line review गुणवत्ता सुनिश्चित करने का सिर्फ़ एक तरीका है, उसी तरह की समस्याएँ पकड़ने वाले automated systems भी प्रभावी हैं
  • अगर नतीजों पर भरोसा नहीं है, तो खुद करके उसकी भरपाई न करें, बल्कि system को ठीक करें

• "सॉल्यूशन इंजीनियर से ही आना चाहिए"

  • AI approach पर रिसर्च, trade-off analysis और option recommendations कर सकता है, इसलिए इंजीनियर की भूमिका है taste जोड़ना — इस codebase, इस टीम और इस context में कौन-सा solution सही है, यह तय करना

• "कोड ही मुख्य output है"

  • कोड पैदा करने वाला system व्यक्तिगत कोड से ज़्यादा मूल्यवान है
  • एक शानदार implementation से ज़्यादा महत्वपूर्ण है लगातार अच्छे implementations पैदा करने वाली process

• "कोड लिखना ही मुख्य काम है"

  • डेवलपर का काम value ship करना है, और कोड उसका सिर्फ़ एक input है
  • planning, review, system training — ये सब भी काम का हिस्सा हैं

• "पहली कोशिश अच्छी होनी चाहिए"

  • पहली कोशिश की defect rate 95% है, दूसरी की भी 50%
  • यह failure नहीं बल्कि process है, और ध्यान तेज़ iteration पर होना चाहिए ताकि तीसरी कोशिश पहली से तेज़ पूरी हो

• "कोड आत्म-अभिव्यक्ति है"

  • कोड टीम, प्रोडक्ट और users का होता है, और जब कोड को self-expression नहीं माना जाता तो feedback लेना, refactoring करना और quality पर बहस करना आसान हो जाता है

• "जितना ज़्यादा टाइप करेंगे, उतना ज़्यादा सीखेंगे"

  • आज muscle memory से ज़्यादा understanding महत्वपूर्ण है
  • जो डेवलपर AI की 10 implementations रिव्यू करता है, वह खुद 2 टाइप करने वाले डेवलपर से ज़्यादा patterns समझता है

बदलाव की प्रक्रिया में मनोवैज्ञानिक चुनौतियाँ

• टाइपिंग कम होने पर कम काम करने जैसा महसूस होना: वास्तव में agents को निर्देश देना implementation से ज़्यादा सोच की मांग करता है
• autonomous execution को लेकर असहजता: इसका मतलब control छोड़ना नहीं, बल्कि constraints, rules और review process में control को encode करना है
• "क्या यह मैंने बनाया है?" जैसा सवाल: planning, review और quality bar तय करना ही असली काम है, AI सिर्फ़ लिखने का हिस्सा करता है

अपनाने योग्य मान्यताएँ

• सिस्टम में taste निकालकर डालें

  • naming conventions, error handling patterns, test approach जैसी डेवलपर की पसंद आम तौर पर document नहीं होती और senior engineers के दिमाग़ में रहती है
  • इन्हें CLAUDE.md या AGENTS.md में लिखना चाहिए, और review, testing, deployment के लिए specialist agents और skills बनानी चाहिए ताकि AI खुद approval लायक कोड तैयार कर सके

• 50/50 नियम

  • engineering time का 50% feature development, 50% system improvement पर लगना चाहिए
  • पारंपरिक रूप से यह 90% feature / 10% बाकी होता है, लेकिन review agent बनाना, patterns document करना, test generator बनाना जैसी चीज़ें भविष्य के features को आसान बनाती हैं
  • review agent में 1 घंटे का निवेश, 1 साल में 10 घंटे review time बचा सकता है

• process पर भरोसा करें और safety net बनाएँ

  • AI assistance को scale करने के लिए हर लाइन का human review संभव नहीं है, इसलिए tests, automated review, monitoring जैसे guardrails बनाना ज़रूरी है
  • अगर output पर भरोसा नहीं है, तो manual review पर वापस न जाएँ, बल्कि उस चरण को भरोसेमंद बनाने वाला system जोड़ें

• environment को agent-native बनाएँ

  • डेवलपर जो देख या कर सकता है, agent भी वही कर सके: tests चलाना, production logs देखना, screenshot debugging, PR बनाना आदि
  • agent को जो काम करने की अनुमति नहीं है, वह सब खुद मैन्युअल रूप से करना पड़ेगा

• parallelization का इस्तेमाल करें

  • पहले bottleneck इंसानी attention था, यानी एक समय में एक task; अब नया bottleneck compute है, यानी एक साथ चल सकने वाले agents की संख्या
  • कई agents और कई features एक साथ चलाएँ, और review, testing, documentation को parallel में करें

• planning ही नया code है

  • planning document अब सबसे महत्वपूर्ण output है
  • पहले code लिखकर बाद में document करने के बजाय, plan पहले लिखने से agent code generate, test और verify करने के लिए इसे source of truth की तरह इस्तेमाल कर सकता है
  • ideas को कागज़ पर बदलना, code में बदलने से सस्ता पड़ता है

• मुख्य सिद्धांतों का सार

  • हर काम की इकाई आगे के काम को आसान बनाए
  • taste को review में नहीं बल्कि system में embed करें
  • खुद काम न करें, system को सिखाएँ
  • review process नहीं, safety net बनाएँ
  • environment को agent-native structure में रखें
  • compound thinking को हर जगह लागू करें
  • delegation की असहजता को स्वीकारें, और perfect लेकिन scale न होने वाले नतीजों के बजाय imperfect लेकिन scalable नतीजे चुनें
  • कम कोड लिखें और ज़्यादा value deliver करें
  • ये सिद्धांत engineering से आगे design, research, writing जैसे उन सभी क्षेत्रों तक बढ़ सकते हैं जहाँ taste और context को codify करना मददगार हो

डेवलपर के विकास के चरण (5-stage ladder)

• Stage 0: मैन्युअल development

  • AI के बिना एक-एक लाइन कोड लिखना, documents और Stack Overflow से रिसर्च करना, print statements से debugging करना
  • इससे दशकों तक अच्छा software बना है, लेकिन 2025 में यह काफ़ी तेज़ नहीं है

• Stage 1: chat-based assistance

  • ChatGPT, Claude, Cursor आदि से सवाल पूछकर code snippets लेना और काम की चीज़ों को copy-paste करना
  • AI research और boilerplate generation को तेज़ करता है, लेकिन हर लाइन खुद रिव्यू करते हुए पूरा control बनाए रखा जाता है

• Stage 2: agentic tools + line-by-line review

  • Claude Code, Cursor Composer, Copilot Chat जैसे agentic tools files पढ़ते हैं और सीधे codebase में बदलाव करते हैं
  • agent जो भी सुझाव देता है, उसे approve/reject करने वाले gatekeeper की भूमिका
  • ज़्यादातर डेवलपर्स इसी चरण में अटक जाते हैं, इसलिए AI delegation का फ़ायदा नहीं उठा पाते

• Stage 3: plan-first, PR-level review

  • यह वह चरण है जहाँ सब कुछ बदलता है: requirements, approach, edge cases सहित विस्तृत plan AI के साथ मिलकर लिखा जाता है
  • plan बनने के बाद AI बिना supervision के implementation करता है, और output का PR के रूप में review होता है
  • Compound Engineering यहीं से शुरू होती है — हर cycle का planning, implementation और review system को सिखाता है, जिससे अगला cycle और तेज़ व आसान हो जाता है

• Stage 4: idea → PR (single machine)

  • आप idea देते हैं और agent codebase research, planning, implementation, testing, self-review, issue resolution और PR generation तक सब कुछ संभालता है
  • आपकी भागीदारी घटकर idea देना, PR review करना, merge करना इन 3 चरणों तक रह जाती है
  • अभी भी एक समय में एक ही computer पर एक ही execution

• Stage 5: parallel cloud execution (multi-device)

  • execution को cloud में ले जाकर parallel execution
  • 3 features के लिए 3 agents एक साथ चलाएँ, और PR तैयार होने पर review करें
  • agents feedback monitor कर सकते हैं और proactively fixes भी सुझा सकते हैं
  • अब भूमिका व्यक्तिगत contributor की नहीं, बल्कि agents की fleet को निर्देशित करने की हो जाती है

लेवल-अप गाइड

• 0 → 1: सहयोग शुरू करें

  • एक टूल चुनें (Cursor with Opus 4.5 या Claude Code आदि) और उसे हर दिन इस्तेमाल करें
  • कोड लिखने से पहले AI से मौजूदा कोड समझाने को कहें ताकि समझ की पुष्टि हो सके
  • टेस्ट, config files, repeat होने वाले functions जैसी boilerplate चीज़ों से delegation शुरू करें
  • हर लाइन को review करके सीखें
  • कंपाउंडिंग कार्य: जो prompts अच्छी तरह काम करें, उन्हें लगातार रिकॉर्ड करें

• 1 → 2: एजेंट access की अनुमति दें

  • agentic mode पर स्विच करें और एजेंट को file system access दें
  • "इस function में test जोड़ो" जैसे single-file, single-purpose, सीमित बदलावों से शुरुआत करें
  • हर action को approve/reject करते हुए trust intuition बनाएं
  • diff को review करें और सिर्फ बदले हुए हिस्सों पर ध्यान दें
  • कंपाउंडिंग कार्य: CLAUDE.md फ़ाइल बनाएं, और एजेंट की गलती होने पर उसमें notes जोड़ें

• 2 → 3: योजना पर भरोसा करें (मुख्य बदलाव)

  • requirements, approach और edge cases को स्पष्ट योजना के रूप में लिखें
  • AI को codebase पढ़ने, patterns खोजने और approach सुझाने की अनुमति दें
  • योजना लिखने के बाद implementation एजेंट को सौंप दें और पूरा होने तक उससे दूर रहें
  • individual steps या code lines की जगह PR स्तर पर review करें
  • कंपाउंडिंग कार्य: हर implementation के बाद, योजना से छूटी बातों को document करें

• 3 → 4: निर्देश नहीं, परिणाम दें

  • "नए comment पर email notification जोड़ो" की तरह outcome दें, implementation कैसे होगी यह एजेंट तय करे
  • क्योंकि एजेंट codebase जानता है और research कर सकता है, योजना भी एजेंट की ज़िम्मेदारी होती है
  • implementation से पहले approach का review करें ताकि गलत दिशा को जल्दी रोका जा सके
  • कंपाउंडिंग कार्य: अच्छी तरह काम करने वाले outcome-केंद्रित निर्देशों की library बनाएं

• 4 → 5: सब कुछ parallel करें

  • execution को cloud पर ले जाकर local machine bottlenecks हटाएं
  • 3 agents को एक साथ 3 features सौंपें
  • ideas, bugs और improvements को queue के रूप में व्यवस्थित करें ताकि एजेंट क्रम से उन्हें संभालें
  • एजेंट को user feedback monitor करने और स्वेच्छा से features सुझाने के लिए सक्षम करें
  • कंपाउंडिंग कार्य: कौन-से काम parallel हो सकते हैं और कौन-से मूल रूप से serial हैं, यह अलग करके document करें

AI आउटपुट approve करने से पहले 3 सवाल

• "यहाँ सबसे मुश्किल फैसला क्या था?" — इससे AI कठिन हिस्सों और निर्णय-बिंदुओं को सामने लाता है
• "आपने कौन-से alternatives खारिज किए, और क्यों?" — इससे विचार किए गए options दिखते हैं और गलत चयन पकड़े जा सकते हैं
• "किस हिस्से को लेकर आपको सबसे कम भरोसा है?" — इससे LLM अपनी कमज़ोरियों को स्वीकार करता है, लेकिन सिर्फ तब जब आप सीधे पूछें

एजेंट-नेटिव आर्किटेक्चर

• मुख्य बात यह है कि एजेंट को डेवलपर के बराबर की क्षमता दी जाए
• अगर एजेंट tests नहीं चला सकता, तो आपको खुद चलाने पड़ेंगे; अगर वह logs नहीं देख सकता, तो आपको खुद debug करना पड़ेगा — यानी जो भी क्षमता नहीं दी जाती, वह manual काम में बदल जाती है

• एजेंट-नेटिव checklist

  • डेवलपमेंट environment: local application चलाना, test suite चलाना, linter और type checker चलाना, DB migrations, dev data seed करना
  • Git operations: branch बनाना, commit करना, remote push करना, PR बनाना, PR comments पढ़ना
  • Debugging: local/production logs देखना (read-only), UI screenshots, network requests inspect करना, error tracking (Sentry आदि) access

• एजेंट-नेटिव को चरणबद्ध तरीके से अपनाना

  • Level 1 (बेसिक डेवलपमेंट): file access, tests चलाना, Git commit — बुनियादी Compound Engineering संभव
  • Level 2 (पूरा local): browser, local logs, PR creation access — Stage 3~4 संभव
  • Level 3 (production visibility): production logs (read-only), error tracking, monitoring dashboards — एजेंट की सक्रिय debugging संभव
  • Level 4 (पूर्ण integration): ticket systems, deployment capability, external service integrations — Stage 5 संभव

• एजेंट-नेटिव mindset

  • feature बनाते समय: "एजेंट इसके साथ कैसे interact करेगा?"
  • debugging करते समय: "एजेंट को क्या-क्या देखने में सक्षम होना चाहिए?"
  • documentation करते समय: "क्या एजेंट इसे समझ सकता है?"

Skip Permissions

• Claude Code का --dangerously-skip-permissions flag हर action पर पूछे जाने वाले permission requests को disable करता है
• इसका नाम जानबूझकर डरावना रखा गया है ताकि इस्तेमाल से पहले लोग सावधानी से सोचें

• कब इस्तेमाल करें

  • इस्तेमाल की सलाह: जब अच्छी planning और review system हो, sandbox environment में काम हो रहा हो, और speed की ज़रूरत हो
  • इस्तेमाल से बचें: जब आप सीख रहे हों (permission requests समझ बढ़ाने में मदद करते हैं), production code पर काम हो, या rollback system न हो

• permission skip करने पर safety mechanisms

  • Git safety net है: एजेंट का काम Git में रिकॉर्ड होता है, इसलिए git reset --hard HEAD~1 से restore किया जा सकता है
  • Tests गलतियाँ पकड़ते हैं: merge से पहले tests चलाएँ
  • Merge से पहले review: implementation के दौरान permissions skip की जा सकती हैं, लेकिन final review ज़रूर करें
  • Worktree से risk isolate करें: risky काम isolated directory में experiment करें

• productivity calculation

  • permissions skip न करने पर लगभग हर 30 सेकंड में prompt आता है, और हर बार "y" टाइप करने से focus टूटता है
  • permissions skip करने पर flow state बनाए रखना संभव होता है, जिससे 5~10 गुना तेज iteration मिलती है और कभी-कभार rollback का risk भी समय की बचत के सामने छोटा पड़ता है

डिज़ाइन workflow

• Baby App approach

  • एक disposable project (baby app) बनाएं जिसमें tests, architecture या breaking changes की चिंता किए बिना खुलकर iterate किया जा सके
  • जब design संतोषजनक लगे, तब colors, spacing, typography और component patterns निकालकर उन्हें मुख्य project में transfer करें

• UX exploration loop

  • कई versions बनाकर click-through करें, और users के साथ functional prototype साझा करके feedback लें
  • Figma mockups के विपरीत, यह वास्तव में clickable होता है
  • prototypes सीखने के लिए होते हैं, और बाद में उचित योजना के साथ शुरुआत से फिर बनाया जाता है

• डिज़ाइनर के साथ सहयोग: Compound flow

  • पारंपरिक flow: designer mockup → developer interpretation → बार-बार revisions
  • Compound flow: designer Figma mockup → /plan को Figma link देना → AI implementation → figma-design-sync agent यह जाँचता है कि implementation और mockup मेल खाते हैं या नहीं → designer screenshots की जगह live version review करता है

• डिज़ाइन पसंद को code में बदलना

  • designer के साथ कुछ features पर काम करते हुए मिले patterns (पसंदीदा colors, form layouts आदि) को skill files में रिकॉर्ड करें
  • इससे AI designer की पसंद के अनुसार, designer के बिना भी design बना सकता है

• डिज़ाइन agents

  • design-iterator: मौजूदा design screenshot का विश्लेषण करता है, सुधारों को दोहराता है और धीरे-धीरे refine करता है
  • figma-design-sync: Figma से design लाता है, implementation से compare करता है, और differences को अपने-आप ठीक करता है
  • design-implementation-reviewer: जाँचता है कि implementation Figma specs से मेल खाता है या नहीं, ताकि visual bugs users तक पहुँचने से पहले पकड़े जा सकें

वाइब कोडिंग (Vibe Coding)

• यह तरीका उन लोगों के लिए है जो खुद code नहीं, बल्कि सिर्फ outcome चाहते हैं: product managers, designers, personal projects आदि
• ladder को छोड़कर सीधे Stage 4 पर जाएँ: जो चाहिए उसे बताएं → एजेंट planning, code, tests, review और PR सब संभालेगा
• कब उपयुक्त है: personal projects, prototypes, experiments, "क्या यह संभव है?" जैसी जाँच, internal tools, UX exploration
• कब उपयुक्त नहीं है: users वाले production systems, ऐसा code जिसे दूसरे लोग maintain करेंगे, security-sensitive apps, performance-critical systems

• वाइब कोडिंग paradox

  • वाइब कोडिंग उल्टा planning ability को बेहतर बना सकती है
  • जब यह स्पष्ट न हो कि क्या बनाना है, तब prototype बनाकर user feedback लें, फिर सब कुछ हटाकर उचित योजना के साथ दोबारा शुरू करें
  • सबसे अच्छा बँटवारा: वाइब कोडिंग से discovery, spec से build — अंतिम implementation में हमेशा spec की जीत होती है

टीम सहयोग

• नई टीम डायनेमिक्स

  • पारंपरिक: व्यक्ति A कोड लिखता है → व्यक्ति B रिव्यू करता है → PR comments पर चर्चा → approval के बाद merge
  • Compound: व्यक्ति A plan बनाता है → AI implementation करता है → AI agent रिव्यू करता है → व्यक्ति B AI review का रिव्यू करता है → मानव approval के बाद merge

• टीम मानक

  • plan approval: चुप्पी approval नहीं है, इसलिए implementation से पहले स्पष्ट sign-off ज़रूरी है
  • PR ownership: कोड किसने लिखा, इससे अलग काम शुरू करने वाला व्यक्ति PR का मालिक होता है, और plan quality, review, fixes, merge के बाद के प्रभाव की ज़िम्मेदारी लेता है
  • मानव review का फोकस: AI review agent जिस PR का विश्लेषण पहले ही कर चुका है, उसमें मानव syntax error, security, performance, style पर नहीं बल्कि intent-केंद्रित review करता है — "क्या यह तय हुई बात से मेल खाता है?", "क्या approach तर्कसंगत है?", "क्या business logic में कोई issue है?"

• communication patterns

  • async by default: plan बनाना, review करना, approve करना — इन सबके लिए meeting की ज़रूरत नहीं, "मैंने plan document बना दिया है, कृपया आज के भीतर comments दें"
  • स्पष्ट handoff: इसमें status, क्या पूरा हुआ, क्या बाकी है, context, और आगे कैसे जारी रखना है — सब शामिल हो

• scaling patterns

  • स्पष्ट ownership + async updates: हर मुख्य feature के लिए एक मालिक हो जो planning, monitoring, review, merge, और team updates संभाले
  • Feature flag + छोटे PRs: जितनी तेज़ी से सभी deploy करते हैं, merge conflicts उतने बढ़ते हैं; छोटे units में deploy करें, main में बार-बार merge करें, और conflicts को तुरंत resolve करें
  • Compound docs = tribal knowledge का विकल्प: "Sarah से पूछो, उसे auth अच्छी तरह पता है" की जगह, Sarah /compound चलाकर solution को document कर दे तो कोई भी उसे search कर सकता है

user research

• research-development gap

  • पारंपरिक: researcher interview करता है → report लिखता है → Google Drive में छोड़ दी जाती है → developer report नहीं देखता → feature में user needs नहीं झलकती
  • Compound: research structured insights बनाती है → insights को plan context में इस्तेमाल किया जाता है → AI planning के समय insights को refer करता है → usage data insights को validate करता है → insights चक्रवृद्धि की तरह जमा होते जाते हैं

• research structuring

  • raw interview notes को AI के उपयोग लायक structured Markdown में बदलना: participant जानकारी, मुख्य insights, quotes, implications, confidence (n/5 participants) शामिल हों

• persona documents

  • goals, frustrations, quotes के साथ persona documents तैयार करें ताकि AI उन्हें refer कर सके

• research-driven planning

  • /workflows:plan चलाते समय research context (interview results, persona patterns, current pain points) शामिल करें ताकि research insights सीधे features से जुड़ें

data pattern extraction

• उपयोगकर्ता product को जिस तरह इस्तेमाल करते हैं, वह क्या बनाना है इसका संकेत देता है

• किन pattern types पर ध्यान दें

  • overuse patterns: अपेक्षा से बहुत ज़्यादा इस्तेमाल होने वाले features, एक ही page पर बार-बार लौटना
  • difficulty patterns: सरल page पर बहुत ज़्यादा dwell time, एक ही action को बार-बार करने की कोशिश, error → retry → error loop
  • workaround patterns: एक जगह से data export करके दूसरी जगह import करना, screens के बीच copy-paste, तुलना के लिए एक साथ कई tabs खोलकर रखना
  • drop-off patterns: flow के बीच में छूट जाना, शुरू किए गए लेकिन पूरे न हुए features

• pattern से feature तक

  • उपयोगकर्ता tables के बीच हफ़्ते में 50 बार data copy-paste करते हैं → "Sync to table B" button को feature बना दें
  • उपयोगकर्ता "template" project बनाकर उसे duplicate करते हैं → first-class template support को feature बना दें

copywriting

• plan में copy शामिल करें

  • ज़्यादातर teams copy को feature बनने के बाद भरने वाली बाद की चीज़ मानती हैं, लेकिन copy user experience का हिस्सा है
  • planning stage से ही email subject, success message, error message जैसी user-facing copy शामिल कर दी जाए तो AI implementation के समय copy पहले से तैयार रहती है

• voice को codify करना

  • principles (इंसान की तरह बोलना, error messages मददगार होने चाहिए, छोटे वाक्य, स्पष्ट शब्द) और किन शब्दों से बचना है (Invalid → didn't work, Error → क्या हुआ यह समझाएँ, आदि) को skill file में लिखें

• copy review

  • /workflows:review process में copy review जोड़ें: clarity, helpfulness, tone, consistency — इन 4 मानकों पर जाँच करने वाला copy-reviewer agent

product marketing

• Compound flow

  • engineer product value proposition के साथ plan बनाता है → AI feature implement करता है → AI plan से release notes बनाता है → release notes से social posts बनते हैं → Playwright से screenshots अपने-आप capture होते हैं → engineer review के बाद सब कुछ साथ में ship करता है
  • सब कुछ एक ही जगह flow होने से handoff की ज़रूरत नहीं, कोई gap नहीं

• release notes generation

  • AI के पास plan, code changes, और tests सब होते हैं, इसलिए वह ठीक-ठीक समझ सकता है कि क्या बनाया गया है
  • पहले user benefits, एक ठोस example शामिल हो, breaking changes का ज़िक्र हो, और 200 शब्दों के भीतर रहे

• changelog generation

  • /changelog command से हाल की main merges देखें, और हर plan/PR को पढ़कर आकर्षक changelog तैयार करें

• automated screenshots

  • Playwright का उपयोग करके marketing screenshots अपने-आप capture करें; engineering से screenshot माँगने की ज़रूरत नहीं, और पुराने screenshots की समस्या खत्म