Compound Engineering Explained

Compound engineering is a methodology for building software with AI in which every piece of work you complete makes the next piece easier, because the learnings get compounded back into the system itself. The speaker developed it while building Kora, an AI email assistant, and later turned it into an Anthropic plug-in that now has tens of thousands of users.

The bigger argument in this walkthrough is not really about the plug-in. It is that using AI tools effectively requires rethinking long-held beliefs about what software development is. Code stops being the primary artifact. Planning becomes the core job function. Trust in the system, agent-native environments, and parallelization become the levers. The video closes with a five-stage maturity model that gives you a concrete way to locate yourself and push toward a fully autonomous loop where ideas turn into pull requests on their own.

If you use the plug-in without understanding the philosophy underneath it, the speaker argues, it is hard to get value out of it. The guide and this video exist to fix that.

Origins of Compound Engineering

Compound engineering started during the build of Kora, an AI email assistant. The speaker was experimenting with prompts, flows, and sub-agents and kept finding patterns that worked better than the default approach. Over time those patterns formed a loop where each completed task made the next one easier, with learnings flowing back into the system rather than just into the engineer’s head. That loop is where the name comes from.

When Anthropic released a way to build plug-ins, the speaker turned the methodology into one. The plug-in now has tens of thousands of users, but the recurring questions, “How do I start? What is this? What is the philosophy?”, made it clear that the tooling alone was not enough. The accompanying guide (at every.to/guide/compeng) is a long, thought-dump-style document meant to be read by humans or dropped into Claude as context. It covers the philosophy, the plug-in commands, and the belief shifts required to actually use the approach.

Rethinking Software Development

The plug-in is the surface. The deeper move is letting go of the beliefs that made traditional development feel right, and adopting beliefs that make AI-assisted development feel right.

Beliefs to Let Go

1. Code must be written by hand. It is fine, and preferable, for the AI to write it.
2. Every line must be reviewed. If you still feel you must review every line, that is the belief to work on first.
3. Solutions must originate from the engineer. You no longer need to be the source of every architectural or functional decision.
4. Code is the primary artifact. The system you use to create code matters more than the code itself.
5. Writing code is the core job function. Planning and brainstorming are now the job. Writing code shifts to the AI.
6. The first attempt should be perfect. Most AI output is iterative. Expecting one-shot perfection sets you up to bounce off the methodology.
7. Code is self-expression. It is, on personal projects. But on a team or in a large codebase, identifying your ego with the code makes the rest of these shifts almost impossible. If you do not write it, your ego may feel hurt, and that hurt will block you from compounding.
8. More typing equals more learning. Many people fear that not typing means not learning. Understanding probably matters more than typing. If you spend more time understanding the codebase and reading code, you can do more. The balance still matters, but typing is no longer the proxy for competence.

Beliefs to Adopt

1. Extract your taste into the system. The compound loop should reflect what makes you happy and gives you energy. Pure CSS, Tailwind, shadcn, Rails, TypeGrid, whatever it is, program your preferences into the system so it builds the way you like.
2. The 50/50 rule. Spend 50% of your time on the actual feature and 50% on the meta-layer: making sure the system itself improves so the next build is better. Invest in the system while you build with it.
3. The 80/20 planning rule. Spend 80% of your time planning and 20% building.
4. Plans are the new code. The quality of the feature tracks the quality of the plan. Use a brainstorm step to figure out what you actually want, then a planning step to produce a detailed, technical version. If both are good, the feature is usually very good.
5. Trust the process, but build safety nets. Trust that the AI will do the right thing, and build the monitoring and review structure that catches it when it does not. Do not fly blind. Do not merge without monitoring. Trust builds slowly as you watch things work and not break.
6. Make your environment agent-native. Anything you can do, your AI assistant should be able to do the same way. If a deployment requires clicking a button, build a CLI that triggers it. If customer support requires logging into a tool, expose that to the agent. The obvious caveat: do not give it write access to production databases or anything else where the blast radius is unrecoverable. Dan’s agent-native guide is the recommended deeper read here.
7. Lean into parallelization. Structure work so multiple agents or processes can run concurrently rather than serially.

The Five Stages of AI Development

The speaker has personally relearned how to work this way several times over the past three years. The stages below are not strictly linear; for any given task you may move back and forth. The aim is to spend most of your time in stages 3, 4, and 5.

Stage 0: Manual

Traditional hand-coding with no AI assistance.

Stage 1: Chat-Based

Copy-pasting code in and out of ChatGPT, or using basic inline commands like Cursor’s Command-K. The AI is a helper sitting next to your editor, not inside it.

Stage 2: Agentic

Multi-step AI agents that can plan and execute across files. Cursor Composer was an early step in this direction without being fully agentic. Windsurf was the first to feel genuinely agentic, and Claude Code kicked off the broader agentic wave.

Stage 3: Plan First, PR-Only Review

The first stage that requires letting go. Instead of yoloing changes, you spend real time on planning, leaning into something software developers always claimed to value. The AI executes the plan, and you only review the final pull request. The crucial compounding step is comparing the plan against the PR, identifying what was missed in the plan, and feeding that back into the system so the next plan is better. This stage is the one you have to get right; if it works for you, you can safely let go further.

Stage 4: Idea to PR

The environment is fully set up, learned, and instrumented. You provide an idea and the system runs it from inception to a finished pull request on its own. Compound engineering’s /sfg command is meant for exactly this: hand off the idea, let the machine do the rest.

Stage 5: Parallel and Autonomous

Fully automated development running off your local machine. A monitoring system catches a bug in production, an autonomous agent picks it up, writes the fix, and submits a PR with no human in the loop. The speaker is operating at stage 5 for some things and stage 3 for others, depending on the task.

If you are below stage 3, the goal is to push yourself there. The guide describes the compounding move that takes you from each stage to the next.

Beyond Software Engineering

Compound engineering’s principles are not limited to traditional engineering work.

• Vibe coding and design. Non-engineers at Every use the plug-in and the philosophy to ship better code, catch edge cases, and turn design intent into working software. Many find it simply easier than coding without it.
• Team collaboration. Solo AI development and team AI development are different problems. Etiquette, communication norms, and shared workflows shift when multiple humans and multiple agents are working in the same codebase.
• User research and data patterns. Even before brainstorming, the methodology applies to structuring user interviews, extracting patterns from support documentation, and organizing copywriting and product marketing workflows.

The guide is designed to be read by humans or by machines. You can read it cover to cover, or drop it into Claude and ask the agent to explain the parts you care about.

Meta

Added: 2026-04-26