Learning from Every's Compound Engineering

One of the relatively few AI-native products I use is Cora.computer which summarizes my personal inbox. It’s not perfect, but it’s done a much better job than my collection of filters at managing the ever-growing onslaught of spam and unsolicited email that flows in.

I’ve run into a few issues with Cora, which ended up in me following folks at Every to report the issues, and more recently this led me to see their work on compound engineering and specifically the compound-engineering-plugin.

Compound Engineering is two extremely well-known patterns, one moderately well-known pattern, and one pattern that I think many practitioners have intuited but have not found a consistent mechanism to implement. Those patterns are:

1. Plan is decoupling implementation from research. This is well understood, e.g. Claude’s plan mode, although it can certainly be done better or worse by being more specific about which resources to consult (specs, PRDs, RFCS, issues, etc)

2. Work is implementing a plan. This is well understood, and the core of agentic coding. Again, this can be done better or worse, but much of that depends more on the quality of your codebase, tests, and continuous integration harness than the agent itself

3. Review is asking the agent to review the changes against your best-practices, and identify ways it could be improved. I think most practitioners have some version of this, but standardization is low, even within a given company.

4. Compound is asking the agent to summarize its learnings from a given task into a well-defined, structured format (basically a wiki) which is consulted by future iterations of the plan pattern. This interplay between the compound and plan steps creates the compounding mechanism.

   Many practitioners are implicitly compounding, but it’s often done manually through their own work. For example, I’d often ask the agent to update our AGENTS.md or skills based on a specific problem encountered in a task, but it required my active attention to notice the issue and suggest incorporation.

Taken together, these four steps are not shocking but are an extremely effective way to convert these intuited best-practices into something specific, concrete, and largely automatic within a company by adding a few commands (e.g. workflow:plan, workflow:review, …) and updating your AGENTS.md to instruct the agent when and how to use those commands.

Implementing within Imprint’s frontend and backend monorepos was straightforward, taking about an hour. Most of this was iterating on the last mile of details, for example we want our plans in .claude/plan-*.md format to match our existing .gitignore pattern, and none of it was complex. Most importantly, this frees up a topic that many of our engineers (including me) were trying to find a standard approach. Now we have one, and can move on to the next problem.

If recent history is our guide, it’s a solid guess that many of the practices in compound engineering will get absorbed into the Claude Code and Cursor harnesses over the next couple of months, at which point using these techniques explicitly will be indistinguishable from folks who are entirely unaware they’re using them. But we’ll see. Until then, this is a cheap, useful experiment that you can implement in an hour.