Compound engineering is our factory floor

"Claude Code opens 100 percent of my pull requests, and I haven't typed a function in weeks."

Kieran Klaassen wrote that in July 2025, while running Cora, one of the products Every builds with mostly single-person engineering teams. Three months later he open-sourced the process behind it as a Claude Code plugin called compound engineering. Trevin Chow joined as co-maintainer and has since written more of it than anyone. Dan Shipper, Every's CEO, told everyone in January that "now's the time to start".

Our whole team runs on it now, in Claude Code and in Claude Desktop. In the week of 5 October, roughly ten of us merged 469 pull requests.

This post is a thank-you with receipts: how to install it for people and for agents, the loop it gives you, the data from our team, and the one step we still skip.

The plugin is a process, packaged

Most AI coding tools sell you a smarter model. Compound engineering sells you nothing and gives you a workflow. It is 36 skills, typed as slash commands, that walk a change through the same stations every time: brainstorm, plan, work, simplify, review, compound. The README puts the bet in one line: "80% is in planning and review, 20% is in execution."

The idea behind it is older than the plugin. Every's guide states it plainly: each unit of engineering work "should make subsequent units easier". Normal codebases go the other way. Every feature adds a special case, every fix adds a workaround, and the tenth change is slower than the first. The loop is built to bend that curve. The plan step reads what earlier work learned. The review step catches what the plan missed. The compound step writes down what was hard, so the next plan starts there.

The plugin has kept moving. Every's guide described four steps in December 2025. Klaassen's May 2026 upgrade took it "from four steps to eight". The README today lists six. As of 15 October 2026 the repo has 25,536 stars. The commands were renamed from /workflows:plan to /ce:plan to /ce-plan along the way, so anything you read from early 2026 uses older names.

Install it once, for every agent you run

In Claude Code it is two commands:

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

In Claude Desktop, the Claude Code docs cover both surfaces. In the Code tab you click + next to the prompt box, then Plugins > Add plugin. A marketplace outside Anthropic's has to be added first, and the simplest way is the terminal command below. Desktop's local sessions read the same settings files as the terminal, so a plugin installed at user scope in one shows up in the other. Cowork has its own Customize > Plugins > Add marketplace, which takes the EveryInc/compound-engineering-plugin shorthand.

Agents can't click through a dialog, so they need the non-interactive form. I ran it against a clean config directory before writing this, and it installed 3.30.5 without a single prompt:

claude plugin marketplace add EveryInc/compound-engineering-plugin
claude plugin install compound-engineering@compound-engineering-plugin -y

For a whole team, put it in the repository instead of in anyone's laptop. A checked-in .claude/settings.json registers the marketplace and enables the plugin for everyone who trusts the folder. It is the same shape the CLI wrote when I installed it:

{
  "extraKnownMarketplaces": {
    "compound-engineering-plugin": {
      "source": { "source": "github", "repo": "EveryInc/compound-engineering-plugin" }
    }
  },
  "enabledPlugins": {
    "compound-engineering@compound-engineering-plugin": true
  }
}

The docs note one catch. Because the plugin lives in an external repository, each contributor still runs claude plugin install compound-engineering@compound-engineering-plugin --scope project once. It also runs outside Claude: the README has install steps for Codex, Cursor, Copilot, OpenCode, Droid and more, over a dozen hosts in all.

Klaassen's own rule for a new repository is to make the setup its first pull request:

The humans stand at both ends of the line

I wrote earlier this year that the dark factory is a title, not a practice. Every team that actually built one kept a human at the point where the stakes turn real. Compound engineering is the most practical version of that I have used. The lights are off in the middle of the line and on at both ends.

The ends are the plan and the review. A brainstorm or a plan is a document a person reads, argues with and approves. The work between is where agents run unattended: /ce-work executes the plan, /ce-simplify-code cleans the diff, /ce-commit-push-pr opens the pull request, and /ce-babysit-pr watches CI and answers review comments until it is ready. Then a person reads the review, decides, and merges.

/lfg is the switch that turns the middle fully dark. You hand it a request and it routes through plan, work, simplify, review, browser tests and a PR without stopping. Our pipelines are built on that pattern: the spec goes in, a pull request comes out, and a person judges the result. What makes it a factory and not a demo is that the stations are the same every time. Swap the model and the line still runs. Klaassen plans with Opus and implements with Codex, and the skills don't care.

Here's the data behind the cheering

GitHub keeps score whether you ask it to or not. I counted every merged pull request in our organization, week by week, for a year.

A year ago we merged about 70 pull requests a week. In the week of 5 October we merged 469. The team didn't grow: ten people authored human pull requests in the first week of the chart and ten in the last. Bots add 7 to 13 a week at both ends, so they aren't the story either. That is about six merged PRs per engineer per week then, and about forty-six now.

I won't claim the plugin did that alone. The models got better in the same year, and so did Claude Code. My first /ce- command is dated 29 March, and the climb past 200 a week only holds from mid-August, apart from one dip. The rest of the team picked up the loop gradually over the summer, and the steepest stretch of the chart comes right after.

The second chart is my own machine. It counts how often each skill ran, split into what I typed by hand and what the model invoked on its own.

Review is the busiest station by a wide margin: 89 typed /ce-code-review calls and 98 by the model. Review and simplify call each other in a loop; "review, then simplify" was the most common transition in two months of my sessions, 57 times. What I type sits at the two ends of the line. I start plans, brainstorms and reviews; the model starts commits, PRs and the babysitting.

The best habits are in how you call the skills

The skills accept a sentence after the command, and that sentence does most of the work. These are the patterns that recur in seven months of my own prompts.

Review the plan before the code. My most common hand-typed chain is /ce-plan, then /ce-doc-review on the plan, then /ce-work. A wrong plan reviewed costs a paragraph. A wrong plan built costs a pull request.

Steer the review, don't just run it. "/ce-code-review of critical stuff, merge-blocking stuff in the PR" gets a different review than a bare command. So does asking it to check its findings against the read-only production database.

Keep reviewers from sharing a brain. "/ce-code-review in sub agents so no previous reasoning is shared." A reviewer that read the author's reasoning tends to agree with it.

Hand findings to the next agent, not to yourself. "Post comments to the PR folder so another agent can take care of them." The review becomes the next agent's input.

Give /lfg a standing brief. Mine is one line long: work in a worktree, use the browser, use the CLIs and MCPs we have, reuse shared code, open the PR when done, attach screenshots.

Add a rule when the input is untrusted. For a pull request from an outside contributor: "be extra careful with it, post the review here before posting to the PR".

That cost is the most common complaint, and it is fair, but it is worth paying. A review that catches one bad migration pays for a lot of tokens, and the tokens are cheaper than the person who would otherwise read every line.

The step we skip is the one that compounds

There is a gap in my own data, and it sits exactly where the plugin's name points.

/ce-compound is the step that makes the next unit of work easier. It writes a short document to docs/solutions/ with the symptom, the root cause, what didn't work and the fix, and the next /ce-plan reads that folder before it plans. Every's guide is blunt about it: "Skip it, and you've done traditional engineering with AI assistance."

I typed it 6 times since March. The model ran it twice in two months. Over the same windows, review ran 89 and 98 times.

There are two readings. The generous one is that compounding happens anyway. /lfg captures durable learnings inside its own run without a separate command, and the skill has a strict bar: it only writes down what the final code and tests don't already explain. Across my repositories there are 24 of these documents, and this blog has its own. The less generous reading is that we run the four loud steps every day and the quiet one when we remember. Which raises the question I can't answer from the data. If ten people can merge 469 pull requests in a week while mostly skipping the step that compounds, what does the curve look like when we stop skipping it?