Compound Engineering: Why Each Task Should Make the Next One Easier
Most projects get harder over time. Compound engineering inverts this by encoding every lesson back into the system. The same discipline works for code, AI agents, and leadership.
Every project gets harder to run over time. More features mean more code to maintain. More complexity means more things that can break. Growth adds friction.
That's the default. Most builders accept it as a law of nature.
Compound engineering says it doesn't have to be. And the principle applies far beyond code.
The core idea
The term comes from Dan Shipper and Kieran Klaassen at Every, where they build and operate five software products, each primarily run by a single person. Their core principle:
Each unit of work should make subsequent units easier, not harder.
The mechanism is codification. When something goes wrong, you don't just fix it. You document why it went wrong, update the instructions, add a validation check that catches the category of error. The fix is permanent. The class of problem is eliminated. The system got smarter.
This is compound interest applied to work.
The four-phase loop
Every task follows the same cycle: Plan, Work, Review, Compound.
Plan: Research what exists, read prior documentation, check for similar past work. The more institutional knowledge is available, the better the plan.
Work: Execute. Code, configuration, analysis.
Review: Not just "does it work?" but "what did we learn?" What assumptions turned out wrong? What edge cases emerged?
Compound: Encode the lessons back into the system. Updated documentation. New validation rules. Revised instructions. This is the step most people skip. It's also the step that creates all the value.
The counterintuitive insight: at Every, roughly 80% of effort goes into Plan and Review. Only 20% goes into Work and Compound. When your tools are fast enough to execute in minutes, the bottleneck isn't execution. It's knowing what to do and learning from what was done.
This is how good management works
I've spent 20+ years in enterprise sales and leadership. I've been called a "force multiplier" at work: someone who makes the people around them more effective.
When I first read about compound engineering, I recognized the pattern immediately. It's how the best organizations already operate.
After a negotiation, the effective leader doesn't just move on to the next deal. They codify what worked. I built a document on negotiation techniques that started as personal notes and is now shared broadly across the organization. Each lesson from a real engagement, encoded once, benefits every person who reads it afterward. One experience becomes institutional knowledge.
That's the compound step applied to management. Most organizations skip it. They debrief, nod, and forget. The next team facing a similar situation starts from scratch. The knowledge stayed locked in one person's head.
The compound engineering framing gave me a name for something I'd been doing instinctively: treating every experience as a deposit into organizational intelligence.
Applied to AI agents
The same loop works when building with AI. Every review cycle that updates agent instructions is a deposit into a compounding account.
Quality that compounds. My quality gate runs seven checks before every deploy. The checks themselves evolve. When a new failure mode appears, it gets added. After hundreds of commits, the gate catches failure modes that didn't exist during the first hundred. Each test is a codified lesson that prevents a category of regression permanently.
Operations that compound. My monitoring didn't originally track certain patterns. That check was added after noticing unexpected behavior once. One observation, codified into permanent monitoring. The next anomaly gets caught automatically.
The gap between compound and linear widens with every cycle:
| Metric | Linear | Compound |
|---|---|---|
| Bug fix | Fix each instance individually | Fix once, prevent category permanently |
| Quality validation | Same checks, same coverage | Growing test suite, expanding coverage |
| Operational awareness | Check dashboards manually | Anomaly detection with historical context |
A linearly-operated system at month 12 works as hard as it did at month 1. A compound-engineered system operates with accumulated intelligence that didn't exist at month 1.
Three habits to start
You don't need complex tooling to start. You need three habits.
1. After every task, ask: what did the system learn? Not "what did I learn." What did the system learn? If the improvement lives only in your head, you skipped the compound step.
2. Treat documentation as investment, not overhead. Every guideline, every test case, every rule is a deposit into a compounding account. Skipping documentation to "save time" is withdrawing from the account.
3. Track the ratio, not just the output. Don't just measure how many things you shipped. Measure how long each one took compared to the last. If the ratio isn't improving, the compound loop is broken somewhere.
I applied compound engineering to how I organize my AI assistant and to building a memory system for it. Both started messy. Both got better with every cycle.