Compound Engineering: The AI Loop Where Every Task Makes the Next Easier

Most people use AI coding the same way every day and never get better at it. Compound engineering flips that. It is a loop where every bug, fix, and review gets recorded as a permanent lesson, so the next task starts smarter than the last. You stop re-explaining your stack. The mistakes you caught last week do not come back.

The payoff is simple. Your first feature is hard. Your tenth is easier than your first, because the system learned from the nine before it.

What is compound engineering?

Compound engineering is a way of working with AI agents where each unit of engineering work makes the next one easier. The term was coined by Dan Shipper and Kieran Klaassen at Every, who define it plainly: "In compound engineering, you expect each feature to make the next feature easier to build" (Every, "Compound Engineering," Dec 11, 2025, updated Jun 3, 2026).

That is the opposite of normal software, where every feature you add makes the codebase a little heavier and the next change a little slower. Compound engineering inverts the curve by treating lessons as assets. Every PR teaches the system. Every bug becomes a rule that stops it from happening twice.

It came out of real product work, not theory. Klaassen, general manager of Cora (Every's AI chief-of-staff for email), built the approach while shipping production software with agents. Every now runs several software products in-house, each primarily built and maintained by a single person using this loop (Every, Jun 2026).

The key distinction: this is not generic "AI coding." Generic AI coding is one-off prompting. You ask, it answers, the context evaporates when the session ends. Compound engineering is a system with memory. The output of one task is captured and fed back in as input to the next.

Why does compounding beat one-off prompting?

Because one-off prompting has no memory, so you pay the same teaching tax forever. Compounding pays it once.

Think about what happens in a normal AI coding session. You explain your folder structure. You remind the agent you use oRPC, not tRPC. You point out the same null-check bug you pointed out yesterday. The session ends, and all of that disappears. Tomorrow you start from zero. Your hundredth session is no smarter than your first.

Now picture the compounding version. The first time the agent ships a bug because it forgot to handle an empty array, you record that lesson. The next time it plans a feature, it reads that lesson and writes the guard automatically. The error is now structurally impossible to repeat. Klaassen sums up the result: "mistakes get caught, codified, and they don't happen twice" (Roger Wong, summarizing Klaassen's tutorial, Feb 26, 2026).

This is why the work compounds. Each lesson is permanent and reusable. Ten lessons make the agent meaningfully better. A hundred lessons make it feel like a senior engineer who has worked on your exact codebase for a year. The investment is front-loaded, like onboarding a teammate, and it pays back on every task after.

There is a weighting that makes this work in practice. The compound engineering method puts most of its effort into thinking, not typing. Every's own plugin states the split directly: "80% is in planning and review, 20% is in execution" (EveryInc/compound-engineering-plugin, GitHub, Jun 2026). Execution is cheap when the plan is good and the lessons are loaded. The leverage is upstream.

The plan-build-review-compound loop

The loop has four steps, and the fourth is the one everyone skips. Here is each step in plain English, drawn from Every's definition (Every, Jun 2026).

Plan. The agent reads the issue, researches approaches, and writes a detailed implementation plan as a markdown file: data models, file references, architectural decisions, edge cases, and sources. Critically, the planner pulls from past lessons so it avoids pitfalls it has already learned about.

Build. The agent takes that plan and produces a pull request. Code gets written, tests get generated, docs get updated. Because the plan was thorough, the build is mostly mechanical.

Review. You review two things, not one. You review the code itself, and you review the lessons the work surfaced: a new bug pattern, a performance trap, a cleaner way to solve something.

Compound. This is the step that makes it compound. You feed the lessons back into the system so the next loop is better. Every describes it as the engineer feeding "the results back into the system, where they make the next loop better by helping the whole system learn from successes and failures" (Every, Jun 2026).

In a diagram, the loop is a circle, not a line:

   ┌──────────────────────────────────────────┐
   │                                            │
   ▼                                            │
 PLAN ──▶ BUILD ──▶ REVIEW ──▶ COMPOUND ────────┘
  ▲                                │
  │     reads past lessons         │  writes new lessons
  └────────────────────────────────┘
        (the lessons file)

Skip the compound step and you just have plan-build-review, which is fine but flat. The compound step is the flywheel. It is what turns a one-time effort into a permanent capability.

How to set up compound engineering in Claude Code

You set it up with three pieces: a rules file the agent always reads, a lessons file it appends to after each task, and a repeatable capture step that turns review notes into rules. You can build this by hand, or install Every's official plugin. Start by hand so you understand the mechanics.

1. The rules file the agent always reads

Claude Code automatically loads CLAUDE.md from your project root into context at the start of every session. This is your standing memory. Put your stable conventions here: stack, structure, and the bar for what "done" means.

Create CLAUDE.md in your repo root:

# Project: Acme SaaS

## Stack
- Next.js 16, React 19, TypeScript strict
- oRPC + Zod for the API layer (NOT tRPC)
- PostgreSQL via Supabase, row-level security on every table
- Tailwind v4 + shadcn/ui

## Conventions
- Server Components by default. Add "use client" only when you need state or effects.
- Every API procedure validates input with a Zod schema.
- Every database table has an RLS policy. No exceptions.
- Tests live next to the file they test, named `*.test.ts`.

## Definition of done
- Type-checks clean: `npm run typecheck`
- Lint clean: `npm run lint`
- Build passes: `npm run build`
- New behavior has a test.

## Always read before planning
@.claude/lessons.md

The last line matters. The @ syntax tells Claude Code to pull .claude/lessons.md into context too, so your accumulated lessons load on every session alongside the rules.

2. The lessons file that grows over time

This is the compounding asset. It starts empty and grows one entry at a time. Each entry is a mistake the agent made, written so the agent will not make it again. Keep entries short, specific, and phrased as rules.

Create .claude/lessons.md:

# Lessons

Append one entry per real mistake or insight. Newest at the bottom.
Each entry: what went wrong, the rule that prevents it.

## 2026-06-08 — Empty arrays crashed the dashboard
The metrics chart threw when a new user had zero events.
RULE: Components that render lists or charts must handle the empty case
explicitly. Render an empty state, never assume length > 0.

## 2026-06-08 — Stripe webhook processed events twice
A retried webhook double-counted a subscription.
RULE: Every webhook handler must be idempotent. Check for an existing
record by the event id before writing.

## 2026-06-08 — RLS policy missing on new table
The `invoices` table shipped without row-level security.
RULE: A migration that creates a table is incomplete until it also
creates the RLS policy in the same migration file.

By the time you have 30 entries, the agent is dodging 30 categories of bug before it writes a line. That is the compounding.

3. The capture step that records lessons after each task

This is the discipline most people drop. After a task, before you move on, you ask the agent to extract lessons and append them. Save this as a reusable slash command so it is one keystroke, not a paragraph you retype.

Claude Code reads custom commands from .claude/commands/. Create .claude/commands/compound.md:

---
description: Capture lessons from the work we just finished and append them to the lessons file.
---

Review the work we just completed in this session.

Identify any reusable lessons:
- Bugs we hit and how we fixed them
- Performance traps we found
- Conventions we clarified or corrected
- Anything that would have made this task faster if we had known it upfront

For each lesson, write a short entry in this exact format:

## <today's date> — <one-line title>
<one or two sentences on what went wrong>
RULE: <the imperative rule that prevents it next time>

Append the entries to .claude/lessons.md under the existing entries.
Do not duplicate a lesson that is already there. If a new lesson refines
an existing rule, update the existing entry instead of adding a new one.

Now your loop in Claude Code is concrete. Plan the feature. Build it. Review the PR. Then run /compound to record what you learned. The next /plan reads those lessons automatically, because CLAUDE.md pulls lessons.md into context. The circle closes.

4. Optional: install Every's official plugin

If you want the proven version instead of the hand-rolled one, Every ships the loop as a Claude Code plugin. As of June 2026 it has 20.6k stars and an MIT license, and it works across Claude Code, Cursor, Codex, GitHub Copilot, and Factory Droid (EveryInc/compound-engineering-plugin, GitHub).

Install it inside Claude Code:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

It adds the full loop as slash commands (EveryInc/compound-engineering-plugin, GitHub, Jun 2026):

/ce-strategy        maintain a STRATEGY.md that grounds the product
/ce-ideate          generate and evaluate big-picture ideas
/ce-brainstorm      interactive Q&A to build a requirements doc
/ce-plan            turn an idea into an implementation plan
/ce-work            execute the plan with worktrees and task tracking
/ce-debug           reproduce and fix failures systematically
/ce-code-review     multi-agent review before merge
/ce-compound        document learnings for future reuse
/ce-product-pulse   time-windowed usage and performance report

The everyday loop is /ce-brainstorm then /ce-plan then /ce-work then /ce-code-review then /ce-compound, then repeat. Same four phases you built by hand, with research, debugging, and multi-agent review wired in.

Where this fits if you are shipping a real SaaS

The hand-rolled setup above is the method. Productizing it for a full SaaS, with the orchestrator, the agent roles, and the quality gates already wired together, is exactly what Build This Now does. Its pipeline is the compound loop applied to an entire product: /discover plans the market and feature specs, /mvp-build runs an orchestrator that spawns the right specialist agents in order, every feature passes type-check, lint, and build gates before it counts as done, and the system records what it learns so later features build on earlier ones. It is $197 one-time, built on Claude Code. Compound engineering is the principle. This is one way to buy it pre-assembled instead of wiring it yourself.

Frequently asked questions

Who invented compound engineering?

The term was coined by Dan Shipper and Kieran Klaassen at Every. Klaassen developed the practical loop while building Cora, Every's AI email chief of staff, and the team now uses it to run several in-house products each maintained by a single person (Every, Jun 2026).

How is compound engineering different from just using Claude Code?

Plain Claude Code use is one-off: you prompt, it responds, the context disappears at the end of the session. Compound engineering adds a memory layer. You capture lessons after each task into a file the agent reads on every future session, so it stops repeating mistakes and gets measurably better over time. The method weights effort heavily toward planning and review (Every's plugin cites an 80/20 split) rather than raw code generation (EveryInc/compound-engineering-plugin, GitHub, Jun 2026).

Do I need the Every plugin, or can I do this by hand?

You can do it entirely by hand with three files: a CLAUDE.md rules file, a .claude/lessons.md lessons file referenced from it, and a /compound slash command in .claude/commands/ that appends new lessons after each task. The official EveryInc plugin packages the same loop with extra commands for strategy, debugging, and multi-agent review if you want the assembled version (EveryInc/compound-engineering-plugin, GitHub).

What actually makes the work compound?

The fourth step of the loop: compound. After plan, build, and review, you feed the lessons back into the system so the next loop starts smarter. Skip that step and you have a fine linear workflow that never improves. Keep it, and every task permanently raises the floor for the next one (Every, Jun 2026).

How long before compounding pays off?

It front-loads like onboarding a teammate. The first few tasks feel like extra work because you are writing rules and lessons as you go. By the time you have a few dozen lessons recorded, the agent is avoiding whole categories of bug before they happen, and new features land faster than old ones did. Klaassen frames the trust as something that builds iteratively, the same way you learn to delegate to a new hire (Roger Wong, Feb 26, 2026).

Posted by @speedy_devv