Compound Engineering

Compound Engineering describes a particular way of building software. The basic idea: every task should make the next task easier. Whoever solves a problem doesn’t just write the solution, but also records what they learned in the process. These notes and rules are then given to the AI assistants that help with programming. The word “compound” refers here to compound interest: small amounts that add up and reinforce each other over time. So instead of starting from zero every day, a stock of knowledge keeps growing.

The compound-interest effect in everyday development

In many teams, the opposite happens. A developer discovers a stumbling block, fixes it, and tells no one about it. Three months later, a colleague falls into exactly the same trap. Such repetitions cost an enormous amount of time, yet they show up in no statistics. Compound Engineering tries to systematically stop this loss.

The idea became especially important with the rise of AI assistants that suggest code. These programs are fast, but they don’t inherently know the peculiarities of a project. Without guidance, they make the same mistakes in every new conversation. Anyone who instead gives the assistant a well-maintained collection of project rules gets noticeably better suggestions. The effort for this collection is incurred once, while the benefit arises with every further request.

For companies, this is an economic argument. A team that records its findings becomes faster over the months without hiring new people. A team without this memory stays just as fast, no matter how many AI tools it buys.

What remains after every task

In practice, this mostly runs through three types of traces. First, text files with project rules that the AI assistant reads along with every session. These state, for instance, which libraries are allowed or what error messages should look like. Second, automated tests: small programs that check after every change whether everything still works. Anyone who fixes a bug writes a test for it, so that the same bug never quietly returns.

Third, documented decisions. When a team decides on a particular database, it briefly notes the reasons. Later, no one asks anymore why it was done that way, and the discussion doesn’t start over from scratch. A fitting image is a cookbook that grows a marginal note after every meal: “Ten minutes less in the oven, otherwise it gets dry.”

It’s important to distinguish this from pure documentation. Ordinary documentation often sits in a wiki and is rarely read. With Compound Engineering, what is recorded must sit right where the work happens, that is, in the project directory or directly in the tests. Only then does it work automatically. A common mistake is to keep piling up more and more rules. Overly long rule files confuse both humans and AI models, so cleaning up is part of it too.

Where the term appears

The developer Kieran Klaassen of the software company Every popularized the expression, using it to describe his work with AI assistants. Since then it has appeared in blog posts, at developer conferences, and in job postings. Some companies use it as a buzzword for their entire AI strategy.

In concrete terms, one encounters the idea in tools like Claude Code, Cursor, or GitHub Copilot. These assistants read rule files from the project, often named things like AGENTS.md or claude.md. Exactly such files are the practical core of Compound Engineering. Anyone who programs themselves can try this out on a small scale: create a file and add a line after every problem solved.

In business news, the term most recently came up in connection with the question of why AI tools save a lot of time at some companies and barely any at others. The common explanation is: it’s not the model that’s lacking, but the accumulated project knowledge. Skeptics counter that this is simply an old principle of good engineering practice wearing a new name.