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.