What Compound Engineering Actually Compounds

Compound engineering is a way of working with coding agents where each unit of work makes the next one cheaper, because finished work gets written back to disk as an artifact the next run reads before it starts. The clearest implementation of it is Every's open source plugin, which crossed 23,900 stars on GitHub and installs the same set of skills into Claude Code, Cursor, and Codex.

The star count is not the interesting number. This one is: the project states that 80% of the effort belongs in planning and review, and 20% in execution. That inverts how most people actually use a coding agent, which is to describe a task, skim the diff, accept it, and move on.

Key Takeaways:

• Compound engineering is a process claim, not a product category. The claim is that engineering work should make later work easier instead of harder.
• The loop is brainstorm, plan, work, simplify, review, compound. Only the last step does the compounding.
• /ce-compound writes what was learned into docs/solutions/, and the next brainstorm reads that folder as grounding. That return path on disk is the entire mechanism.
• The plugin is MIT licensed, shipped v3.21.2 on August 5, 2026, and installs on Claude Code, Cursor, Codex, and roughly a dozen other hosts.
• The honest limit is portability. Everything compounds inside one repository. Nothing crosses machines, teammates, or projects on its own.

What compound engineering actually means

The one-line definition in the repository is "AI skills that make each unit of engineering work easier than the last." That sounds like a slogan until you look at what it is arguing against.

Normal development accrues debt in a specific way. A bug gets fixed, and the reason it happened lives in someone's head or in a pull request comment nobody reads again. A tricky migration gets done, and the six gotchas discovered along the way are gone the moment the branch merges. The codebase grows, the context needed to change it safely grows faster, and the next change costs more than the last one.

Agents made that worse before they made it better. A coding agent starts every session with no idea that you already litigated this decision in March. It will happily repeat the mistake, and it will do it faster than a human would.

Compound engineering is the claim that this is fixable by changing where knowledge lives. Not in a chat history, not in a model, but in files in the repository that the next agent run is required to read. Every, the company behind the plugin, has been writing about this publicly for over a year, including an account of arriving to find the AI had already fixed the code.

What this proved: the bottleneck moved from what the model can do to what the model is told before it starts. What it left unsolved: somebody still has to decide what is worth writing down, and that judgment is not automated by any of this.

The six-step loop, and the one step that compounds

The core workflow is six skills. Five of them are recognizable. The sixth is the point.

Run the first five and you have a tidy workflow. Run the sixth and you have a feedback loop, because /ce-brainstorm and /ce-plan read docs/solutions/ as grounding on the next pass. The learnings from cycle one are inputs to cycle two.

This is a smaller and more boring mechanism than the phrase "compound engineering" suggests, and that is a point in its favor. It is markdown files in a folder, with a convention about who writes them and who reads them. There is no vector store, no fine-tune, no proprietary format. If the plugin disappeared tomorrow, docs/solutions/ would still be readable.

The repository also lets you relocate all of it. Projects whose docs/ folder is tracked content can move every artifact directory under one repo-relative root through a docs_root setting, which is the kind of detail that only shows up after real users hit a real conflict.

What this proved: a return arrow drawn on a whiteboard becomes real when it is a file path. What it left unsolved: nothing stops docs/solutions/ from turning into a junk drawer, and the plugin does not prune it for you.

What the plugin installs across Claude Code, Cursor, and Codex

Host coverage is broader than the tagline suggests. The documented install paths cover Claude Code, Cursor, the Codex app, and the Codex CLI, with the README also listing Kimi Code CLI, Cline, Grok Build CLI, Devin CLI, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, and Antigravity CLI. The skills are portable because they assume very little about the agent harness underneath: the host keeps verification, commits, and shipping, and the skill supplies the procedure.

Two practical notes for anyone installing this week.

In Claude Code and Cursor, skills are invoked with a slash, as in /ce-plan. In Codex, installed skills are invoked with a dollar sign instead, as in $ce-plan, because / is reserved for built-in commands. Getting this wrong is the most common first-run failure.

If you installed an earlier version, the project moved to a root-native layout, and running /plugin update alone leaves you on the old one. You have to refresh the marketplace first. There is also a legacy block that older Codex installs wrote into your global AGENTS.md, between <!-- BEGIN COMPOUND CODEX TOOL MAP --> sentinels, which the README now tells you to delete because one of its lines incorrectly instructed Codex to collapse subagent dispatch onto the main thread.

Beyond the core six, the plugin ships a wider catalog: /ce-ideate for when you do not yet know what to build, /ce-strategy to maintain a STRATEGY.md that upstream skills read, /ce-debug for when the input is a bug rather than a feature, /ce-product-pulse for a time-windowed report on what users actually experienced, and /ce-explain and /ce-pov for accounting for work and forcing a decision.

What this proved: the design is host-agnostic on purpose, which is why it spread. What it left unsolved: the surface area is now large enough that most users will only ever touch three of these skills.

Compound engineering versus context engineering

These two phrases get used as if they were competing, and they are not even about the same layer.

Context engineering is about assembling the right inputs at inference time. Compound engineering is about what gets written at the end of the task. You can do both, and in practice a team doing compound engineering well is generating exactly the corpus that context engineering wants to serve.

The reason the distinction matters commercially is that they have different adoption costs. Standing up a semantic layer is a quarter of platform work. Adopting a six-skill loop is an afternoon, and the failure mode is social rather than technical.

Where the compounding actually breaks down

Three limits are worth stating plainly, because the enthusiastic coverage skips them.

It compounds per repository, not per person. The artifacts live in docs/. Move to a different repo and you start from zero. Work across five services and you have five separate accumulations that do not talk to each other. For a solo developer on one product this is fine. For a platform team it is a real gap.

The 80/20 split is a recommendation, not a measurement. The repository asserts that most of the value sits in planning and review. No public benchmark backs that ratio, and none of the coverage has tested it. Will Larson, writing about the project at lethain.com, engaged with it as a set of practices worth learning from rather than as a validated result, which is the right posture.

Review is report-only by default. /ce-code-review produces findings and does not apply them unless you explicitly ask. That is the correct default and it also means the compounding depends on a human reading the report. Skip that and the loop quietly degrades into an expensive linter.

There is a fourth thing that is not a flaw but is worth knowing: the project moves fast. It shipped v3.20.0 on July 22, v3.21.0 on July 31, v3.21.1 on August 4, and v3.21.2 on August 5, 2026. With 1,959 forks and 90 open issues, anything you read about its exact command surface has a short shelf life. Check the repository before you copy a command from a blog post, including this one.

What this proved: the honest version of the pitch is narrower and more useful than the viral version. What it left unsolved: cross-repository and cross-teammate compounding is still an open problem that nobody has shipped.

Who compound engineering is for

If you work primarily in one repository, run a coding agent daily, and keep rediscovering things you already solved, this is aimed directly at you and costs an afternoon to try. Start with /ce-plan and /ce-compound alone. The other skills can wait.

If you are evaluating this for a team, the question is not whether the loop works. It is whether your engineers will read docs/solutions/ in three months. That is a culture question and the plugin cannot answer it.

And if what you actually want is not a local workflow but an agent that already holds its tools, its scope, and what it learned between runs without you maintaining a plugin install across four hosts, that is a different shape of product. MoClaw runs hosted agents for developers, where the setup and the persistence are managed rather than assembled. Compound engineering is the discipline; a managed agent is one way to stop paying the setup cost every time you change machines.

Compound engineering is a filing convention, and that is why it works

The most useful reframe here is deflationary. Compound engineering is not a new capability unlocked by a smarter model. It is an agreement about which files get written at the end of a task and which files get read at the start of the next one. The plugin is 23,930 stars' worth of evidence that a good convention, shipped as installable skills across every major coding agent, spreads faster than a clever technique.

The open question is whether the accumulation survives contact with a second engineer. Everything in the design so far optimizes for one person and one repository getting steadily faster. That is a real win, and it is a smaller claim than the name implies.

Repository facts verified against the GitHub API on August 5, 2026: 23,930 stars, 1,959 forks, MIT license, created October 9, 2025, latest release compound-engineering-v3.21.2.

FAQ

What is compound engineering in AI?

It is a way of working with AI coding agents where each task writes durable artifacts, such as plans, review reports, and solution notes, that later tasks read before starting. The goal is that the second time you touch an area, the agent already has the context you paid for the first time.

What is a compound engineer?

It is not a job title. It describes an engineer who spends most of their effort on planning and reviewing agent work rather than on writing the implementation, and who treats the notes left behind as part of the deliverable.

Is the compound engineering plugin free?

Yes. The repository is MIT licensed and installable from its own plugin marketplace. You still pay whatever your coding agent and model provider cost.

Does it work with Cursor and Codex too?

Yes. Claude Code, Cursor, the Codex app, and the Codex CLI all have documented install paths, and the README lists roughly ten more hosts including Cline, GitHub Copilot, Qwen Code, and OpenCode. In Codex, invoke skills with $ rather than /.

Do I need all of the skills to get value?

No. The compounding comes from /ce-compound writing to docs/solutions/ and the planning skills reading it back. Two skills is enough to test whether the loop helps you.