C² vs spec-driven development: specs that persist

Spec-driven development is one of the best ideas to come out of the agentic-coding wave. It says: stop prompting code into existence and start from a spec — a detailed, version-controlled description of what the system should do, with acceptance criteria you can run. It's a direct, correct answer to vibe coding.

C² agrees with almost all of it. The interesting question isn't C² versus spec-driven development — it's what SDD gets right, where it stops, and how C² extends it. Here's the honest map.

What spec-driven development gets right

SDD's core moves are sound, and C² shares them:

• Spec before code. Write down what to build, in detail, before generating anything. A clear target beats a vague prompt.
• The spec is the source of truth. It's version-controlled and authoritative — code derives from it, not the other way round.
• Runnable acceptance criteria. The strongest specs define done as something you can check. As the SDD guides put it, a criterion you can't run is an opinion, not a criterion.

This is genuinely good practice. If you take nothing else from SDD, take "write a checkable spec first." It's the cure for the agent that drifts into plausible nonsense.

Spec as source of truth, criteria you can run

The heart of SDD is making intent explicit and checkable. An executable spec, broken into atomic tasks, each with acceptance criteria the agent can verify. That's what lets agents work autonomously without drifting — they have a target they can test against, not a feeling to interpret.

C² runs on the same instinct. Its Prompt Brief is, in effect, a spec for a unit of work: what to build, what not to build, what to read first, and how you'll know it worked. The agreement here is near-total.

Where SDD stops

Here's the gap. Spec-driven development is centred on the spec — one unit of work at a time. Write the spec, build it, verify it, done. It's excellent at that.

But it has little to say about what carries between specs. The decision you made building feature one — does feature two's spec start knowing it? The gotcha you hit last week — does this week's spec author (you or the agent) start aware of it? In pure SDD, each spec tends to start fresh. The spec is the source of truth for this feature, but the project's accumulated knowledge isn't a first-class artifact the way the spec is.

Stuart Leo

A great spec builds one feature right. It doesn't, on its own, make the next feature start any smarter.

That's not a flaw — it's a scope choice. SDD nails the unit of work. It just stops at the edge of it.

C²: specs plus a compounding contextbase

C² keeps the spec discipline and adds the layer SDD leaves out: a contextbase that compounds across every spec.

• The brief carries the spec discipline — checkable criteria, build-this-not-that — for each unit of work.
• The contextbase carries everything that should persist between briefs: decisions, patterns, gotchas, session memory — committed to git, read before each new brief is written.

So in C², a new spec doesn't start from zero. It starts from everything the project has learned. The spec is sharp and the project is smart, and both get better the longer you run. SDD makes each feature right. C² makes each feature start ahead.

Side by side

How to choose or combine

• Reach for SDD's discipline whenever you build a real feature — write the checkable spec first, every time. It's the right habit.
• Reach for C² when you want that discipline and a project that gets sharper across features — when the knowledge between specs is worth keeping.
• Best of all, combine them. Run SDD-style specs as your C² briefs, with the contextbase compounding underneath. The specs stay rigorous — the project stops starting cold.

A great spec builds one feature right — a contextbase makes every next spec start ahead.

Start here: write acceptance criteria your agent can check, see how the methodologies compare, or read the method.