This document introduces a unique software development philosophy and methodology called 'Compound Engineering'. This methodology ensures that each unit of engineering work contributes to making the next task easier, helping the code base become more understandable, easier to modify, and more reliable over time. In particular, it focuses on the four-step loop (planning - work - review - compound) that actively utilizes artificial intelligence (AI) tools to maximize development efficiency. It presents traditional beliefs that developers should discard in the AI era, new ways of thinking that should be adopted, and specific best practices applicable to various development fields.
1. 컴파운드 엔지니어링의 철학 ✨
The core philosophy of compound engineering is that every unit of engineering work should make subsequent units easier. 보통 코드베이스는 새로운 기능을 추가할수록 복잡성이 증가해서 시간이 지날수록 다루기 어려워지죠. But compound engineering reverses this process, allowing feature additions to teach the system new capabilities, bug fixes to eliminate similar future bugs, and patterns to become tools for future work. Ultimately, the goal is for the codebase to become more understandable, easier to modify, and more reliable over time. 🚀
2. Key 4-step loop: Plan → Work → Review → Compound 🔄
Every operates primarily as a one-person engineering team on five products: Cora, Monologue, Sparkle, Spiral, and Every.to. The secret to making this possible is the four-step loop: Plan → Work → Review → Compound → Iterate**. The first three steps will be familiar to the average developer, but the fourth step, 'Compound', is what makes compound engineering special. The benefits gained at this stage accumulate! Skipping this step will just end up being traditional engineering with the help of AI.
This loop works the same whether you're fixing a 5-minute bug or building a feature over several days; the only difference is how long each step takes. Ideally, engineers should spend 80% of their time on Planning and Review and 20% on Work and Compound. 즉, 코드 작성 전후에 대부분의 사고 과정이 일어나는 거죠.
2.1. Step 1: Planning 💡
Planning is the process of turning an idea into a blueprint. Good planning produces better results. At this stage, you need to ask yourself the following questions and take action.
- Understanding Requirements: "What are we building and why are we building it? What are the constraints?"
- Codebase Study: "How do similar features work? What patterns exist?"
- External Research: "What does the framework documentation say? What are the established best practices?"
- Solution Design: "What approach will we use? Which files will need to change?"
- Plan Verification: "Is this plan solid and complete?"
2.2. Step 2: Work 👷♀️
Actions are the steps that put your plan into action. The AI agent carries out implementation while the developer watches. This step involves several small tasks.
- Isolation settings: Separate work using
Git worktreeor branches. - Plan Execution: The agent implements the plan step by step.
- Run validation: Run testing, linting, and type checking after each change.
- Progress Tracking: Check completed and remaining tasks.
- Problem handling: If a problem arises, revise the plan.
"If you trust the plan, you don't need to watch every line of code."
2.3. Step 3: Review (Evaluate) 🧐
This step plays a critical role in discovering and resolving issues before they are deployed. Furthermore, it lays the foundation for compound engineering by capturing learnings for the next cycle.
- Multiple agents review output: Multiple expert reviewers review code in parallel.
- Prioritize results: Prioritize as P1 (required modifications), P2 (recommended modifications), and P3 (recommended modifications).
- Resolve as a result: Agent fixes the issue based on review feedback.
- Verify edits: Make sure your edits are accurate and complete.
- Pattern Capture: Document the pattern in which the problem occurred to prevent recurrence.
2.4. Step 4: Compound (the most important step!) 🌟
Traditional development ends at stage 3, but it is only in the compound stage that the real benefits are achieved. While the first three steps are about building features, the fourth step is creating a system that allows you to build better features every time. In this final step, you need to take the following actions:
- Solution Capture: Ask yourself, "What worked, what didn't? What are the reusable insights?"
- Make it easier to find: Add a
YAML frontmatterso that you can be tagged with the correct metadata, tags, and categories for search. - System Update: Add new patterns to the
CLAUDE.mdfile that the agent reads at the start of every session, and create new agents if necessary. - Learning Validation: Ask yourself, "Will the system automatically detect this problem next time?"
3. Plugins and core commands 🔌
Compound Engineering Workflow is provided in the form of a plug-in, so you can use it right away by simply installing it. This plugin includes 26 expert agents, 23 workflow commands, and 13 domain expertise (skills).
3.1. plugin component
- 26 specialized agents: Each agent is trained for a specific task.
- 23 workflow commands: including main loop and utilities.
- 13 skills: Provides domain expertise such as agent native architecture skills and style guide skills.
3.2. Important files 📁
CLAUDE.md: The most important file that the agent reads during each session. Record developer preferences, patterns, and project context here, and add notes so the agent can learn when problems arise.docs/solutions/: Solved problems become searchable documents that contribute to institutional knowledge. Past solutions can be found automatically in future sessions.todos/: Track to-do items with priority and status. Based on the issues found in the review phase, decide what is worth fixing and use the fix command to proceed with the work.
3.3. Key commands 🚀
-
/workflows:brainstorm: When you're uncertain about what to build, brainstorm ideas and ask the questions you need to plan. A lightweight repository conducts research, asks questions to clarify the purpose, users, constraints, etc., then proposes an approach. The decision is stored in docs/brainstorms/. -
/workflows:plan: Describe what you want and it will create a build plan. We conduct codebase pattern research, framework documentation research, and best practice research in parallel, and analyze user flows and edge cases to create a structured plan including affected files and implementation steps. By activatingultrathinkmode, you can even deepen your planning using over 40 parallel research agents. -
/workflows:work: Command that causes the agent to actually write code. It creates agit worktree(quick start), implements each task (run), performs quality checks (quality check), and finally runs linting and generates a PR (ship). -
/workflows:review: Have PRs reviewed simultaneously by 12 or more expert agents. It analyzes various aspects such as security, performance, architecture, data integrity, code simplicity, etc. in parallel and provides a prioritized list.- Review Agents: 14 specialized agents, including
security-sentinel,performance-oracle, andarchitecture-strategist, analyze code in their respective areas and report prioritized issues. - Automatically resolve: Use the
/resolve_pr_parallelcommand to automatically process all findings. You can fix P1 issues first, with each fix running in isolation, and ultimately manually reviewing the resulting fixes.
- Review Agents: 14 specialized agents, including
-
/triage: Presents each finding one by one so people can make their own decisions. There are options to approve (add to to-do list), skip (delete), and customize (edit priority/details). -
/workflows:compound: Command to document the solved problem for future reference. Create searchable Markdown documents by creating six parallel sub-agents to analyze problem context, extract solutions, link related documents, relapse prevention strategies, categorize, and create documents. -
/lfg: Enter your feature description and our agent will handle everything - plan, build, review, and even merge-ready PRs. With this one command, you connect the entire pipeline (Plan → Deep Planning → Tasks → Review → Resolve Findings → Browser Testing → Feature Video → Compound) and run 50+ agents at every stage.
4. Beliefs to abandon and beliefs to adopt 🤔
With the advancement of AI tools, some of our beliefs about software development may now get in the way.
4.1. Beliefs that must be abandoned 🙅♀️
- 'Code should be written by hand': What matters is good code that is maintainable and solves problems, and it doesn't matter who writes it.
- 'Every line must be reviewed manually': Automated systems can catch the same problems. If you don't trust the system, you need to fix it.
- 'Solutions must come from engineers': When AI can study approaches, analyze pros and cons, and recommend options, the engineer's role shifts to adding a sense of 'which solution is right'.
- 'Code is the primary output': The system that produces the code is more valuable than individual pieces of code.
- 'Writing code is a core business function': The developer's role is to provide value, and code is just an input.
- 'First try should be good': In our experience, 95% of first attempts are crap. The goal should be to complete the third attempt in less time than the first attempt through rapid repetition.
- 'Code is self-expression': Code belongs to the team, product, and users, and moving away from the idea that it's self-expression makes you more receptive to feedback and less hesitant about refactoring.
- 'The more you type, the more you learn': Understanding is now more important than muscle memory. Learning is reviewing AI implementation and knowing the mistakes and errors of AI.
4.2. A belief to adopt 🙏
- 50/50 Rule: 50% of your engineering time should be devoted to building features and 50% to improving systems (any work that helps build institutional knowledge). System improvements make future features easier and faster.
- Trust the process and build a safety net: Instead of having to manually review every line, you need to trust AI by building safety nets such as testing, automated reviews, and monitoring.
- Make the environment agent-native: The environment must be built so that the agent can do everything that the developer can do. Limiting functions to AI increases the amount of work developers will have to do manually.
- Leverage parallelism: While humans can only do one task at a time, AI agents can execute multiple tasks in parallel. Run multiple agents simultaneously to maximize efficiency.
- Planning is the new code: Planning documents become the most important deliverables. Instead of writing code first and documenting it later, start with a plan and make it a source of truth that agents use to create, test, and verify code.
4.3. Core Principles 🌟
The core principles of this new software development approach are:
- Every unit of work makes the next task easier.
- Taste belongs to the system, not review.
- Teach the system, don't do all the work yourself.
- Establish a safety net, not a review process.
- Make the environment agent-native.
- Apply compound thinking everywhere
- Accept the discomfort of giving up.
- Provide more value, type less code.
5. Getting started: AI utilization step-by-step roadmap 📈
The compound engineering loop is a process, but the scope of the process to be entrusted to AI varies depending on the familiarity and ability with AI. Here are five steps developers can take to determine where they stand and take the next step.
5.1. Phase 0: Manual Development ✍️
This is the stage where you directly write code lines without AI, examine them through documents, and debug with print statements. 2025 isn't fast enough.
5.2. Step 1: Chat-based support 💬
It uses AI as a smart reference tool, asking questions to ChatGPT, Claude, Cursor, etc. and copy-pasting code snippets. AI accelerates research and boilerplate creation, but still reviews and fully controls every line.
5.3. Step 2: Agent Tools and Line-by-Line Review 🤖
Steps include using agent tools such as Claude Code, Cursor Composer, and Copilot Chat that can read files and make changes directly. It allows the AI to access and change files, but the developer acts as a gatekeeper, approving or rejecting all suggestions. Most developers get stuck at this stage and don't take advantage of leaving more to AI.
5.4. Step 3: Plan first, review PR only 📝
From this stage onwards, everything changes. Developers and AI jointly develop a detailed plan including requirements, approach, and edge cases. Developers then let the AI implement the plan without supervision and review the resulting PR. Only then can we move away from intervention at the line-of-code level and identify problems in PR reviews. This is the stage where compound engineering begins.
5.5. Step 4: From idea to PR (single machine) 🚀
개발자가 아이디어를 제공하면 에이전트가 코드베이스 연구, 계획, 구현, 테스트 실행, 자체 검토, 문제 해결, PR 생성 등 모든 것을 처리합니다. Developer involvement is reduced to three steps: ideation, PR review, and merge. But you're still just running one task at a time on your own computer.
5.6. Step 5: Run parallel clouds (multiple devices) ☁️
As a final step, we move execution to the cloud to run multiple tasks in parallel. All three features start simultaneously, three agents work independently, and developers review PRs once they are complete. You can even go further and have agents monitor feedback and suggest corrections without you asking. Now you become a commander 'commanding the fleet' rather than an individual contributor.
6. Three questions before approving AI output 🤔
Even without an advanced multi-agent review system, there are many benefits to asking these three questions before approving AI artifacts:
- "What was the most difficult decision here?"
- Let AI reveal difficult areas and where judgment was needed.
- "Which alternatives did you reject and why?"
- AI shows you the options considered, helping you figure out if you made the wrong choice.
- "What are you most unsure about?"
- Force the AI to admit its weaknesses. LLM knows his weaknesses, but he will answer only if you ask.
7. Best practices 🌟
7.1. Agent Native Architecture 🏗️
Agent-native architecture means giving agents the same capabilities that developers have. If the agent can't run the tests, you'll have to do it yourself, and if you can't see the logs, you'll have to debug it yourself. Any functionality you don't give to AI becomes a task for developers to handle manually.
7.1.1. Agent Native Checklist ✅
Find out if your agent can:
- Development Environment: Run the application locally, run the test suite, run linters and type checkers, run database migrations, and seed development data.
- Git operations: Create branch, commit, push to remote repository, create PR, read PR comments.
- Debugging: View local logs, view production logs (read-only), take UI screenshots, inspect network requests, access error tracking (Sentry, etc.).
7.1.2. Progressive Agent Native 🚀
There is no need to be 100% agent native from the beginning. Grant access to agents incrementally.
- Level 1: Basic Development: Access files, run tests, commit Git.
- Level 2: Fully local: Browser access, local logs, ability to create PRs.
- Level 3: Production Visibility: Access to production logs (read-only), error tracking, and monitoring dashboards.
- Level 4: Fully integrated: Ticket system access, distribution capabilities, external service integration.
7.2. Skip permission 🛑
The --dangerously-skip-permissions flag disables the permission prompt that Claude Code asks before every operation, such as creating a file. The name is intentionally scary and makes you think before using it, but at level 3 and above in compound engineering, constant permission requests will disrupt the flow.
7.2.1. When to use it 🟢
- When you trust the process: When you have a good plan and a good review system.
- In a safe environment: When working in a sandbox without affecting real users or live products.
- When you want speed: When permission requests slow down your workflow.
7.2.2. When not to use 🔴
- When you're learning: When a permission request helps you understand what's happening.
- In production: Never use this when working with production code as it impacts real users.
- When rollback is difficult: Stay prompted when recovering from a mistake is not easy.
7.2.3. Safety measures 🛡️
- Git: Everything the agent does is recorded in Git, so it can be easily reversed.
- Test: Run tests before merging to see if the agent caused the problem.
- Pre-merge review: Skipping permissions only skips the implementation prompt, a final PR review is required.
- Worktree: Use
git worktreefor risky tasks to isolate risks.
7.3. Design Workflow 🎨
Designs are easier to iterate in code than in mockups. But you don't want to experiment on a production codebase.
7.3.1. Baby app approach 👶
Create temporary projects, "baby apps," to freely iterate on your design without worrying about testing, architecture, or breaking existing code. Once we are satisfied with the design, we extract the patterns and apply them to the actual project.
7.3.2. UX Discovery Loop 🔎
When you don't know what to build, create multiple versions of the prototype and gather user feedback to learn. Remember that prototypes are for learning purposes only, not for distribution.
7.3.3. Collaboration with designers 🤝
In compound engineering, a designer creates a Figma mockup, AI implements it accurately, and the figma-design-sync agent verifies that the implementation matches the mockup. Designers review the live version and iterate until it's perfect.
7.3.4. Codification of design tastes 💅
After you've worked out a few features with your designer, record your preferred patterns of color, spacing, typography, etc. in a skill file. This allows AI to create designs that suit the designer's tastes without the designer's intervention.
7.4. Vibe Coding 🧘♀️
Vibe coding is for people who are not interested in the code itself and only want the results. It's perfect for product managers prototyping ideas, designers testing interaction feel, or building personal projects. The goal is to verify that your code works.
7.4.1. Vibe Coder's Philosophy 💫
The method is to move directly to step 4, where you explain to the AI what you want and have the agent build it. No need to worry about code quality, architecture, testing, or best practices.
7.4.2. When to use 🕰️
- Perfect: Personal projects, prototypes, experiments, internal tools, UX exploration.
- Not suitable: User-driven production systems, code that will be maintained by others, security-sensitive apps, and performance-critical systems.
7.4.3. Vibe Coding Paradox 🧩
Vibe coding can also make your plans better. When you don't know what you want, you can create a prototype, gather feedback, then delete everything and start again with a proper plan. Vibe coding accelerates discovery, and detailed specifications are responsible for final implementation.
7.5. Team Collaboration 🤝
Team dynamics change when AI handles implementation. We need a new consensus on who approves the plan, who owns the PR, and what needs to be reviewed by humans after the agent completes the first review.
7.5.1. New team dynamics 🔄
- Traditional: Developer A writes code → Developer B reviews → discuss in PR comments → merge after approval.
- Compound: Developer A creates plan → AI implements → AI agent reviews → Developer B reviews AI review again → Merge after human approval.
7.5.2. Team standards 📏
- Planning Approval: Requires explicit approval prior to implementation.
- PR Ownership: The person who initiated the work owns the PR and is responsible for the quality of the plan, review of the work, resolution of issues, and post-merge impact.
- Focus of Human Review: If an AI review agent has already analyzed the PR, human reviewers should focus on 'intent' and not implementation. Check for business logic issues, etc., and leave syntax errors, security vulnerabilities, etc. to AI.
7.5.3. Communication patterns 🗣️
- Asynchronous by default: Plan creation, review, and approval can occur asynchronously without meetings.
- Explicit handoff: When handing over a task, you should include everything you need: status, completed work, remaining work, context, and how to continue.
7.6. User Research 🧑💻
Research needs to be structured so that AI can use it. Create persona documents, connect insights with features, and close the loop between research and implementation.
7.6.1. Research-Development Gap 🌉
- Traditional: Researcher interviews → writes report → report sits in Google Drive → developer builds feature → developer does not read report → feature does not meet user needs.
- Compound: Research generates structured insights → Insights become planning context → AI references insights in planning → Builds research-based capabilities → Usage data validates insights → Insights accumulate.
7.6.2. Structuring your research 📑
Instead of writing raw interview notes that are difficult for AI to use, structure them with key insights, quotes, takeaways, convictions, etc.
7.6.3. Building a Persona Document 🎭
Create a persona document that AI can reference, including goals, complaints, quotes, and more.
7.6.4. Research-based planning 🗺️
By providing relevant research context for planning, we guide AI to design features that meet user needs.
7.7. User Behavior Analysis 📊
Your users are already telling you what to create by how they use your product.
7.7.1. Types of patterns to look for 📈
- Heavy usage patterns: Pages that are used much more than expected or are visited repeatedly.
- Difficult Pattern: High dwell time on simple pages, repeated attempts to do the same thing, error → retry → error loop.
- Solution pattern: When the product doesn't provide what the user needs, so they create their own solution (e.g. copy-pasting data, using multiple tabs).
- Abandonment Pattern: Abandonment from the user flow or functionality started but not completed.
7.7.2. From pattern to function 💡
You need to create actual product features based on insights gained from user patterns. For example, if you notice that your users are copy-pasting data dozens of times, you might gain insight into the need for automation between tables and create a "Sync with Table B" button.
7.8. Copywriting 📝
Most teams see copy as something secondary to fill in after building features, but copy is part of the user experience and deserves the same attention as code.
7.8.1. Copy included in plan ✍️
From the beginning, your plan should include the text your users will see, codify your brand voice for AI to follow, and review it like any other deliverable.
7.8.2. Codifying your brand voice 🗣️
Create a skill file to define the principles of your brand voice, words to avoid, good examples, etc., and the AI can generate copy tailored to your tastes.
7.8.3. Review copy like code 🧐
Add copy review to the /workflows:review process. The copy-reviewer agent reviews clarity, usability, tone, consistency, etc.
7.9. Product Marketing 📢
Once you've launched something, it's time to tell the world. You can publish it using the same system you used to build the feature.
7.9.1. Compound Flow 🔄
Engineers create a plan including product value proposition → AI implements features → AI generates release notes from the plan → AI generates social media posts from release notes → AI automatically generates screenshots using Playwright → Engineers review everything and release. It's all in one place, so no information is missed.
7.9.2. Create release notes 📝
After implementing a feature, you can ask AI to write release notes based on your plans and implementation. Instruct them to be concise, including user benefits, specific examples, changes, etc.
7.9.3. Create change log 📜
For many features, you can use the /changelog command to read plans/PRs and generate attractive change logs based on recent merges into the main branch.
7.9.4. Automated Screenshots 📸
You can use Playwright to automatically capture screenshots for marketing. No more asking engineers for screenshots or using old screenshots.
Conclusion 🌟
Compound engineering goes beyond simply leveraging AI tools and requires a fundamental shift in thinking about software development. By letting AI handle repetitive, predictable tasks, developers can create even more value by focusing on planning, improving systems, and ensuring the quality of the output AI produces. It may be uncomfortable and unfamiliar at first, but by adopting these new beliefs and best practices and taking gradual steps to leverage AI, development teams will be able to build systems that become more efficient and powerful over time. Ultimately, all of this effort goes toward the goal of "typing less code, delivering more value." 🚀