Superpowers vs Compound Engineering: is the 'vs' even real?

Igor Kramar — Mon, 04 May 2026 13:02:08 +0000

TL;DR — Superpowers and Compound Engineering aren't competitors. They're optimised for different worlds. Superpowers is gold for mature codebases with established methodology (TDD shops, large legacy systems, teams enforcing standards). Compound Engineering is gold for early-stage products where one person owns a feature end-to-end. Pick by what your codebase looks like, not by which README sounds shinier.

If you've spent any time in the Claude Code plugin ecosystem in the last few months, you've almost certainly heard about both:

Superpowers by Jesse Vincent — a "complete software development methodology" plugin, ~42k stars, in Anthropic's official marketplace.
Compound Engineering by Every — a 36-skill, 50-agent framework around the idea that "each unit of engineering work should make the next one easier", ~16k stars. Both ship as Claude Code plugins. Both wrap roughly the same surface — brainstorm, plan, work, review. Both have evangelists writing "I 100x'd my output" posts. So the natural question gets asked a lot: which one wins?

I installed both, ran them on the same projects for a few weeks (work — a Nuxt/Vue 3 platform product; personal — a small landing-page tool and my wife's florist site), and the answer turned out to be more interesting than I expected.

The "vs" is the wrong question. Let me show you why.

What both plugins are actually solving

Bare Claude Code is excellent at small tasks and dangerous at large ones. Without scaffolding it tends to:

Skip planning and start typing code on turn two.
Forget the lessons from yesterday's bug-hunt by tomorrow morning.
Drift further from your project's conventions the longer the session runs.
Treat each new request as if the codebase were a stranger. Both plugins exist to fix this — but they fix it from different ends. To see the difference, you have to look past the README marketing and ask what each one forces you to do.

The 90% overlap

Honestly: most of the surface is the same. Here's the side-by-side:

Phase	Superpowers	Compound Engineering
Refine a vague idea	`brainstorming`	`/ce-brainstorm`
Turn it into a plan	`writing-plans`	`/ce-plan`
Isolated execution	`using-git-worktrees`	`ce-worktree`
Code review before merge	`requesting-code-review`	`/ce-code-review`
Systematic debugging	`systematic-debugging`	`/ce-debug`

If you only look at this table, the conclusion is "they're the same plugin with different prefixes". That conclusion is wrong, and the difference is hidden in two places: what each plugin enforces, and what each one adds beyond the shared surface.

The real difference

Superpowers is a discipline-enforcement engine

Read the Superpowers source and you find it again and again: this plugin is opinionated, and the opinions have teeth. The clearest example is TDD:

If Claude tries to write code before tests, this skill literally makes it delete the code and start over. No exceptions.

That's not a tip. That's a guard rail. Other examples:

The brainstorming skill activates automatically when you describe a feature — you can't accidentally skip it.
systematic-debugging runs a 4-phase root-cause process and triggers a mandatory architectural review after three failed fix attempts.
YAGNI and "evidence over claims" are baked in as non-negotiables. Superpowers is, in Jesse Vincent's own framing, a methodology. It's there to make Claude behave the way a senior engineer at a disciplined shop would behave, whether you remember to ask or not.

The cost of this is real: Superpowers will fight you when you don't want to do TDD, when you want to vibe-code a quick spike, when you'd rather see something running before you write the test. That's not a bug. That's the entire point.

Compound Engineering is a knowledge-accumulation framework

Compound Engineering's central claim is in its name: each cycle should make the next cycle cheaper. The unique skills, the ones Superpowers has no real equivalent for, all serve that claim:

/ce-compound — after a feature ships, you write down what was learned. Bug patterns, gotchas, surprising decisions. These get indexed and pulled into the context of future plans.
/ce-compound-refresh — periodically reviews stored learnings and decides whether to keep, update, replace or archive them. Without this, your knowledge base drifts.
/ce-strategy — maintains a STRATEGY.md at the repo root: target problem, persona, key metrics, tracks. /ce-ideate, /ce-brainstorm and /ce-plan all read it as grounding.
/ce-product-pulse — time-windowed reports of what users actually experienced, saved to docs/pulse-reports/ so a timeline of outcomes builds up over time. Notice what's happening here: CE is reaching above the engineering loop (strategy) and below it (user outcomes), and tying both back into the planning context. It's trying to be a product loop, not just an engineering one.

The cost is also real: 36 skills and 50+ agents is a lot of surface. Without discipline you end up running ceremonial workflows on tasks that didn't need them. And /ce-compound only works if you actually use it after every cycle — skip it for two sprints and CE collapses into "Claude Code with extra slash commands".

Where each one breaks

This is the part most comparison posts skip, so let me be specific.

Superpowers breaks when your domain isn't TDD-shaped.

I tried Superpowers on a Nuxt/Vue 3 SSR feature where most of the work was prop-drilling, layout tweaks and Pinia state plumbing. The TDD-first enforcement turned a 90-minute change into a 3-hour session of writing tests for code that's mostly visual. For SSR-specific bugs (hydration mismatches, server-only state) the discipline pays for itself. For "make this card layout responsive", it's pure friction.

Superpowers also struggles with rapid iteration. Brainstorm-plan-test-implement is brilliant for a feature you'll ship to a million users. It's overkill for a 30-minute spike where the goal is to know whether an approach is even viable.

Compound Engineering breaks when you skip the compound step.

This is the trap. CE has so many slash commands that it feels productive even when you're just running /ce-plan and /ce-work on autopilot. But CE without /ce-compound is not compound engineering — it's just a more verbose Claude Code session. The plugin's value compounds only if you compound. I've watched myself skip it under deadline pressure on three consecutive cycles before I noticed the framework had quietly become decorative.

CE also breaks at team scale. The named-persona reviewers (ce-dhh-rails-reviewer, ce-kieran-typescript-reviewer) encode somebody else's taste. On a personal project that's fine — useful, even. On a team project, "the reviewer Claude is roleplaying as DHH" is not a conversation I want to have with a senior colleague at standup.

The shape that actually predicts which one fits

Here's the rule of thumb I landed on after two months of switching back and forth:

Your situation	Better fit
Mature codebase, established conventions, real test suite	Superpowers
Greenfield product, you own it end-to-end, conventions still forming	Compound Engineering
Team enforcing TDD or similar discipline	Superpowers
Solo dev or small team, knowledge dies if not written down	Compound Engineering
Legacy system where consistency matters more than novelty	Superpowers
Early-stage product where strategy shifts week to week	Compound Engineering
You want the plugin to constrain you	Superpowers
You want the plugin to remember for you	Compound Engineering

Or stated more bluntly: Superpowers is for codebases with a methodology to enforce. Compound Engineering is for products where the knowledge to compound is still being created.

A startup with a 6-month-old codebase and a single engineer per feature has very little to enforce — there are no conventions yet, the test suite is patchy, the architecture is in flux. What it desperately needs is a memory: why did we pick Pinia over Vuex, what broke last sprint, who is the persona we're optimising for. CE's /ce-strategy, /ce-product-pulse and /ce-compound are exactly that memory.

A 10-year-old enterprise codebase with 30 engineers has the opposite shape. The knowledge already exists — in the test suite, in code review norms, in the architectural decision records. What it needs is enforcement, because the failure mode is drift away from established standards under deadline pressure. Superpowers' "delete the code, write the test first, no exceptions" is precisely calibrated to that failure mode.

What I actually run, and where

For my work codebase (Nuxt/Vue 3, established team, real conventions), I lean on Superpowers — but selectively. brainstorming and writing-plans for any non-trivial feature; systematic-debugging for tricky SSR bugs; I let TDD enforcement run on backend Pinia store logic and turn it down on pure UI work.

For personal projects (the landing-page tool, the florist site), I run Compound Engineering. /ce-strategy once at the start gives every subsequent /ce-plan real context about what the product is for. /ce-compound after each meaningful feature actually compounds — I've already had /ce-plan surface a learning from a previous cycle that saved me an evening.

I don't run both in the same repo. They both touch CLAUDE.md, they both want to be the source of truth for how the agent behaves, and the conflict isn't worth it.

The honest version of "vs"

If someone asks "which plugin should I install?" — that's the wrong question. The right one is: what shape is the work?

Mature codebase, established discipline, the failure mode is drift → Superpowers.

Early product, single owner per feature, the failure mode is forgotten learnings → Compound Engineering.

The "vs" framing is what marketing produces when two tools are competing for the same star count. Engineering produces a different question: what fits this codebase, this team, this stage?

Try both. Run each on the project where its philosophy actually matches. You'll know within a week which one earned its place.

If you've run them both and your shape is different from mine, I'd genuinely like to hear it in the comments — especially the cases where I'm probably wrong.

DEV Community: Igor Kramar