Compound Engineering - What It Means and How to Start with AI Agents

Q: What are the steps of the compound engineering loop?

Four steps, repeated for every piece of work. Plan: the agent researches the codebase and writes a detailed implementation plan. Work: the agent carries out the plan step by step, running tests as it goes. Assess (called review in the plugin): you and review agents check the result with tests, linters, and security checks. Compound: you record what was learned as rules, tests, or notes in the repository so future tasks start from it. Skipping the fourth step is what turns this back into ordinary AI-assisted coding.

What is Compound Engineering?

Compound engineering is a way of building software with AI agents where every completed piece of work makes the next one easier. In traditional development, the hundredth feature costs about as much as the tenth. In compound engineering, you deliberately capture what each task taught you (the patterns, the mistakes, the project conventions, the tests) so that both you and your agents start the next task with more context than the last. The difference from traditional software engineering is that learning is treated as part of the deliverable, not a side effect.

The term was popularized by Dan Shipper and Kieran Klaassen at Every, who describe a loop of plan, work, assess, and compound. (Their Claude Code plugin calls the third step review, and adds a brainstorm step up front.) Agents plan and build, humans and review agents check the result, and then the lessons get written down where future agents will find them. That last step is the one most teams skip, and it’s the one the name is about.

This post is my take on it: what it means in practice, where the real leverage is, and what I’d set up first if I were starting over.

TL;DR

AI has made writing code cheap. It has not made knowing whether the code is right cheap.
So the bottleneck moves to feedback: tests, type checks, CI, review, and how quickly you find out you were wrong.
Guardrails (types, specs, project instructions) matter more than clever prompts.
The “compound” part comes from writing down what you learn, so the next task is easier than the last.
I can’t give you a reliable multiplier. Gains depend heavily on your codebase, your test suite, and how much you already trust your pipeline.

If you’re interested in compound engineering, you might also want to read:

Compound Engineering v3 and the Rise of Agentic Software Delivery — What changed in the Compound Engineering plugin’s v3 release and why it matters for multi-agent work
Antfarm Patterns: Orchestrating Specialized Agent Teams for Compound Engineering — How multi-agent workflows using Antfarm turn compound engineering from theory into practice
Compound Engineering vs Traditional Software Engineering: Why Linear Teams Can’t Keep Up — A deep comparison of how compound engineering differs from traditional development teams
How the Ralph Loop Plays a Key Role in Compound Engineering — Understanding the Ralph Loop pattern and its synergy with compound engineering

From Vibe Coding to Compound Engineering

Through 2025, most of us got comfortable with AI in the editor. Claude Code, Cursor and Copilot became part of the daily routine, and the early gains were real. Boilerplate vanished, unfamiliar APIs stopped being scary, and first drafts arrived in seconds.

But it was mostly the same workflow, faster. We were still asking, “how do I write this code quicker?” And a lot of it was vibes: prompt, skim the output, hope it works, fix what breaks.

Compound engineering starts from a different question: what if writing the code is no longer the slow part? Once it isn’t, everything around the code becomes the constraint. How clearly did you specify the task? How fast can you tell whether it worked? Did anything you learned survive past this session?

Why “compound”? The analogy is compound interest. Each cycle leaves something behind, such as a test, a documented convention, or a note about a pitfall, and that makes the next cycle a little cheaper. It’s a slow effect at first. I’d be wary of anyone who promises a precise rate.

A rough way I think about it:

Useful output ≈ how fast you can generate × how fast you can verify × how often you iterate

It’s a mental model rather than a formula. But it explains why teams with identical AI tools get very different results: generation speed is now roughly equal, and verification is not.

The Mindset Shift for Engineers

From code writer to system designer

For many of us, being an engineer meant being the person who writes the code. That’s still part of the job, but you’ll likely write less of it yourself. More of your time goes to:

Building the feedback system. The tests, validation, and deployment pipeline that tell you quickly if something’s wrong.
Writing clear instructions. Specs and project guidelines that steer the AI toward the right answer.
Reading signals. Test failures, user feedback, and metrics, and deciding what to do about them.
Keeping the architecture coherent while changes arrive faster than you’re used to.

I’ll be honest that this isn’t comfortable for everyone. Some of the best engineers I know like the craft of writing code, and this shift takes some of that away. It’s worth being upfront about the trade.

From “get it right” to “find out quickly”

Traditional engineering culture leans on careful planning because mistakes were expensive. When regenerating a change takes minutes, some of that caution can relax. You can try something, see it fail, and try again.

I’d caution against taking this too far. Cheap to regenerate isn’t the same as cheap to be wrong. A subtle bug that reaches production, or a design decision that gets baked in across twenty files, is still expensive. The trick is to be relaxed only where your feedback loop is strong enough to catch problems.

From manual checking to automated guardrails

The old flow was: write code, click around, find bugs, fix them. The flow I aim for now is: write a spec, let the agent implement it, let the test suite and linters judge it, and feed failures back in.

That only works if you trust your checks. If your tests don’t catch real problems, automating around them just produces wrong code faster. Building that trust is most of the work.

The Feedback Loop Is the Bottleneck

When an agent can produce a feature in a minute, what determines how fast you actually ship? Mostly how quickly you can answer:

Did it build what I meant?
Does it work across the scenarios I care about?
Does it play well with the rest of the system?
Can I ship it without breaking things?
Did it solve the user’s problem?

If validating a change takes two hours, it barely matters that generating it took a minute.

Here’s how the stages tend to shift:

Stage	Traditional	With compound engineering
Code generation	Hours to days	Minutes
Validation	Manual review	Automated tests plus review
Integration testing	Before release	Continuous
Deployment	Manual steps	Automated pipeline
Rollback	Manual process	One-step revert
User feedback	Days to weeks	Depends on your release cadence

Note the last row. Some parts of the loop compress a lot, and some (like waiting for real users) don’t.

Making feedback fast

Tests first, where it makes sense. When the test exists before the implementation, the agent has something objective to aim at. This works well for well-defined logic:

describe('User authentication flow', () => {
  it('should authenticate valid credentials', async () => {
    const result = await authenticateUser('user@example.com', 'password');
    expect(result.authenticated).toBe(true);
    expect(result.token).toBeDefined();
  });

  it('should reject invalid credentials', async () => {
    const result = await authenticateUser('user@example.com', 'wrong');
    expect(result.authenticated).toBe(false);
  });
});

// Then: "Implement authenticateUser so these tests pass, and run them."

Fast, parallel tests. A test suite that takes twenty minutes will get skipped. Whatever you can run in parallel, do.

Gradual rollouts. Feature flags and canary releases shrink the time between “shipped” and “noticed a problem.”

Observability. Logs, metrics, and traces are how you learn whether AI-written code behaves in production, not just in tests.

Guardrails: Good Instructions Matter

The faster code gets generated, the more a vague instruction costs you. With a human colleague, ambiguity gets resolved in a hallway conversation. An agent will usually pick an interpretation and run with it, and you find out later.

What’s worked for me

Types as constraints. A strong type system narrows what the agent can produce. It’s a cheap way to rule out whole categories of wrong answers:

type UserRole = 'admin' | 'user' | 'guest';

interface AuthenticatedUser {
  id: string;
  email: string;
  role: UserRole;
  permissions: Permission[];
}

type AuthResult =
  | { success: true; user: AuthenticatedUser; token: string }
  | { success: false; error: AuthError };

Written-down acceptance criteria. Before asking for a feature, spend a few minutes writing what “done” means. Which cases must work? What should happen on failure? Even a short list improves results noticeably.

Reusable project context. Instead of re-explaining your stack every time, keep it in a file the agent reads (a CLAUDE.md or AGENTS.md, for example):

# Context
- Architecture: Next.js + PostgreSQL
- Auth: JWT in HTTP-only cookies
- Errors: never expose internals to clients

# When implementing a feature
- Follow the patterns in similar existing features
- Include TypeScript types and handle edge cases
- Run `npm run test`, `npm run typecheck` and `npm run lint` before finishing

This file is also where the “compound” step lives. When an agent makes a mistake and you correct it, add a line so it doesn’t happen again.

Always give the agent a way to check its work

If I had to pick one habit, it’s this. Compare:

"Implement user authentication"

with:

"Implement user authentication, then run the test suite and fix any failures"

The second version gives the agent a loop: generate, verify, refine, verify again. It’s a small change in wording and a big change in outcome.

Testing: The Critical Link

Unit tests tell you a component works. When AI writes a lot of code quickly, the more common failure isn’t a broken function, it’s pieces that individually work but don’t fit together, or a feature that does something slightly different from what you asked. That’s where integration and end-to-end tests earn their keep.

         /\
        /  \  E2E tests (critical user journeys)
       /    \
      /------\ Integration tests
     /        \
    /----------\ Unit tests

The pyramid still holds, but I’d lean a bit more on end-to-end coverage for your most important paths, and invest in making those tests fast enough that people actually run them.

A testing setup I’d aim for:

Fast unit tests that run constantly
Integration tests for the seams between modules
A small, reliable set of E2E tests for critical journeys
Type checking and linting on every change
Performance checks where speed matters, since AI-written code can be subtly inefficient

CI/CD does the heavy lifting

Your pipeline is what lets you trust agent-written changes. What I’d want from it:

Fast feedback, ideally minutes rather than tens of minutes
Easy rollback, via feature flags or blue-green deploys
Automatic checks: lint, types, security scanning
Visibility: dashboards and alerts that show when something’s off

If your CI is slow or flaky, fix that before adding more AI tooling. It will pay off either way.

Getting Started

You don’t need to adopt everything at once. This is the order I’d suggest.

1. Look at your current feedback loop

Time how long it takes to go from “I have an idea” to “it’s deployed and I know it works.” Find the slowest step. For most teams it’s either the test suite, code review, or deployment. Fix that first.

2. Get the basics of verification in place

Make sure your tests run quickly and reliably
Add type checking and linting to CI if you haven’t
Identify critical user journeys that lack end-to-end coverage
Start asking the agent to run tests as part of every task

3. Write down your conventions

Create a project instructions file (CLAUDE.md, AGENTS.md, or similar)
Document your architecture and patterns
Add rules when the agent gets something wrong

4. Close the loop

After each meaningful piece of work, ask: what did we learn that a future task should know? Capture it. That might be a note in your instructions file, a new test, a helper, or a short doc. This is the compounding step, and it’s easy to forget when you’re busy.

5. Keep tightening

Track things like how long changes take to ship and how often the same mistake recurs. If something keeps going wrong, that’s a missing guardrail.

Common Pitfalls

Optimizing for generation speed. It’s the most visible number and the least important one. Look at total time from idea to verified, shipped change.

Weak guardrails. Vague prompts, loose types, and no automated checks leave the agent guessing, and you’ll pay for it in review.

Too few end-to-end tests. Everything passes locally and the feature doesn’t work.

Manual review as the bottleneck. If the agent finishes in a minute and review takes two hours, the process needs more automation, or smaller changes.

Trusting plausible code. AI output often looks right. Keep verifying, and keep a human on the decisions that matter, especially security, data, and architecture.

Skipping the compound step. If you never write down what you learn, you’re just doing AI-assisted development. That’s perfectly fine, but it isn’t what this post is about.

What It Costs, and What You Get

The honest answer on speed is that it varies. Teams with good tests and a healthy CI pipeline can see large improvements, particularly on well-scoped work. Teams with slow builds, thin tests, or a tangled codebase will see much less until they fix those things. I haven’t seen a number I’d trust as a general rule, so I’d treat any headline multiplier with skepticism, including ones I’ve been tempted to write myself.

What does shift reliably is where the effort goes:

Less time typing out code
More time on tests, specs, and pipeline quality
More time reviewing and deciding, since the volume of change goes up

That’s an investment, and it pays back gradually. It’s also not free. Reviewing a lot of AI-generated code is real work, and it’s easy to underestimate.

Where This Is Heading

I’d rather offer a few tentative expectations than predictions.

Testing and verification tooling will likely get better at working with AI-generated code.
Specs and project context will keep becoming first-class artifacts, alongside the code.
Engineering roles will probably tilt toward design, review, and judgment, though what that looks like day to day will differ by team.
Simple architectures tend to work best with agents. Sprawling, tangled systems are hard on humans and agents alike.

None of this is settled, and I expect to revise my views as I see more real projects.

Key Takeaways

Compound engineering is about making each piece of work leave the next one easier, by capturing what you learn.
When code is cheap to generate, feedback speed becomes the bottleneck.
Guardrails (types, acceptance criteria, project instructions) usually beat clever prompting.
Always give the agent a way to verify its work.
Integration and end-to-end tests matter more when changes arrive quickly.
Start with your slowest feedback step, not with new tools.
Be skeptical of precise productivity claims. Measure your own.

Conclusion

AI made writing code faster. What separates teams now is what happens around the code: how quickly they can tell if it’s right, and whether they remember what they learned.

Compound engineering isn’t a tool you install. It’s a habit of investing in verification and in shared knowledge, so that each task leaves your project slightly easier to work on. It’s early, and I don’t think anyone has this fully figured out. But the underlying idea, that learning should accumulate instead of evaporating, seems like a sound bet.

If you try one thing this week, pick your slowest feedback step and make it faster.

Frequently Asked Questions

What is compound engineering in AI?

Compound engineering is a way of building software with AI agents where each completed task makes future tasks easier. Instead of treating every feature as a fresh start, you capture patterns, lessons, tests, and conventions so that your team and your agents begin the next task with more context. The approach was popularized by Dan Shipper and Kieran Klaassen at Every, built around a plan, work, assess, and compound loop.

What is the meaning of “compound” in compound engineering?

It’s borrowed from compound interest. Each cycle of work leaves something behind, such as a test, a documented rule, or a reusable pattern, and that makes the next cycle a bit cheaper. The effect builds gradually rather than immediately.

What are the steps of the compound engineering loop?

Four steps, repeated for every piece of work. Plan: the agent researches the codebase and writes a detailed implementation plan. Work: the agent carries out the plan step by step, running tests as it goes. Assess (called review in the plugin): you and review agents check the result with tests, linters, and security checks. Compound: you record what was learned as rules, tests, or notes in the repository so future tasks start from it. Skipping the fourth step is what turns this back into ordinary AI-assisted coding.

What does “compound AI” mean, and is it the same thing?

No. “Compound AI systems” is a separate, older term for AI applications built from several interacting components, such as models, retrievers, and tools, rather than a single model call. Compound engineering is about how you build software: it’s a development workflow. The two overlap in practice, since agent systems are often compound AI systems and are often built this way, but they answer different questions.

What is the Compound Engineering plugin for Claude Code?

It’s an open-source plugin from Every, maintained by Kieran Klaassen and Trevin Chow, that packages the loop as skills you can run inside your coding agent. The main commands cover brainstorming requirements (/ce-brainstorm), planning (/ce-plan), executing a plan (/ce-work), multi-agent review (/ce-code-review), and capturing what you learned (/ce-compound). In Claude Code you install it from the Every marketplace with /plugin marketplace add EveryInc/compound-engineering-plugin and then /plugin install compound-engineering. It also runs on other agent hosts, including Cursor and Codex. For what changed in the latest version, see Compound Engineering v3.

What are compound engineering skills?

Two things get called that. In the plugin, skills are the reusable commands above, such as planning and review. For people, the skills that matter are writing clear specs, building fast and trustworthy tests, reviewing AI-written changes critically, and recording lessons so they don’t get lost. The second set is what makes the first set work.

What is the difference between compound engineering and traditional software engineering?

In traditional development, effort per feature stays roughly constant, and much of what the team learns lives in people’s heads. Compound engineering leans on agents for implementation, automated checks for verification, and written-down knowledge that carries forward. It focuses on the whole path from idea to verified, shipped change rather than only on how quickly code gets written. There’s a longer comparison in Compound Engineering vs Traditional Software Engineering.

How does compound engineering work with AI?

AI agents do a large share of the implementation, but the approach depends on the system around them: fast automated tests to check the output, clear specs and project instructions to guide it, CI/CD to ship safely, and a habit of recording what was learned. The AI supplies speed. The surrounding system decides whether that speed is useful.

Is compound engineering just another name for AI coding?

Not quite. AI coding is about using AI to write code. Compound engineering is about the workflow around it: planning, verification, review, and capturing knowledge so it accumulates. You can do AI coding without any of that, and many people do. It’s a fine place to start, but you’ll hit a ceiling once verification and context become the limiting factors.

Do I need to be a large company to adopt compound engineering?

No. Small teams and solo developers often find it easier because there’s less process to change. The core practices (a fast test suite, a project instructions file, and a habit of capturing lessons) cost very little to start.

What tools do I need for compound engineering?

Very little to begin with: an AI coding tool such as Claude Code, Cursor, or GitHub Copilot, a test suite that runs quickly, and a CI pipeline. Everything else, including prompt templates, spec formats, and agent orchestration, can be added gradually. The most important asset is a fast, trustworthy feedback loop.

Does compound engineering work with Claude Code, Cursor, or Copilot?

Yes. The practices aren’t tied to a specific tool. Claude Code is what I use most, and its support for project instruction files, running commands, and iterating against tests fits the approach well. Cursor and Copilot can support the same habits, since what matters is that the agent has project context and a way to verify its work.

How do I start with compound engineering?

Start with your feedback loop. Time how long it takes to go from an idea to a verified, deployed change, then improve the slowest step, which is usually testing, review, or deployment. Next, add a project instructions file and make “run the tests and fix failures” a standard part of every task. Finally, after each piece of meaningful work, write down what you learned.

Won’t this lower code quality since code is generated faster?

It can if you skip verification. Speed without checks just produces mistakes faster. Quality holds up when every change has to pass tests, type checks, and linting, and when humans review the decisions that matter. Done well, code can end up more thoroughly tested than before, but that comes from the checks, not from the AI.

How long does it take to transition?

It depends on where you’re starting. If your tests and CI are already solid, you can see benefits within a few weeks. If they aren’t, most of the early effort goes into improving them, which is worthwhile regardless. The compounding part builds over months, as your written knowledge and guardrails accumulate.