Compound engineering

What is compound engineering?

Compound engineering is the habit of finishing every task with an agent by leaving something behind that makes the next task cheaper. The change ships, and so does an artefact: a line in the project's instruction file, a check that now runs on its own, a saved command, a note explaining a decision.

The default is the opposite. You fix a bug with a coding agent, the fix goes in, the session ends, and the reasoning that produced it is gone. Next month someone hits the same wall and starts from zero, because the model opened with an empty context window and nothing on disk told it what you learned.

Kieran Klaassen of Every described the practice in August 2025 under the name compounding engineering: "building self-improving development systems where each iteration makes the next one faster, safer, and better." By December 2025 he and Dan Shipper had settled on the shorter name and a plainer sentence: "in compound engineering, you expect each feature to make the next feature easier to build." Every has since released the workflow as an MIT-licensed plugin that runs in fourteen agent hosts, Claude Code, Codex and Cursor among them.

The loop has four beats: plan, work, review, compound. Only the last one is new. It is the step where you ask what this task taught you and where that lesson has to live so a machine finds it next time.

What a task can leave behind

"Write down what you learned" is too vague to act on. In practice the artefacts fall into five kinds, and they are not equally strong.

• A line in the instruction file. The AGENTS.md or CLAUDE.md at the root of the repository, read at the start of every session. Anthropic's guidance for Claude Code gives a clear trigger: the agent made the same mistake a second time, or you typed the same correction you typed last session.

• A check that runs by itself. A test, a linting rule, a script that exits with an error when two totals do not reconcile. The strongest kind, because nothing has to remember it. Anthropic is direct about why: instruction files "shape Claude's behavior but are not a hard enforcement layer", while a hook or a permission rule is "enforced by the client regardless of what Claude decides to do".

• A saved skill or command. When a job comes back in the same shape, the procedure moves out of the chat into a file the agent loads when it is relevant. Anthropic's trigger: you keep pasting the same checklist, or a section of the instruction file has grown into a procedure rather than a fact.

• A written decision. One paragraph on why credit notes are excluded, or why you skipped the vendor's own connector. Every's plugin writes these into a docs/solutions/ folder so the next planning step can read them, and nobody reopens the question in six months.

• A fix to the environment. The agent failed three times because a driver was missing from the container. Put it in the setup script and the next agent, and the next colleague, never meets that failure.

The first and the fourth cost tokens in every session. The second and the fifth cost nothing at runtime and hold even when the model reads past the prose. Given the choice, turn a rule into a check.

One recurring task, three cycles

A distributor closes the books on the fifth working day and wants a sales report for the management meeting, built from an ERP export. Same job every month.

Month one. You explain everything: where the export lands, that credit notes carry a negative sign and must not count as sales, that the month closes on the fifth. The report comes out right, and that is where most people stop. The compound step takes ten minutes: three lines in the instruction file about the export layout and the credit-note rule, plus one test that fails unless the total matches the total the ERP reports.
Cycle two does not rediscover the credit-note rule, and does not trust a total because it looks about right.

Month two. Purchasing added a product group, the script quietly dropped those lines, and the report came out four thousand euro low. The fix is one row in a mapping table. The durable part is a check that stops the script when it meets a category it does not know, plus two sentences saying the real bug was the silent dropping.
Cycle three does not depend on someone spotting a wrong number by eye.

Month three. The work has the same shape as last month, so it becomes a saved command: run the export, run the reconciliation, write the report, and if the reconciliation fails, stop and mail the controller.
Cycle four does not need you in the room, because the colleague covering in July can run it.

Three artefacts, roughly forty minutes of extra work over three months. What that bought is a fourth close that is one request with a check on the end, instead of a conversation.

Compound engineering versus using an agent task by task

Both approaches use the same tools and produce the same change. They differ in what exists once the task is finished.

Task by task, what exists is the change: a commit, a working script, and a chat log nobody opens again. Why the code looks like that lives in the head of whoever was there. The second time the job comes round, it costs close to what the first one cost.

With compound engineering, what exists is the change plus something the next session can read. The second run costs less, and the gap widens as long as those artefacts stay true. The trade is honest: the compound step is real work tacked onto a task you thought was done, and on a one-off job it is wasted.

Keeping the pile small enough to be read

Left alone, this turns into a second problem. Thoughtworks put agent instruction bloat in the caution ring of its April 2026 Technology Radar. Context files accumulate as teams add codebase overviews, conventions and rules, and every addition looks useful on its own. The result, in their words: "Instructions become long and sometimes conflict with each other."

Two failure modes matter most. Contradiction: two rules disagree, the model picks one, and the behaviour becomes a coin flip. Decay: the rule described the codebase as it was in March. Anthropic attaches numbers to the same discipline. Keep an instruction file under 200 lines, because longer files consume more context and reduce adherence, and review them periodically to remove outdated or conflicting instructions.

Instruction files rot the way documentation rots, for the same reason: they are prose that nothing tests. As Thoughtworks puts it about skills used as onboarding documentation, "unlike static documentation, executable documentation can help you notice staleness much earlier." A stale rule is silent. A stale script fails. When you add a line, look for one to delete.

What does not compound on its own

The name suggests interest accruing while you sleep. It does not.

The model does not remember your project. Anthropic states it in one line: each session begins with a fresh context window. Some tools now write notes for themselves between sessions, but that memory sits on one machine. Anything that has to survive a colleague or a change of supplier belongs in a file in the repository.

Somebody has to decide what was worth keeping. A session that writes down every observation produces the bloat above. One that writes down nothing produces the reset.

The reported gains come from one team. Every describes features shipping faster and pull requests reviewed in hours instead of days after three months of working this way. Those are the numbers of a small company reporting on its own product, with no controlled comparison behind them. Read them as an account of how the practice felt, not as a figure for a business case.

The same pattern outside software

Nothing in the idea is specific to code. It fits any task that comes back and where the context has to be explained again each time.

Take supplier invoices that arrive by mail and have to be booked. The first time you set this up with an agent you explain which mailbox, which suppliers send PDFs and which send structured files, and that anything above 5,000 euro goes past the manager first. Task by task, you explain all of it again next quarter. Compounded, it becomes an instruction file the agent reads, a check that refuses to book when the supplier and the order number disagree, and a saved procedure a stand-in can run.

Whether the compound step is worth it does not depend on how big the task is. It depends on how often it returns and how much of the explaining is identical each time.

You can watch whether it works without a dashboard. Three numbers move first: how many rounds of review a change needs before it is accepted, how often you retype a correction you have given before, and how long you spend setting up context before a familiar task starts. Write those down today for one recurring job. If they read the same in three months, the artefacts are not being read.