Compound Engineering: The Loop, the Plugin, the Evidence

Compound engineering is a development methodology from Every in which each unit of work is required to leave the system better able to do the next one: plan, work, review, then capture the learning where the next run will read it. The fourth step is the whole method; skip it and the loop is ordinary AI-assisted development.

The same bug arrives for the third time this quarter. Somebody fixed it in March, the fix was correct, and the reasoning behind it lives in a Slack thread nobody can find and an agent transcript that was garbage-collected. You are not slow because the fix is hard. You are slow because the system you work in has no memory, and neither does the agent you handed it to.

That is the problem compound engineering names, and the name has stuck hard enough that the plugin implementing it passed 24,500 stars and 2,000 forks inside ten months. It is also a method with a real argument against it, published in a peer-reviewed venue, that almost nobody writing about compound engineering mentions. Both halves are below.

What you’ll walk away with from the compound loop

• The four-step loop and the one step that separates it from “AI-assisted development”, plus the three different time splits Every publishes for it and how to read them
• A verified inventory of what the plugin actually ships today, and the specific places its own published guide describes an architecture the repository deleted
• The five-stage adoption ladder, with the transition that matters and the two that most teams try to skip
• The measurement that argues compound engineering should make your agent worse, why it does not refute the plugin, and the design property that decides which side you land on
• Four rules from the plugin’s internal vocabulary that decide whether the loop compounds or just accumulates, none of which appear in the marketing
• Four copy-paste prompts that run the loop with no plugin installed: capture, retrieval check, independence audit, and a quarterly ablation of your own learning store

What compound engineering actually claims

The premise is a claim about the second derivative, not the first. Most codebases get harder over time because each feature is a negotiation with the ones before it. Compound engineering asserts the inverse is achievable: features teach the system new capabilities, a bug fix eliminates a category rather than an instance, and the codebase gets easier to change as it grows.

Kieran Klaassen, general manager of Cora at Every, introduced it in August 2025 under the name “compounding engineering”, after finding that Claude Code had opened a pull request citing its own prior reviews — “changed variable naming to match pattern from PR #234, removed excessive test coverage per feedback on PR #219”. The point was not that the AI wrote code. It was that the AI had retained three months of review taste and applied it unprompted.

The loop, and the step that makes it compound

1. Plan. Understand the requirement, research the codebase for how similar things already work, research externally, design the approach, validate that the plan holds together.
2. Work. Set up isolation (a worktree or branch), execute the plan step by step, run tests and type checks after each change, adapt when something breaks.
3. Review. Multiple specialised reviewers examine the output in parallel, findings get prioritised P1/P2/P3, fixes are applied and validated.
4. Compound. Capture what worked and what did not as a retrievable artifact, tag it so it can be found, update the instructions the agent reads at session start, and verify the system would now catch this automatically.

Steps one to three are familiar. Step four is the entire thesis: the first three steps produce a feature, the fourth produces a system that builds features better next time. Every’s own framing is blunt about the failure mode — skip step four and you have done traditional engineering with an AI typing.

80/20, 50/50, or both?

Every publishes three different time splits for this loop, in two documents, and reading them as contradictions is a mistake worth avoiding.

Split	Scope	Where it appears
80% plan and review, 20% work and compound	Within one feature	The guide’s “main loop” section
80% planning and review, 20% execution	Within one feature	The plugin README’s philosophy section
50% features, 50% improving the system	Across your whole week	The guide’s “beliefs to adopt” section

The first two are the same claim stated loosely. The third is a different axis: it is not about how you spend a feature, it is about how much of your engineering capacity goes to work that produces no feature at all — review agents, documented patterns, test generators. Traditional teams put roughly 90% into features and treat the rest as overhead you get to when you have spare time, which is never.

Note

The 50/50 split is the load-bearing one, and it is also the one that does not survive contact with a roadmap unless somebody senior defends it. An hour building a review agent is claimed to save ten hours of review over a year. That ratio is an assertion, not a measurement — but the direction is the part you can verify cheaply on your own repo by counting how many times you have explained the same convention.

What the plugin is now, and what the guide still describes

The workflow ships as a plugin under MIT licence. Here the article earns its keep, because the published guide at every.to and the repository it links to have diverged, and the guide is what most people read first.

The guide’s “what’s in the box” section lists 26 specialized agents, 23 workflow commands, and 13 skills — then, eleven lines later, a directory tree in the same document labels the same folder “Domain expertise (14 skills)”. Its links to the agents and commands directories both return 404. So does every deep link into them: the design agents it names, the command files it points at for /plan and /compound. The marketplace URL it gives you, EveryInc/every-marketplace, now 301-redirects, because the repository was renamed.

What the repository holds as of 24 August 2026, version 3.23.3:

Guide says	Repository has
26 agents in agents/	No agents/ directory. 404.
23 commands in commands/	No commands/ directory. 404.
13 skills (or 14) in skills/	33 skills, each a directory with a SKILL.md
14 review agents spawned by /review	27 reviewer persona files, owned by ce-code-review and not exposed as plugin components
Claude Code, OpenCode, Codex	14 agent hosts, including Cursor, Kimi, Devin, Copilot, Qwen, Antigravity, Grok

This is not pedantry about a stale doc. The architecture genuinely changed, and the change is the interesting part. In the current design, specialist behaviour is not a standalone agent you install. A skill owns its reviewer personas as internal prompt files, and dispatches generic subagents seeded with them. The plugin’s own glossary states the reason directly: a skill is user-invoked and coordinates, an agent is dispatched and performs scoped work, and exposing every specialist as an installable agent made the surface area larger than the value.

The practical consequence for you: /review spawning “14 named agents” is no longer a thing you can inspect or override by editing an agent file. The personas live inside skills/ce-code-review/references/personas/, and the skill decides which ones to route to.

Installing it in Cursor, Claude Code, and Codex

All three read the same repository; only the marketplace mechanics differ.

Cursor

In Cursor Agent chat:

/add-plugin compound-engineering

Or search for “compound engineering” in the plugin marketplace. Grok Bot uses your Cursor account and plugin library, so installing here covers it — do not install separately inside Grok Bot.

Claude Code

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

If you already had it installed, refresh the marketplace before updating. Running /plugin update on its own keeps you on the old version — a documented trap in the repo’s upgrade notes.

Codex

codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin

Codex invokes skills with $, not / — so $ce-plan and $lfg. For a non-default profile, run both commands against the same CODEX_HOME, because the marketplace step only makes the plugin available and the install step is what activates the skills for that profile.

Then run /ce-setup once in the project. It reports which optional tool capabilities are present, writes .compound-engineering/config.yaml if missing, and gitignores a local override. The default artifact folders are docs/plans/, docs/solutions/, and docs/brainstorms/; if your docs/ is already tracked content — as it is on this site — the docs_root setting relocates all of them under one repo-relative root.

Where are you on the five-stage ladder?

The guide’s most useful section is the one that is not about the plugin at all. Compound engineering only starts working at stage three, and teams that read about multi-agent review while sitting at stage two either give up or skip ahead and lose trust in the tools.

Stage	What you do	What the agent does
0	Write every line. Docs and Stack Overflow for research.	Nothing
1	Ask a chat model, copy-paste what is useful	Generates snippets you paste
2	Agentic tools with file access; you approve every action	Reads and edits, gated on you
3	Collaborate on a detailed plan, then step away	Implements unsupervised, output is a PR
4	Describe the outcome; review the PR; merge	Researches, plans, implements, self-reviews, opens the PR
5	Direct parallel work from anywhere	Multiple agents run in the cloud on independent features

Stage 2 is where most developers plateau, and the reason is not capability — it is that line-by-line approval feels like diligence. The transition to stage 3 is the one that matters, and it is a trust transition, not a tooling one: you stop reviewing keystrokes and start reviewing a plan document and a pull request.

Caution

The ladder is worth taking literally about not skipping. Each rung builds the mental model the next one needs. A team that jumps from stage 2 straight to /lfg gets a 40-file pull request from a plan nobody read, cannot tell which part to distrust, and concludes that autonomous agents do not work. What actually happened is that they removed the plan review — the one step at stage 3 that makes stage 4 legible.

For the record on what full autonomy does and does not include: /lfg chains plan, implement, simplify, review, apply eligible fixes, browser tests, commit, push, open a PR, and watch CI inside a bounded repair loop. It explicitly does not merge, and it can finish with leftovers when the repair budget runs out. With no git remote it stops at local commits. The guide’s phrasing — “handing you a PR ready to merge” — is optimistic about the leftovers.

What a captured learning actually looks like

The fourth step is the one people nod at and skip, so it is worth seeing what the artifact is. ce-compound writes one document per solved problem into docs/solutions/, and classifies it onto one of two tracks that produce different section structures:

• Bug track — Symptoms, What Didn’t Work, Solution, Why This Works, Prevention. For build errors, test failures, runtime errors, performance and integration issues.
• Knowledge track — Context, Guidance, Why This Matters, When to Apply, Examples. For architecture and design patterns, tooling decisions, conventions, workflow practices.

Three mechanics in there are worth stealing even if you never install the plugin.

“What Didn’t Work” is a first-class section. The failed approaches are the most expensive part of an investigation and the first thing to evaporate. A learning that records only the answer sends the next person down the same three dead ends.

Overlap is scored before a new doc is written. A subagent compares the candidate against existing learnings across five dimensions — problem statement, root cause, solution approach, referenced files, prevention rules. Four or five matches means update the existing doc rather than create a second one. Two or three means write it and flag for consolidation. Without this, a knowledge store becomes two documents about the same bug that quietly disagree.

Discoverability is checked as part of capture. Every run asks whether the project’s AGENTS.md or CLAUDE.md would actually lead a future agent to find docs/solutions/. A knowledge store nothing points at is a knowledge store that does not exist. This is the single most common way a compound-engineering attempt fails silently: the docs are written, nothing reads them, and six months later somebody deletes the folder because it looks abandoned.

Tip

Copy-paste prompt for capturing a learning without the plugin:

We just solved a non-trivial problem in this session. Write it up as a
retrievable learning document, not a summary for me.

Classify it first: is this a defect (a thing that was broken) or guidance (a
convention, pattern, or decision)? Say which, and use the matching structure:

  Defect: Symptoms / What Didn't Work / Solution / Why This Works / Prevention
  Guidance: Context / Guidance / Why This Matters / When To Apply / Examples

Rules for the write-up:
- "What Didn't Work" is mandatory for a defect and must name the approaches we
  actually tried and why each failed. Do not compress this section.
- Every claim about code behaviour must quote the source line that proves it,
  with a file path. If you cannot find the line, mark the claim UNVERIFIED
  rather than asserting it.
- Add YAML frontmatter with: title, problem_type, component, root_cause, and
  3-6 tags a future search would plausibly use. Prefer vocabulary that already
  appears in existing docs in this repo over inventing new terms.

Before writing, search the repository for an existing document covering the
same problem. Compare on five dimensions: problem statement, root cause,
solution approach, files touched, prevention rule. If four or more match,
update that document instead of creating a new one and tell me which.

Finally: check whether this repo's agent instruction file would lead a future
session to find this document at all. If not, quote the smallest addition that
would fix it and ask before editing anything.

Does accumulating learnings make agents worse?

Here is the argument compound engineering has to answer, and almost no write-up about it does.

The most direct study of repository context files — Gloaguen et al. at ETH Zurich — found in its v2 abstract that context files “do not generally improve task success rates, while increasing inference cost by over 20% on average”. The v1 paper carried a split that v2 aggregates away: LLM-generated files scored about 3% worse than having no file at all; developer-written ones about 4% better.

That is a direct shot at the compound step as the guide describes it. The guide’s instruction is to “add new patterns into CLAUDE.md, the file the agent reads at the start of every session”. Do that after every feature for a year and you have machine-generated accretion in the one file that is always loaded — the exact configuration the study measures as net-negative and definitely more expensive.

It gets worse before it gets better. Tool vendors inverted their own advice on this in July 2026: Anthropic removed over 80% of Claude Code’s system prompt for the Claude 5 generation with no measurable loss on coding evaluations, and the user-facing guidance flipped from “add a line every time it makes a mistake” to “delete your context files periodically and see what the model can do without them”. Our ablation protocol for pruning CLAUDE.md and AGENTS.md walks through that inversion in detail.

Why the plugin’s design survives the objection

The objection lands on the guide’s prose. It does not land on the shipped plugin, and the difference is one property: retrieval versus always-loaded.

• docs/solutions/ is a retrieved store. Learnings sit on disk. ce-plan and ce-ideate pull the relevant ones as grounding for the work at hand. A store of 400 learnings costs nothing on a task that matches three of them.
• CLAUDE.md is an always-loaded file. Every line is paid for on every task, whether relevant or not. This is the thing the study measures, and the thing the July inversion targets.

The plugin puts almost everything in the first category and touches the second only to add a pointer at the store. It also ships the counterpart nobody builds by hand: ce-compound-refresh maintains the store over time with five verdicts — Keep, Update, Consolidate, Replace, Delete. That is an ablation protocol for your knowledge base, and it is the reason the store does not become the same problem in a different folder.

So the practical rule, whether or not you use the plugin:

Caution

Anything that must be true on every task goes in the always-loaded file, and that file stays short enough to defend line by line. Anything that is true on some tasks goes in a retrieved store with tags and an index the agent is told to search. Compound engineering that writes learnings into the always-loaded file is the version the evidence penalises.

Tip

Copy-paste prompt for auditing whether your knowledge store is actually read:

Audit whether this repository's accumulated knowledge is reachable by an agent
that has never seen it. Do not fix anything yet.

1. Find every location in this repo that stores durable engineering knowledge:
   solution docs, ADRs, runbooks, plan artifacts, wiki exports, long comments
   in the agent instruction file. List them with file counts and the date
   range of last modification.

2. For each location, answer: is it referenced from the file this project's
   agent loads at session start? Quote the referencing line, or write NOT
   REFERENCED.

3. Take the five most recently fixed bugs from `git log`. For each, search the
   knowledge locations for a document that would have prevented or shortened
   it. Report hit or miss, and for each hit say whether the document was
   findable by the words someone would actually search for, or only by knowing
   it existed.

4. Report the ratio of documents that are reachable AND findable to total
   documents. That number, not the document count, is the size of the
   knowledge base.

Finish with the single highest-leverage change: one line added to one file, or
one index created. Not a plan, one change.

The rules the guide never mentions

The plugin’s CONCEPTS.md is a glossary the team maintains for its own agents, and it contains the operational rules that decide whether any of this works. None of them appear in the marketing, and three generalise well past this plugin.

Two reviewers in one context are not two witnesses

The rule, stated in the plugin’s own words: independence is a property of the execution context a reviewer ran in, not of the lens it applied. Two personas reasoned inside one context are two perspectives, not two witnesses.

This is the most transferable idea in the whole repository. If you prompt one agent with “review this as a security reviewer, then as a performance reviewer, then as an architect”, the three findings share a context, share the same initial read of the diff, and share whatever the model got wrong on the first pass. Agreement between them is not corroboration. It is the same witness repeating itself in three costumes.

The plugin enforces the consequence: only separately dispatched contexts license promoting a finding’s confidence or describing it as independently confirmed, and when dispatch fails and the work runs inline, the run reports the lost coverage rather than promoting on it.

A model’s identity is a receipt, not a request

When a review is delegated to a different model provider for a second opinion, the plugin records the serving backend’s own report of which model handled the run, alongside the model that was requested — so the two can disagree visibly. Outputs without that receipt are labelled requested-but-unverified, and logic that weights cross-model agreement follows the receipt, not the request.

If you have ever built a multi-model review pipeline on the assumption that specifying a model means you got that model, this is the failure mode you did not instrument.

The skill body your host silently truncates

Every agent host caps how much of a skill’s body it keeps in the model-visible prompt, each reaches that cap by a different route, and — the part that matters — every known truncation keeps the beginning of the body and discards the rest, and none of them reports an error.

The consequence is that ordering is load-bearing. A stop rule or a safety boundary placed below a long routing block can vanish while every mechanical check still passes. The plugin’s answer is the “phase-loaded kernel”: the always-visible body carries only the outcome, the done condition, the authority, the phase order, and the stop classes, with each phase’s mechanics in a reference file loaded at the moment of acting.

If you write skills or long instruction files of your own, this is the single most useful thing in the repository: put what must survive above what may be cut.

Findings carry a confidence anchor, not a score

Review findings are gated by a discrete self-scored confidence value on a small fixed scale, where each level is tied to a behavioural criterion the model can honestly apply — deliberately not a continuous score, which invites false precision. Corroboration promotes a finding by one level, but only across contexts that met the independence bar above.

Tip

Copy-paste prompt for an independence audit on any AI review you already run:

Audit the review process described below for independence, not for accuracy.

[paste your review prompt, command, or pipeline description]

Answer these, and refuse to guess:

1. How many separate model invocations does this actually make? Count contexts,
   not personas, roles, or bullet points in the prompt.
2. For each finding the process can produce, what would count as corroboration?
   If two findings can only arise from the same invocation, say so explicitly.
3. Where does the process treat agreement as evidence? Quote the line. Then say
   whether that agreement is between independent contexts or the same context
   talking to itself.
4. Which findings does the process rank or escalate, and is the ranking derived
   from anything other than the model's own confidence in its own output?
5. If a delegated model call silently fell back to a different model, what in
   this process would notice?

Output a table of claims the process makes versus what it can actually support,
and one concrete change that would buy real independence at the lowest cost.

What breaks when you run the compound loop

The learning store becomes a second codebase nobody maintains. Capture is cheap and satisfying; maintenance is neither. Without a periodic refresh pass, you get contradictory documents about the same subsystem, and an agent that finds the stale one first. Run a Keep/Update/Consolidate/Replace/Delete pass on a schedule, or do not start the store.

Guidance beats learnings at the moment of action. The plugin’s glossary makes this explicit: an agent loads its skill instructions, runbook, or root instruction file at the moment it acts, so a learning that contradicts that guidance is not merely stale — it will be overridden in practice. When a learning and an instruction file disagree, the instruction file wins regardless of which is right. Resolve the contradiction where the agent reads, not where you wrote.

Plan review disappears first under deadline. The 80/20 split inverts quietly. When it does, you are at stage 2 with stage 4 tooling: agents shipping large diffs from plans nobody read, which is the exact configuration that produces the review backlog described in software factories.

--dangerously-skip-permissions is advised by the guide, and the advice is conditional. Every’s own conditions are a branch that is separate from main, tests that can catch a mistake, a revert path, and no real users touching the code until you are ready. Those conditions are the whole safety argument. Copy the flag without them and you have copied the risk without the mitigation.

Compounding is asserted, not measured. “An hour building a review agent saves ten hours of review” is a plausible direction with no published number behind it. The honest version is that you can measure it on your own repo: count how many times per quarter somebody re-explains the same convention, and check whether that count falls after the store exists. If it does not, the loop is running but not compounding.

Running the loop without installing anything

The loop is a process, not a product, and every step of it works with a plain agent, a docs/solutions/ folder, and discipline. The plugin buys you enforcement, cross-referencing, and reviewer dispatch — not the idea.

Start here, in this order: keep a short always-loaded instruction file, create a retrieved learning store, write one learning by hand after your next real bug, then check a month later whether anything read it. If nothing did, fix discoverability before writing learning number two. That sequencing is the difference between a knowledge base and a folder.

Tip

Copy-paste prompt for a quarterly ablation of your learning store:

Review this repository's accumulated learning documents. For each one, return
exactly one verdict: KEEP, UPDATE, CONSOLIDATE, REPLACE, or DELETE.

Judge each document against the code as it exists now, not against the state
it described when it was written:

- DELETE if the code it describes no longer exists, the tool it depends on was
  removed, or the problem is now impossible by construction.
- REPLACE if the conclusion is now wrong. Say what is wrong and what the
  current answer is.
- CONSOLIDATE if another document covers the same root cause. Name the pair and
  which one should survive.
- UPDATE if the substance holds but a path, command, version, or API changed.
- KEEP only if you verified at least one specific claim against current code.
  Quote the line you checked.

Then run one extra check that matters more than staleness: for each document,
does it contradict anything in the instruction files this project's agents load
at the start of a session? A contradiction there outranks being out of date,
because the instruction file wins at the moment of acting. Report the file and
the conflicting lines. Do not edit the instruction file.

Output a table sorted by verdict, with DELETE and REPLACE first. Do not apply
anything yet.

Where to go next with compound engineering

Pruning CLAUDE.md and AGENTS.md The ablation protocol, the July 2026 inversion, and the routing table for deciding which of five destinations a line belongs in

Software factories What happens downstream when the loop runs at fleet scale: review backlogs, autonomy ledgers, and metering trust loop by loop

Memory patterns The retrieval side of the story: how agents store and recall across sessions, and what each tool persists on its own

Documentation as context Making the docs an agent reads structurally different from the docs a human reads, and what the ETH study says about both

Superpowers The other disciplined design-to-PR plugin, with worktrees, executable plans and enforced TDD — useful as a direct comparison

PRD, plan, todo The planning artifact chain underneath the loop's first step, independent of any plugin