The Era of Compound Engineering

How do you take responsibility for software when you no longer write its code—and rarely inspect it? Kieran Klaassen opens with that situation: he says he has written no code that year and has not looked at most of what he ships. Yet, he reports that thousands of people use Cora and trust it with their email inboxes. He is proud of both the product and its code.

The work has shifted into extracting his thinking and taste into a system. Over two years, he has been developing a workflow in which decisions survive the conversation that produced them. The aim is a practice that outlasts tool trends and benefits from stronger models: first understand how the engineering bottleneck moves, then build repeatable ways to ship, research, and do knowledge work.

At Every, writing, teaching, and product development feed into an AI lab for the future of work. Its studio uses mostly single-engineer teams to pursue problems they care about, with accumulated knowledge helping each iteration move faster. Cora is Klaassen’s product and the setting in which he developed compound engineering. He describes it as an agent-native email inbox: whatever a user can do, an agent can do too. In the version-two rebuild he presents, access spans desktop, phone, CLI, Codex, and MCP; he invites interested users to contact him for forthcoming beta access.

One engineer does not mean no assistance. Klaassen has support, design help, and specialist help with database and difficult engineering problems. He says the new rebuild began in January, using Ruby on Rails on the backend and React on the frontend. He owns the product, including speaking to users when something goes down.

As a former VP of engineering and founder, he already knew how to hire and grow teams. Sonnet 3.5 prompted the opposite experiment: how far could AI take the product before he needed to expand the engineering team? At the time of the talk, he was still working as its sole engineer with that supporting help.

The first constraint was generated code that hallucinated or simply did not work. Agents, skills, and review improved that layer. Then planning became the constraint: a good plan let the model undertake larger changes. Once plans improved, the difficult question became what to build. Talking to users and using his own product helped Klaassen understand which problems deserved attention.

As the scope grew and AI helped write plans, he found himself repeating instructions. Each repetition became a signal to store the knowledge. Initially, that meant adding it to CLAUDE.md; eventually, the file became too large, prompting a more deliberate memory system. The progression was code → plans → product direction → memory.

This moves the engineer’s effort from typing toward judgment and taste. Klaassen considers implementation mostly solved in his workflow; the harder question is where he should think deeply and where the model should take over. When a brainstorm exposes an important judgment, extracting it lets the next brainstorm begin with that thinking already available. He believes one engineer with such a system can outperform full teams using AI without one, though he offers no comparative measurement.

The loop is brainstorm → plan → work → review → polish → compound → repeat. Klaassen calls its division of attention a human–AI sandwich: the human supplies the bread, and AI handles the middle. Brainstorming requires deliberate attention to the problem and the intended outcome. At the other end, polish asks whether the result meets the desired standard—or needs better responsiveness, optimistic behavior, or more delight. Learning should be extracted throughout, especially where these human judgments enter the work.

The automated middle only becomes safe to leave running overnight or in parallel after it has been prepared. Klaassen’s allocation rule is 50% of the time delivering the feature’s value and 50% teaching the system from what went wrong. The second half asks what the system should know or do differently next time, rather than stopping as soon as this particular feature works.

The extracted knowledge lives in the repository as solution documents. That raises an obvious objection: supplying more documents consumes tokens. Klaassen reports an unquantified long-term token-efficiency benefit from making existing answers available. His explanation is that retrieving a known solution can avoid repeated review, correction, and research across the internet. He supplies no task baseline, model comparison, or token accounting for that finding.

The objective is to keep extracting knowledge until the middle can run independently and produce work that exceeds his expectations. His own capacity is relatively fixed, while model capability can improve. Repository knowledge gives those improving models access to decisions he would otherwise have to explain again.

The Compound Engineering plugin packages this workflow for tools including Codex, Claude Code, and Cursor. Klaassen describes support for ten other tools and reports hundreds of thousands of daily users; he does not provide a counting method or observation window. He developed it while building Cora and later shared it. The underlying practice does not require his plugin: storing useful information in files can be enough to begin.

The workflow has also expanded into product work. Co-contributor Trevin Chao brought product thinking to it, and Klaassen describes engineers, product managers, designers, and knowledge workers at Every using the same approach. The common operation is preserving useful knowledge so later work can start from it.

The first demonstration uses CE Ideate to examine open tickets and recommend what to work on next. Inputs can include Linear, GitHub issues, Slack, and Intercom. The command organizes that material into candidate work and makes arguments for and against pursuing it. Its demonstrated output is a clean HTML page that can be shared with a team.

Prior knowledge makes the recommendation more specific than a fresh list of ideas. OKRs and strategy establish the direction; past experiments and repository learnings establish what the team already knows. A strategy document created with CE Strategy can supply that context too. Ideas are scored against it. Klaassen has also seen people pass the resulting document into Claude Design to create a PowerPoint with an X–Y matrix showing promising opportunities relative to their OKRs.

CE Doc Review takes a PRD or another document and returns questions that sharpen it. Those questions can go back to the colleague who supplied the document. After the answers arrive, CE Compound preserves the resulting knowledge so a later review can use the answer instead of asking again.

The procedure is small enough to share with colleagues: review the document, resolve the questions, and store the answers for reuse. Klaassen describes running it in Cowork as well as Claude Code, making document review part of the shared workflow rather than something only an engineer can operate.

Moving people from Cora version one to version two is the larger problem used for CE Brainstorm, Klaassen’s most-used command. This is a deliberate thinking session: he blocks time and avoids multitasking. The command pulls in accumulated knowledge, examines differences between the versions, and consults the personas he has already defined. Those inputs help it ask questions about what different users need.

The goal is enough questioning to produce excellent work, not the feeling of progress that comes from answering a long questionnaire. Klaassen uses thirty questions as an example of activity that can feel productive without improving the outcome. The result of the session is a stored brainstorm document and a plan, with the learning compounded before the handoff to /LFG.

In the demonstrated workflow, /LFG is the automation loop. It can take the brainstorm’s output or a direct building request and run for hours. It performs planning, implementation, review, and testing, opens a pull request, exercises the product, and attempts repairs. Before-and-after video or screenshot evidence in the pull request helps the human see what changed.

After overnight jobs—potentially running in parallel—CE Polish brings human attention back to a pull request. Klaassen likes to run it in Cursor with an explanation on the left and the product on the right. The explanation matters because he also feeds recordings into /LFG, letting it analyze what went wrong; he may not have personally specified every problem it addressed. Polish first establishes what changed, which problem it solves, and how it solves it.

Polish raises the bar; it is not the QA stage. If functionality is broken here, the automated middle has failed. The distinctive example is a page with two logo marks. It works technically, but Klaassen does not want two marks on one page. He asks for only one, then runs CE Compound to extract that preference into a correctly tagged file that future design work can retrieve. The change can be merged while the learning remains available for the next feature.

A minimal Ruby implementation of the storage part could write the rule into a solution document:

require "fileutils"

FileUtils.mkdir_p("docs/solutions/design")
File.write("docs/solutions/design/logo-marks.md", <<~MARKDOWN)
  ---
  title: One logo mark per page
  tags: [design, branding]
  ---

  A page can function correctly while showing two logo marks.
  The product preference is to show only one logo mark per page.

  During future design work, inspect the whole page for duplicate marks.
MARKDOWN

The file path and document format here are an example of implementing the preference. Writing the file preserves the lesson; the design workflow must also find and use it. That retrieval step is what connects today’s correction to tomorrow’s output.

The practice resembles familiar software engineering, with AI taking on work previously coordinated across people. Newer models make accumulated knowledge more useful, but the workflow still needs discipline. Klaassen’s plugin-independent procedure is:

1. Extract repeated instructions. When you catch yourself explaining something again, preserve it where future work will find it.
2. Build an independent middle. Planning, implementation, and review should not routinely require your intervention.
3. Diagnose it manually when necessary. Work through the process yourself, locate where it goes wrong, and improve it until you can let go.

Klaassen’s readiness example is a three-hour autonomous run that consistently produces good results, rather than a measured reliability threshold. The intended experience is boring: it should just work.

Document the thinking, not just the code. Code is the artifact of a decision; its rationale helps a later agent generalize beyond that implementation. Even imperfect traces can help explain an incident. A postmortem can reconstruct what happened, identify which person or agent made the consequential decision, and turn that finding into a lesson that changes future behavior. Klaassen finds postmortems particularly useful for this kind of extraction.

This returns to the allocation rule: spend half the effort making the system better for the next interaction. Once a feature works, moving on is tempting. The additional work is to make the system remember what made it work—and what would prevent the same mistake from recurring.

The underlying bet is that implementation will keep getting cheaper while judgment will not. Future models need access to the taste and decisions accumulated today. Human attention therefore stays at the ends: understand the problem before delegating, then evaluate the working result and raise its quality. Initial understanding should not be offloaded, and final attention should not be consumed by repairing basic failures.

The next feature should be easier because you shipped this one. A feature ordinarily adds code and complexity that later work must navigate. A compounding workflow should also add knowledge that makes later decisions and execution easier. That is the standard Klaassen proposes for judging whether the system is improving.

The open-source plugin is one way to build that system, and Klaassen welcomes contributions. The broader invitation is to build an orchestration system or personal knowledge base that preserves what you learn, so each completed piece of work improves the conditions for the next.