Compound Engineering: How Every Codes With Agents

Compound Engineering

Compound engineering emerged from building Cora, an AI chief of staff for your inbox, from scratch. As we battle-tested every pattern, agent, and workflow across many pull requests, we developed personal productivity hacks to make the work go faster. This, in turn, evolved into a systematic approach to AI-assisted development. We're sharing the details of this philosophy because we believe compound engineering will become the default way software is built.

The Philosophy

The core philosophy of compound engineering is that each unit of engineering work should make subsequent units easier—not harder.

Most codebases get harder to work with over time because each feature you add injects more complexity. After 10 years, teams spend more time fighting their system than building on it because each new feature is a negotiation with the old ones. Over time, the codebase becomes harder to understand, harder to modify, and harder to trust.

Compound engineering flips this on its head. Instead of features adding complexity and fragility, they teach the system new capabilities. Bug fixes eliminate entire categories of future bugs. When they are codified, patterns become tools for future work. Over time, the codebase becomes easier to understand, easier to modify, and easier to trust.

The Main Loop

Every runs five products— Cora, Monologue, Sparkle, Spiral, and our website Every.to—with primarily single-person engineering teams. The system that makes this possible is a four-step loop that forms the basis of compound engineering:

Plan → Work → Review → Compound → Repeat

The first three steps—plan, work, and review—should be familiar to any developer. It's the fourth step that separates compound engineering from other engineering. This is where the gains accumulate. Skip it, and you've done traditional engineering with AI assistance.

The loop works the same whether you are fixing a bug in five minutes or building a feature over several days. You just spend more or less time on each step.

The plan and review steps should comprise 80 percent of an engineer's time, and work and compound the other 20 percent. In other words, most thinking happens before and after the code gets written.

1. Plan

Planning transforms an idea into a blueprint, and better plans produce better results. Here are the actions to take and questions to ask yourself at this step:

• Understand the requirement. What's being built? Why? What constraints exist?
• Research the codebase. How does similar functionality work? What patterns exist?
• Research externally. What do the framework docs say? What are the established best practices?
• Design the solution. What's the approach? Which files need changes?
• Validate the plan. Does this hold together? Is it complete?

2. Work

Execution follows the plan. The agent implements while the developer monitors. Within this step, there are a few smaller tasks:

• Set up isolation. Git worktrees (isolated copies of your repository) or branches keep work separate.
• Execute the plan. The agent implements step by step.
• Run validations. Run tests, linting (automated code checking), and type checking after each change.
• Track progress. Check what work has been done, and what remains.
• Handle issues. When something breaks, adapt the plan.

If you trust the plan, there's no need to watch every line of code.

3. Review (assess)

This step catches issues before they ship. More importantly, it captures learnings for the next cycle, which becomes the basis for compound engineering. Here are the actions that happen during review:

• Have multiple agents review the output. Multiple specialized reviewers examine the code in parallel.
• Prioritize findings. Mark findings as P1 (must fix), P2 (should fix), or P3 (nice to fix).
• Resolve findings. The agent fixes issues based on review feedback.
• Validate fixes. Confirm fixes are correct and complete.
• Capture patterns. Document what went wrong to prevent recurrence.

4. Compound (the most important step)

Traditional development stops at step three, but the compound step is where the gains are to be made. The first three steps (plan, work, review) produce a feature. The fourth step produces a system that builds features better each time.

In this final step, these are the actions you should take:

• Capture the solution. Ask yourself: What worked? What didn't? What's the reusable insight?
• Make it findable. Add YAML frontmatter to make sure it is tagged with the right metadata, tags, and categories for retrieval.
• Update the system. Add new patterns into CLAUDE.md, the file the agent reads at the start of every session. Create new agents when warranted.
• Verify the learning. Ask yourself: Would the system catch this automatically next time?

The Plugin

The compound engineering workflow ships as a plugin. Install it, and the full system is ready to use.

Installation

Below are instructions for adding the plugin to some of the most common AI coding tools. Zero configuration is required.

Claude Code

claude /plugin marketplace add https://github.com/EveryInc/every-marketplace

claude /plugin install compound-engineering

OpenCode (experimental)

bunx @every-env/compound-plugin install compound-engineering --to opencode

Codex (experimental)

bunx @every-env/compound-plugin install compound-engineering --to codex

Core Commands

/workflows:brainstorm

When you're not sure what to build, start here.

/workflows:brainstorm Add user notifications

/workflows:plan

Describe what you want and get back a plan for how to build it.

/workflows:plan Add email notifications when users receive new comments

/workflows:work

This is where the agent actually writes the code.

/workflows:work

/workflows:review

Get your PR reviewed by a dozen specialized agents at once.

/workflows:review PR#123

Beliefs to Let Go

We have all been trained to believe certain things about software development. With improvements in AI tools, some of those beliefs are now obstacles. Here are eight of them to unlearn:

'The code must be written by hand'

The actual requirement for you to do your job well as a software engineer is simply to write good code, which can be defined as maintainable code that solves the right problem. Who types—a human or an agent—doesn't matter.

'Every line must be manually reviewed'

Again, a core requirement to be a good engineer is to write quality code. Manual line-by-line review is one method to get there, but so are automated systems that catch the same issues.

'Solutions must originate from the engineer'

When AI can research approaches, analyze tradeoffs, and recommend options, the engineer's job becomes to add taste—knowing which solution fits this codebase, this team, and this context.

'Code is the primary artifact'

A system that produces code is more valuable than any individual piece of code. A single brilliant implementation matters less than a process that consistently produces good implementations.

'Writing code is the core job function'

A developer's job is ship value. Code is just one input in that job—planning, reviewing, and teaching the system all count too. Effective compound engineers write less code than before and ship more.

'First attempts should be good'

In our experience, first attempts have a 95 percent garbage rate. Second attempts are still 50 percent. This isn't failure—it's the process.

'Code is self-expression'

Developers subconsciously see AI-assisted development as an attack on their identity. It feels like a blow to the ego.

'More typing equals more learning'

Many developers fear that by not typing it, they are not learning it. However, the reality is that understanding matters more than muscle memory today.

Transition Challenges

Trust the Process, Build Safety Nets

AI assistance doesn't scale if every line requires human review. You need to trust the AI.

Core Principles

In summary, the beliefs that underpin this new approach to software development are:

• Every unit of work makes subsequent work easier. Code, documentation, and tooling should build on each other and make future work faster, not slower.
• Taste belongs in systems, not in review. Bake your judgment into configuration, schemas, and automated checks. If you don't you'll be spending time manually checking, which does not scale.
• Teach the system, don't do the work yourself. Time spent giving agents more context pays exponential dividends, but time spent typing code only solves the task in front of you.
• Ship more value. Type less code. Your output should be measured by the number of problems solved, not the number of keystrokes you logged.