2026-04-19

Compound Engineering

AI-assisted coding feels fast - because it is, in the moment. But if every session starts from zero, you're permanently in beginner mode. The model doesn't remember your codebase's quirks, the decisions you rejected last Tuesday, or the bug that bit you in staging. Typing faster isn't the ceiling. The ceiling is whether the system you're building gets smarter with each shipped feature.

That idea has a name now. I only heard it a couple of months ago. Every published the article in late 2025 and the plugin landed in early 2026, but I'd been practising most of it for a while, under various names. Plan files, rules, skills, a post-ship capture habit. It was what worked. Now there's terminology for it, and a scaffold for anyone curious.

Every feature you ship should make the next feature easier to build.

That's compound engineering. Not a tool, not a framework - a discipline. Each pass through the loop leaves your system (codebase, docs, rules, etc.) in a better state for the next session's agent, and the next human. Returns compound because each improvement makes the next one easier.

The compounding curve

Two teams, same tool, same model. One treats Claude Code like smart autocomplete - linear gains. The other cultivates it as a system, and the gains accelerate.

The delta compounds weekly. After a quarter, they aren't in the same conversation any more.

The loop that makes it work

Four phases: plan, work, review, compound. Most teams already do the first three. The missing leg is almost always the fourth.

Plan - specifying intent before code. Plan files survive context resets, which is why they matter.
Work - the feature itself; agents do the typing.
Review - your taste catches drift before anything ships.
Compound - the pass that turns a shipped feature into leverage for the next.

What compounds in Claude Code

Here's where compounding actually lives in my setup - the main levers I pull to make the next session start smarter than this one.

Artifact	What it compounds
`CLAUDE.md`	Conventions, domain language, guardrails
`.claude/rules/*.md`	Modular, reusable rules across projects
`.claude/skills/*`	Repeatable workflows
`.claude/agents/*`	Specialised reviewers, planners, scouts
`.claude/settings.json`	Lifecycle hooks - post-edit checks, session-end compound reminders
`.claude/plans/*.md`	Intent, specified before code
`CHANGELOG.md`	History of what shipped
`TODO.md`	Follow-ups captured, not floating

The table looks static. The dynamic underneath is what actually compounds.

Four of those surfaces - CLAUDE.md, rules, skills, agents - live in two places: globally, where every repo inherits them, and locally in each project, where they carry repo-specific conventions. They do different work. Global rules carry across every repo. Repo rules stay put.

The promotion path is where it gets interesting. A convention starts in a single repo's CLAUDE.md. If I find myself wanting to copy-paste it into a second repo, that's the signal to lift it to the global layer so every future project gets it for free. A rule graduating from repo-specific to global is the compound move - each new project either inherits one or donates one back.

The post-ship pass

Every merge should leave at least one of these slightly better.

Run it before merge. These are the six categories I use at the moment - a personal setup, not a canon. Your list will probably look different from mine. Skip what doesn't apply.

Documentation

Inventory reflects new modules and capabilities.

Regression guards

Integration tests, drift detection, boundary assertions.

Reusable tooling

Extract one-offs into CLIs or composable helpers.

Knowledge capture

Plan files, architecture decisions, new project rules.

Follow-up TODOs

Filed in the tracker, not left floating.

Changelog

A dated paragraph so future sessions can skim what shipped.

Codify it as a skill (e.g. /compound) and it's one invocation, not a checklist to remember. Then let Claude Code refine the skill after each pass - even the skill compounds.

Make it a habit

Cheap to do. Expensive to skip.

Knowledge evaporates, rules go stale, follow-ups get lost, and six months from now someone asks "why did we do it this way?" and nobody remembers.

No merge without a compound pass.

The pass isn't about the feature. It's about the surrounding system that makes the next feature easier.

Where to start

If you're experienced with AI coding, the fastest path is auditing your habits against the artifact map above. You're probably doing most of them already. Formalise the post-ship pass as a repeatable skill or checklist. Share your rules files somewhere the rest of the team can copy them.

If you're new to Claude Code, start with what the tool gives you out of the box: a CLAUDE.md for your repo, one or two skills for repeatable flows, a plan-file habit. Read Every's guide on compound engineering for the conceptual frame. Pair with someone who already has the habits - imitate before you optimise.

One honest note: I haven't used Every's plugin myself. My setup is built from Claude Code's native primitives - rules, skills, agents, plan files, a post-ship /compound skill I wrote for my own workflow. The plugin is worth a look as a pre-built starting point, but the native primitives are what I've actually used.

The takeaway

The goal isn't that Claude writes your code.
The goal is that your repo teaches Claude how to write your code - a little better every week.