Compound Engineering: The 80/20 Rule That Changes AI Code Quality
Deep analysis of Every Inc's Compound Engineering methodology — why spending 80% of time on planning and review produces higher quality AI-generated code than the common prompt-burst approach.
Most developers using AI coding tools follow the same pattern: prompt → accept → next. It’s fast, it feels productive, and it produces code that looks right. But every accepted change adds complexity, and over a few weeks the codebase degrades faster than it would with manual development.
Every Inc, the company behind five in-house software products, has been running a different experiment. Their engineers spend 80% of their time on planning and review and only 20% on execution. The result? Each feature makes the next one easier to build, not harder. They call it Compound Engineering.
What Is Compound Engineering?
Compound Engineering is a development methodology built specifically for AI agent-driven coding. The core thesis, articulated by Every CEO Dan Shipper and GM Kieran Klaassen, is that each unit of engineering work should make subsequent units easier — not harder.
In traditional software engineering, every feature adds complexity. More code means more edge cases, more interdependencies, and more bugs. The codebase becomes harder to change over time.
Compound Engineering inverts this. By systematically documenting what works and what doesn’t — and feeding that context back into the development loop — each feature ships with improved context for everything that comes after.
The methodology is packaged as an open-source plugin on GitHub (EveryInc/compound-engineering-plugin), which has amassed 17.7k stars and 1.4k forks under an MIT license. It ships 37 skills and 51 agents supporting 10+ platforms including Claude Code, Codex, Cursor, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, Gemini, and Kiro.
The 80/20 Split
The most provocative claim in Compound Engineering is the time allocation: 80% planning and review, 20% execution and documentation.
| Phase | Time | Activity |
|---|---|---|
| Plan | ~50% | Research, architecture, strategy, implementation planning |
| Review | ~30% | Multi-agent code review, documentation review, design review |
| Work | ~15% | AI-assisted code writing and testing |
| Compound | ~5% | Documenting learnings for future work |
This directly contradicts the common wisdom that AI agents make planning obsolete. Every’s data — validated across five products — suggests the opposite: when agents write all the code, planning becomes more important, not less.
The STRATEGY.md Pattern
At the heart of the workflow is a top-level STRATEGY.md document. This file captures:
- Target problem — What are we solving and why?
- Approach — Technical and architectural direction
- Persona — Who is the user and what do they need?
- Metrics — How do we measure success?
- Tracks — Work streams and dependencies
Every planning skill (/ce-ideate, /ce-brainstorm, /ce-plan) reads this document first. This ensures that all AI-generated plans are coherent with the product’s strategic direction — something that prompt-burst coding completely misses.
51 Specialized Agents
The plugin defines 51 specialized agent prompts as plain markdown files in plugins/compound-engineering/agents/. Each is a carefully crafted system prompt assigned to a specific role:
Reviewer stack (23 agents): Adversarial reviewer, security reviewer, performance reviewer, design-lens reviewer, scope-guardian, correctness reviewer, maintainability reviewer, coherence reviewer, and more. Each brings a distinct perspective to code and documentation reviews.
Researcher layer (7 agents): Web researcher, repo research analyst, Slack researcher, learnings researcher, best-practices researcher, framework-docs researcher, and issue intelligence analyst.
Architecture and strategy: Architecture strategist, pattern-recognition specialist.
Observability: Performance oracle, spec-flow analyzer, session historian, Git history analyzer.
This level of specialization means reviews catch issues that a general-purpose “review this code” prompt would miss. The adversarial reviewer, for example, actively tries to break the proposed solution — a role that requires a specific prompt design.
The Knowledge Compounding Loop
The mechanism that makes compounding work is the knowledge loop:
- Research — Agents gather context from the codebase, commit history, and web
- Plan — Structured implementation plans with confidence checks
- Work — Agents write code against the plan
- Review — Multi-agent review catches issues
- Compound — Learnings are documented for future use
The /ce-compound skill captures solved problems, failed approaches, and architectural decisions. A companion skill, /ce-compound-refresh, manages stale or drifting learnings — deciding whether to keep, update, replace, or archive each entry.
Over time, this creates a knowledge flywheel. Every bug fix, every feature, every design decision improves the context available to future agents. The codebase doesn’t just grow — it gets smarter.
Comparison with Prompt-Burst Development
| Aspect | Prompt-Burst | Compound Engineering |
|---|---|---|
| Planning | Minimal — prompt and iterate | Structured — research, strategy, plan |
| Review | Ad-hoc — eyeball the diff | Systematic — multi-agent with personas |
| Knowledge | Lost after session | Captured and compounded |
| Code quality | Degrades over time | Improves over time |
| Team scale | 1:1 (one dev, one agent) | 1:N (one dev orchestrates many agents) |
Key Takeaways
- Planning is the bottleneck, not execution. When agents can write code instantly, the limiting factor is deciding what to build and how.
- Specialized reviewers catch more bugs. A security reviewer, a performance reviewer, and an adversarial reviewer each see different issues in the same code.
- Documentation is infrastructure. The
/ce-compoundskill treats knowledge capture as a first-class engineering activity, not an afterthought. - Strategy alignment matters. The
STRATEGY.mdpattern prevents agents from working at cross-purposes to product goals.
The Compound Engineering Plugin is available at github.com/EveryInc/compound-engineering-plugin. The methodology is described in detail in Every’s Chain of Thought article.