The Fourth Step Every Team Skips Is the Real Key to AI Engineering
- 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.
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 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.
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."
The Counterintuitive Part: Writing Code Is Only 20% of the Time
Plan and Review together take up 80% of an engineer's time; actually writing code (Work) plus compounding (Compound) is only 20%. Most of the thinking happens before and after the code gets written.
What each of the four steps actually does / a few old assumptions Every says to drop
How Step Four Actually Works: Turning Solutions Into System Memory
The first three steps (Plan, Work, Review) produce "a feature." The fourth step, Compound, produces "a system that gets better at building features every time." In practice it's four concrete moves.
The YAML frontmatter in step two is a block of metadata tags at the top of the document (title, category, keywords) that lets this solution be searched and retrieved precisely later, instead of getting buried in a pile of docs where nobody can find it again.
Traditional development stops at step three, Review; compound engineering takes one more step: writing the problem you just solved back into the system. This step doesn't produce code — it produces the ability for the system to automatically avoid the same kind of problem next time. That's exactly where the efficiency gap comes from.
CLAUDE.md is the "AI operating manual" sitting at the root of the project — the agent reads it first every time it starts up. Think of it as the SOP manual every new hire has to read: whenever someone solves a problem no one's hit before, a rule gets added; the next person who shows up already knows it, without having to fall into the same hole again.
The toggle below makes the difference — once that rule has accumulated — easy to see directly:
The agent doesn't know about this pitfall; you and it debug, diagnose, and fix it together. Once it's fixed, the Compound step writes "why it happened, how to avoid it" into CLAUDE.md, and saves a tagged document into docs/solutions/. This round took a bit of extra time to record.
The agent reads that rule the moment it starts up, and the old solution is searchable in docs/solutions/ too. So during the Plan step, it proactively steers around the same kind of problem — it never even gets to the point of causing a bug. The time spent recording it earlier gets paid back here, with interest.
Every time a Compound step completes, CLAUDE.md gains one more piece of knowledge — the system gets smarter the more it's used:
How docs/solutions/ Grows Into an Institutional Knowledge Base
14 AIs Reviewing Your Code at Once
When a PR (a code change submission) comes in, the /workflows:review command dispatches 14 specialized agents all at once, running concurrently, each watching exactly one dimension: security, performance, architecture, data, code quality, framework conventions, and so on. Each does its own check, and the results get merged into one priority-ranked list of P1 (must fix) / P2 (should fix) / P3 (nice to fix).
The N+1 query that agent 02 specifically watches for is a common database performance trap: query a list of 100 records, and if it's written wrong, each one triggers a separate follow-up query — 101 requests total. It's like going to the supermarket for 10 items but making 11 trips: one trip to see what's there, then one separate trip for each item.
The 14 concurrent results get merged and deduplicated into one priority-ranked list, roughly like this:
What happens after the list comes out
What's in the Plugin, and How to Use It
The entire workflow is packaged as a plugin — install it and it works, zero configuration. Supports Claude Code, with experimental support for OpenCode and Codex too.
What Each File Is For
Two Lines to Install (Claude Code)
OpenCode / Codex install commands, plus one command to run the entire pipeline
bunx @every-env/compound-plugin install compound-engineering --to codex
The Key Numbers: Just How Big Is the Concurrent Agent Scale
Putting the scale of this system into a few concrete numbers.
Every piece of engineering work should make the work that follows easier, not harder.Every, "Compound Engineering"
The Only Difference Between a Codebase That Gets Harder to Touch and One That Gets Easier: The Step Everyone Skips
Every uses "Compound Engineering" to run 5 products with essentially solo teams. The trick: one extra step after every feature — save the solution into the system so the AI avoids the same pitfall next time. One page, with a diagram.
↓ One page, with one diagram that moves
Every is an AI product company. Its five products — Cora, Monologue, Sparkle, Spiral, plus the main site — each run on an engineering team of basically one person. What holds up that scale is a method called "Compound Engineering" (making every piece of work save effort for the next one).
It's aimed at the old sickness of traditional coding: every feature you add stuffs one more dose of complexity into the system, and ten years in, the team spends more time wrestling with legacy code than building new things. Worse, a hard-won solution gets thrown away the moment it's used — the same pitfall gets stepped in again from scratch next time.
✘ But solved problems don't accumulate — the same pitfall gets stepped in again from scratch next time
The traditional flow calls it done at "Review." Whatever the AI learned this round gets thrown away once used — complexity only goes in, never out, and the code piles up harder to touch.
Compound Engineering is, at bottom, a four-step loop: plan, work, review, compound. Every programmer already knows the first three; the key is that where traditional engineering stops at "review," this method takes one more step — writing this round's solution back into the system.
The difference is just the last step: traditional stops at "review" and throws away this round's solution once it's used; Compound Engineering takes one more step, "compound," writing the solution back into the system so the AI carries it the moment it starts up next time. So how exactly does this step "write back into the system," and how does it let the AI avoid the problem automatically? One diagram makes it clear.
The fourth step, "compound," in practice means: every time a problem gets solved, write the solution into CLAUDE.md (the operating manual the AI reads first every time it starts up). Below, using an example of XiaoHu (this site's owner) repeatedly hitting the same bug, see where traditional and compound diverge.
Most people have no feel for "how many times faster." Converted into time, it's clear. The most straightforward saving from Compound Engineering is handing repetitive labor like "review" over to the system once and for all.
The other saving is "parallelism": reviewing code once means 14 specialized AIs (each an assistant handling one thing) work at the same time; switching on ultrathink (a deeper thinking mode) while planning can dispatch 40+ research AIs at once. The scale, in a few numbers:
All the numbers above come from Every's own account — they're the company's own figures, with no independent third-party verification.
fix this already?
- × Fix it and walk away —
solution tossed once used - × Same pitfall,
stepped in again next time - × Complexity only piles up,
never gets removed
system remember it?
from scratch AGAIN?!
already logged it.
80% of the time,
writing code is only 20%.
Members can copy or download the full Markdown, and let their AI subscribe and ask.
Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.