Deep Dive · XiaoHu Explains

The Fourth Step Every Team Skips Is the Real Key to AI Engineering

Every runs 5 products with essentially solo teams. The core is one extra step after finishing each feature: save the solution into the system so the AI avoids the same pitfall automatically next time.
TL;DR
  • Every uses a methodology called "Compound Engineering" to maintain 5 products with essentially solo engineering teams. The core is a four-step loop: Plan → Work → Review → Compound.
  • Traditional engineering stops at Review. The fourth step, Compound, turns every solved problem into system knowledge so the AI automatically avoids the same mistake next time — that's where the efficiency gap comes from.
  • The method holds that engineers should spend 80% of their time on Plan and Review, and only 20% actually writing code.
  • The companion plugin is open-source and supports Claude Code / OpenCode / Codex, with 26 specialized agents, 23 workflow commands, and 13 skills — works with zero configuration.
  • /workflows:review runs 14 specialized agents concurrently to review code in a single call; /workflows:plan in ultrathink mode can dispatch 40+ research agents concurrently.
Stance note: This piece is Every's own account of its "Compound Engineering" methodology and its own open-source plugin practice. The concurrency scale, time allocation, and product counts here are all the company's own figures. What follows just explains how it works and what each number means.
1Background

How One Person Holds Up Five Products

Every recently published a methodology called "Compound Engineering," along with a companion open-source plugin, explaining how they maintain five products at once with engineering teams that are essentially one person each.

The five products — Cora, Monologue, Sparkle, Spiral — plus the Every.to site itself, each run on an engineering team of basically one person. What holds up that scale isn't longer hours; it's the last step of a four-step loop that most teams skip.

Why it's worth reading: Every open-sourced something that usually only runs internally — including 14 AIs reviewing one piece of code at the same time, 40+ research agents running concurrently during planning, plus 26 specialized agents. This is one of the most concrete open-source references currently public for multi-agent parallel engineering practice.
2Problem

Why Code Gets Harder to Touch Over Time

Most codebases get harder to maintain over time for a simple reason: every feature you add injects a new dose of complexity, and the new feature has to "negotiate" with every old feature. Ten years in, teams spend more time wrestling with legacy code than building new things — the code becomes harder to understand, harder to change, harder to trust.

Compound Engineering flips that curve. A feature is no longer a burden added to the system — it's a new skill the system learns. Fix a bug, and you knock out a whole future class of the same bug along the way. Once a solution is compounded into the system, it becomes a tool you can reuse directly next time. The more you iterate, the better the system gets.

Traditional: harder each time Compound Engineering: gets smoother More features / iterations → Effort per change →
Same x-axis (more features / iterations), two trajectories: a traditional codebase gets harder to touch with each change, while compound engineering makes every iteration a little easier than the last.
3Main Loop

The Four-Step Loop: 80% of the Time Isn't Spent Writing Code at All

What holds up this scale is a four-step loop: Plan, Work, Review, Compound — then repeat. Whether you're fixing a five-minute bug or building a feature that takes days, you walk through the same four steps; only the time spent on each step changes.

The first three steps are familiar to any developer. The fourth step, Compound, is what actually separates compound engineering from ordinary engineering. Skip it, and what you're doing is just "traditional engineering with an AI assistant."