Compound Engineering: How Each Session Makes the Next One Easier

If you've ever shipped a feature and felt like the next one got harder—more edge cases, more interdependencies, more "why did we build it that way?"—you've run into the old reality of software engineering. Code accumulates. Complexity compounds. Each sprint can feel like you're carrying more weight.

Compound Engineering flips that script. It's an AI-native methodology where each unit of work is designed to make the next unit easier. The idea comes from Every (Dan Shipper and Kieran Klaassen), who use it to run multiple products with small teams and AI agents doing most of the coding. In their words: "Each unit of engineering work should make subsequent units of work easier—not harder." That's not wishful thinking; it's a learning loop. Every bug, failed test, and aha moment gets documented and fed back so future agents (and humans) don't repeat the same mistakes.

This post breaks down what Compound Engineering is, the four-step loop that makes it work, and how you can start applying it so you literally wake up smarter after every session.

What Is Compound Engineering?

In traditional engineering, you expect each feature to make the next feature harder. More code means more edge cases, more interdependencies, and more issues that are hard to anticipate. Technical debt piles up. New hires need months to get productive. The codebase becomes a maze.

Compound engineering inverts that. You treat process knowledge as a first-class artifact. Your prompts, templates, repo rules, and guardrails improve with every iteration. The codebase still grows, but so does the AI's (and the team's) knowledge of it—which makes future development faster and safer.

Think of it like compound interest for your workflow. Small, consistent improvements—captured and reused—add up. One good "don't do X here" rule prevents a whole class of bugs. One reusable plan template cuts planning time in half. One codified lesson from a failed deploy makes the next deploy smoother. Over time, you're not just shipping code; you're shipping capability.

The Compound Engineering Loop

The process is a loop: Plan → Work → Review → Compound. (Some write it as Plan → Delegate → Assess → Codify; "Compound" and "Codify" are the same idea: encode what you learned so the next cycle is better.)

Roughly 80% of the value is in Plan and Review. The actual "work" step—having agents write code—is the part that gets easier over time because of how well you plan and how ruthlessly you compound.

1. Plan

In a world where agents write most of the code, planning is where most of a developer's time goes. A good plan isn't a vague wish list; it's a document detailed enough that an agent can execute it.

What to include:

• Goal and scope — What we're building and what we're not building (non-goals).
• Constraints — Security, performance, UX, compatibility.
• Acceptance criteria — Definition of done. How we know it works.
• Where to change things — Files, components, and repo conventions so the agent doesn't guess.
• Test plan — What proves it works (manual checks, automated tests).

Before writing the plan, the agent should research: read the codebase and commit history, and scour the internet for best practices. That way the plan is grounded in your actual system and current standards.

Planning builds a shared mental model between you and the agent before you build. Good planning isn't pure delegation—it requires you to think hard and push the agent down the right paths. As models get better, you may need less planning for small projects; for complex production work, a solid plan remains essential.

2. Work

This is the step that feels like "engineering" in the old sense—except the agent does the typing. You hand off the plan; the agent turns it into a to-do list and builds step by step.

Practical tip: Use tools that give the agent context about your running system. For example, a model context protocol (MCP) like Playwright or XcodeBuildMCP lets the agent use your web app or simulate a device as it builds. It can write code, walk through the app, notice issues, and iterate until the result matches the design. That's especially valuable for UI and workflows.

With current models, the output of the work phase is often close to what you envisioned—if the plan was clear. The next two steps are what prevent that work from becoming one-off code that makes the next feature harder.

3. Review (Assess)

Before you call it done, you and the agent review the work. This can include:

• Linters and unit tests — Catch basic errors automatically.
• Manual testing — Sanity-check behavior and UX.
• Code review — Either you review, or you use an automated reviewer (e.g., Claude, Codex, or a dedicated review agent).

Every's compound engineering plugin, for example, runs multiple subagents in parallel—one for security, one for performance, one for over-engineering, and so on—and synthesizes their feedback. The goal isn't to slow you down; it's to catch issues and patterns that you can then codify so they don't happen again.

4. Compound (Codify)

This is the step that makes compound engineering compound. You take what you learned in Plan, Work, and Review—bugs, performance pitfalls, better patterns, confusing spots—and encode it so the next loop is faster and safer.

What to codify:

• Repo rules / agent instructions — "Here's how we do X in this codebase."
• Reusable prompts and templates — Plan templates, PR templates, investigation templates.
• Guardrails — Tests, linters, CI checks, invariants.
• Known pitfalls — "We tried Y and it broke because Z; do this instead."

For example, in the codebase for Every's AI email assistant Cora, before building anything new the agent is prompted to ask: Where does this belong? Should it extend something that already exists? Have we solved something similar before? Those questions are backed by concrete examples from past mistakes, so the agent is primed to choose the right place and pattern.

These rules are often built in a semi-automated way: after a code review, you ask the agent to summarize the comments and suggest rules or docs to add. The key is that learnings live in the repo or in shared prompts, so every developer (and every agent run) benefits. A new hire gets the same "don't repeat this mistake" context as someone who's been on the team for years.

Session → Review → Learn → Update → Better Sessions

You can think of the loop at a higher level too: Session → Review → Learn → Update. Each session is a cycle. You review what happened (tests, manual checks, code review). You learn (what went wrong, what went right, what was surprising). You update (repo rules, prompts, templates, docs). The result is better sessions next time—and over time, fresh knowledge that sticks. That's the "wake up smarter" idea: you're not just finishing tasks; you're improving the system you use to finish the next one.

A Five-Minute Codify Checklist

After you ship something, spend a few minutes answering and encoding:

1. What confused the agent or us? — Turn the answer into a clearer instruction or doc.
2. What instruction would have prevented the first mistake? — Add it to repo rules or your agent's context.
3. What automated check would catch this earlier next time? — A test, a linter rule, a CI step.
4. What pattern or template should become the default? — Reusable plan, component, or workflow.
5. Where should this live so it gets reused automatically? — Rules, prompts, CI, docs.

If you do this consistently, you're doing compound engineering. The loop does the rest.

Why This Matters for Teams and Solos Alike

Compound engineering is tool-agnostic. Every uses Claude Code heavily and has built the compound engineering plugin for it, but the same loop works with other agents (e.g., OpenAI's Codex CLI or Factory's Droid). The methodology is about how you work, not which chatbot you use.

For teams, the payoff is that knowledge spreads automatically. Conventions and pitfalls live in the codebase and in shared prompts, so onboarding is faster and quality is more consistent. For solo developers and small shops (like Defendre Solutions), the payoff is that you're not just shipping features—you're building a system that gets better every time you use it. Each session really can make the next one easier, and over time you wake up smarter: with better defaults, fewer repeated mistakes, and a process that compounds instead of crumbles.

---

Compound Engineering was popularized by Dan Shipper and Kieran Klaassen at Every. For more depth, see their essay Compound Engineering: How Every Codes With Agents and the compounding engineering loop summary. The compound-engineering-plugin on GitHub lets you run a similar workflow in Claude Code.