The Plan Is the Product: What Spec-Driven Development Actually Changes

Two weeks ago I was on stage at Code with Claude in London. After my talk, a developer came up to me and said, "Everyone's talking about Spec Kit. I still don't get what's different." It's a fair question, because on the surface the answer sounds like 1998: write specifications before you code.

That isn't what's different.

What's different is that the specification is now executable context for a fleet of agents that will run dozens of times, against the same plan, with no memory of what they did last time. The spec isn't documentation about the product. The spec is the product. The code is downstream artifact, and it gets regenerated.

GitHub's Spec Kit crossed 90,000 stars in May 2026. That is faster growth than React in its first year. OpenSpec, Kiro, BMAD-METHOD, Intent — every meaningful coding-agent ecosystem now ships a spec-first workflow. This wasn't a coordinated movement. It happened because every team that scaled past one agent had the same problem and arrived at the same answer.

What broke when teams scaled past one agent

The early agentic coding pattern was "vibe-code with Claude in a chat window." It works fine for one developer, one session, one feature. It falls apart the moment you do any of these:

• Run the agent twice on the same problem and get two different architectures.

• Have a second engineer pick up the work and discover the agent's mental model was never written down.

• Re-run the agent six weeks later after the codebase changed and watch it confidently break something it built itself.

• Hand a task to an autonomous agent and find out at 6pm it spent the day rewriting your auth layer.

None of these are model problems. The model is fine. The model is, in fact, much better than it was 18 months ago. The problem is that the plan was implicit, lived in a conversation transcript, and disappeared when the session closed.

Spec-driven development is the operational answer to that. The plan is explicit. The plan is versioned. The plan is the artifact you review, the artifact agents read before every run, and the artifact you update when reality drifts. The code follows.

What a spec actually contains

The mistake I see most often is treating a spec as a requirements document. It isn't. A modern spec, in the Spec Kit and OpenSpec sense, has three layers:

1. The constitution. Non-negotiable principles. "We do not write code without tests." "All external APIs go through this auth adapter." "We deploy through this pipeline only." These are organizational decisions that should not be re-decided every sprint.

2. The spec itself. What we're building, why, who for, what success looks like. Resource models, user journeys, edge cases. This is the part that looks like 1998 — but it's written for agents, not just humans, which changes the texture. It is denser, more enumerative, less prose-y.

3. The plan. How we're going to build it. Architectural decisions, technology choices, sequencing. This is the layer that diverges between Spec Kit (greenfield, top-down) and OpenSpec (brownfield, delta-marker driven).

The plan layer is the one that most enterprise teams underestimate. It is where the trade-offs live, and it is the layer that agents need most because agents do not, by default, know about your organization's preferences, prior decisions, or the painful incident you had with a particular library in 2024.

Where Spec Kit and OpenSpec diverge

Spec Kit, from GitHub, is opinionated toward greenfield work. Three slash commands — /specify, /plan, /tasks — drive you through requirements, technical decisions, and implementation chunks. The Python Specify CLI scaffolds the whole structure. If you are starting a new service or product, this is the cleanest path.

OpenSpec, from Fission-AI, takes the opposite position: most software work is brownfield, and the spec layer needs to live alongside an existing codebase that does not know it is being specced. OpenSpec uses delta markers — ADDED, MODIFIED, REMOVED — that describe what changes relative to existing functionality. It runs a three-phase state machine (proposal, apply, archive) so that every change has a paper trail.

Both are right. Spec Kit is right that greenfield needs structure. OpenSpec is right that brownfield needs deltas. If your team is building one product, pick one. If your team is in twenty codebases of different ages, you will end up with both.

What this means for how you run engineering

The first time a team adopts spec-driven development, the most disorienting change is not the writing. It's where decision-making moves. Code reviews migrate up the stack to plan reviews. The interesting argument is no longer "should this be a for loop or a map" — the agent will do whichever the plan says. The interesting argument is at the plan layer, where you are deciding what to build and what trade-offs to accept.

This has three downstream consequences I want every leader I work with to think about:

• Senior engineers become more valuable, not less. Their judgement is the input the agent fleet runs on. If your seniors leave, the plan layer hollows out, and the agents start producing confident, plausible, wrong code.

• Junior engineers need different training. Reading and writing specs is now a job-critical skill. Reading other people's plans is now a job-critical skill. The agents are perfectly fine at writing the code. The humans need to be perfectly fine at constraining it.

• The artifact of work changes. What gets archived at the end of a project is not the code — that's regenerable. What gets archived is the plan and the constitution. That's your institutional memory.

What I'd do if I were starting today

If you're running an engineering team and you haven't adopted spec-driven yet, the cheapest path I know is:

1. Pick one squad. Not all of engineering. One squad doing greenfield work.

2. Use Spec Kit, end to end, for a four-week pilot. Run the slash commands. Don't shortcut.

3. At week four, do a retro on the plan layer, not the code. Did the plan capture the constraints that mattered? Where did agents drift from the plan?

4. If yes, extend to brownfield squads using OpenSpec. If no, you've learned what your constitution actually needs to say.

The teams I work with at Applied Futures who have gone through this find the same thing: the painful part is not the tooling. The painful part is realizing how many decisions were never written down, and now have to be.

The bigger pattern

This is the first piece in a 12-part series on where I think the field is heading over the next three months. The thread that runs through all of it is something I closed the London talk with: the bottleneck keeps migrating outward. First it was prompts. Then contexts. Now harnesses. Soon meshes. Then governance and organization.

Spec-driven development is what happens when the bottleneck moves from prompts to contexts, then up to plans. The plan is the highest-leverage artifact in the system right now, because it's what the entire downstream agent fleet runs on. If you get the plan right, the rest cascades. If you get it wrong, no amount of model capability fixes it.

That's why the Spec Kit star chart looks like it does. It's not a tool that won. It's a methodology that finally has a vocabulary.

Next week I'll go one layer deeper — into context engineering and the new memory platforms (Mem0, Honcho, OpenViking, MemPalace, ByteRover) that are emerging as their own category.