Compound Engineering · Every (Kieran Klaassen and Trevin Chow) · as of September 30, 2026
Compound Engineering’s most important step starts after the code works
Most AI development methods end when the code is reviewed. Compound Engineering then asks what the work taught, writes it down, and makes the next plan read it, so a trap you fall into once is already a constraint the next time.
This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.
Two philosophies at a glance
Compound Engineering
Each unit of work should make the next one easier: plan and review thoroughly, then write down what you learned where the next plan will read it.
The Enso Method
Define the whole body of work first and keep its requirements current, so every change starts from what the system is meant to do.
Where they differ
- Each task starts fresh Lessons carried to later work Compound Engineering sits at the “Lessons carried to later work” end; the Enso Method sits toward “Each task starts fresh”.
- Specs serve one change Specs live as long as the system Compound Engineering sits at the “Specs serve one change” end; the Enso Method sits at the “Specs live as long as the system” end.
- One change at a time The whole body of work up front Compound Engineering sits at the “One change at a time” end; the Enso Method sits at the “The whole body of work up front” end.
- The developer at the keyboard decides Someone who isn’t at the keyboard decides Compound Engineering sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
What they share
- Built to be watched Built to run unattended Compound Engineering sits at the “Built to run unattended” end; the Enso Method sits at the “Built to run unattended” end.
- Starts from a prompt Intent written down first Compound Engineering sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.
Run one teaches it. Run two remembers.
“Each unit of engineering work should make subsequent units easier -- not harder.” That is Compound Engineering’s founding rule. Its README names what goes wrong without it: “Every bug fix leaves behind a little more local knowledge that someone has to rediscover later.”
So its loop ends with an extra step. Once the work is verified, ce-compound asks whether “a future engineer reading the final implementation” would “still be likely to repeat the mistake or redo substantial investigation”. If so, it writes a learning into the repository and checks its claims against the code. Before the next substantial plan, a researcher searches those learnings.
The README’s demo replays two real sessions 18 days apart. The first recorded why an environment variable never reached a development copy of the app, redirecting every signed-in user. The second, on unrelated work, found that note among 71 and carried two constraints from it into its plan that the prompt never mentioned.
A loop whose last step feeds the first
- Brainstorm. What to build, one question at a time. A fuzzy idea is pressure-tested, even against doing nothing, then written into a dated plan.
- Plan. How to build it, after research agents read the codebase and past learnings. Each unit names its files, patterns to follow and test scenarios.
- Work. Test-first by default where practical, with independent units built in parallel.
- Simplify and review. Specialist reviewers are picked for the change, and findings are admitted on evidence, not on how many reviewers agree.
- Compound. Capture what the work taught, if it taught anything.
/lfg runs the whole loop hands-off and stops at an open pull request with its checks run; merging stays yours. The README’s advice: “Start it after /ce-brainstorm so it plans against real requirements rather than a one-line prompt.”
Built for a codebase you’ll keep working in
Compound Engineering fits a developer, or a small team sharing one repository, who decides what gets built and will keep working in the same codebase. Its makers describe their users as “Agent-first developers who work across more than one harness and model”.
Its makers say “80% is in planning and review, 20% is in execution”, and much of that runs as parallel agents. It doesn’t hide the cost: before its ideation skill sends agents out, it lists them, “so multi-agent cost is not invisible”. Setup is one plugin install; /ce-setup checks the rest.
It suits you less if the product decisions belong to someone outside the chat, or if you want the whole project specified before anything is built.
Where the Enso Method made a different call
Both write intent down before code, settle technical questions from the code instead of asking you, and run without you watching. They part on three things.
What the next piece of work starts from
Compound Engineering
The lessons of past work. Each plan is a dated record of one piece of work; the learnings are what gets maintained.
The Enso Method
The system’s requirements and design, amended before every change, so they always say what the system is meant to do.
Choose by situation: if rediscovering old traps costs you most, Compound Engineering; if losing track of what the system should do, the Enso Method.
How far ahead it plans
Compound Engineering
One coherent piece of work at a time. Handed several, it asks which to take first; it “does not create a parent plan or a roadmap.”
The Enso Method
The whole body of work first, as requirements and a technical design, then the build in session-sized phases.
Choose by situation: a steady stream of features on a live product fits Compound Engineering; a project with a defined finish line fits the Enso Method.
Who settles the product questions
Compound Engineering
You do, in the brainstorm: “The user decides unresolved product direction, preferences, and scope.”
The Enso Method
The agent proposes an answer to each business question, with a confidence level, and keeps building while its owner confirms or corrects it.
Choose by situation: if you own the product, a short dialogue is simpler; if you build for someone who isn’t in the chat, the Enso Method.
Where Compound Engineering shines
- Lessons that come back. A strict bar for what gets written, claims checked against the code, and pruning, because “Two docs saying the same thing will eventually say different things.” The Enso Method has no store of lessons that later plans search.
- Review on evidence, not consensus. Agreement between reviewers running on the same model “never raises confidence”; only a reviewer from another model family can.
- Hands-off to a pull request.
/lfgruns from schedulers and loops; a separate watcher then answers review comments and fixes failing checks. - Tested, and portable. Behavior changes to its skills must be evaluated on real agents, and it installs into 14 of them. The Enso Method doesn’t test its skills yet, and supports two.
How the Enso Method differs, and why
In Compound Engineering, each change starts from the lessons of earlier ones; in the Enso Method, it starts from requirements kept current for the life of the system. Compound Engineering plans one piece of work at a time, with you settling the product questions; the Enso Method defines the whole body of work first and sends business questions to the people who own them while the build continues.
Get started
Compound Engineering is free and open source (MIT) and installs into 14 coding agents, including Claude Code, Cursor and Codex; each one’s install steps are in the README at github.com/EveryInc/compound-engineering-plugin.