"Specification first, code second" has become the mainstream of working with AI agents: OpenSpec, GitHub's Spec Kit and AWS's Kiro collect tens of thousands of stars. Use Case Pattern is also built around a specification — so we often hear "how is your spec different?" The difference is fundamental: they describe a change, we describe a system. Here is what that means in practice.
How spec-driven tools work
For all their differences, the three tools share one scheme. A specs folder appears in the repository; every change gets its own set of artifacts: why we're changing things (proposal), what exactly (requirements with "WHEN the user does X THEN the system responds Y" scenarios), how technically (design), and an implementation checklist (tasks). The agent implements against the checklist; after the merge, the change is archived. OpenSpec does this in a lightweight way and works with any AI tool; Spec Kit is stricter about phases; Kiro builds the same loop into its own IDE.
This is an honest improvement over vibe-coding: the agent gets agreed requirements instead of an oral retelling, and every change leaves a trail.
How the Use Case specification differs
The unit of description. For spec-driven tools the unit is a change: the spec lives from proposal to archive. For UCP the unit is a Bounded Context: the specification describes the whole domain — aggregates, their lifecycle, invariants, commands and events, acceptance criteria — and lives as long as the service does.
The language of description. WHEN/THEN scenarios capture observable behavior but say nothing about the model: you can't see from them that "order" is an aggregate with the invariant "line items sum to the total," or that "cancelled" is a terminal state. The UCP spec describes exactly that system of concepts — the thing from which both code and tests are then derived almost mechanically.
The link to code. Spec-driven tools end at "the agent implemented the checklist" — how the code is structured is up to the agent. In UCP the specification continues into architecture (the layered pattern, maturity levels) and into executable standards: review skills check every PR against coded rules.
| OpenSpec / Spec Kit / Kiro | Use Case Pattern | |
|---|---|---|
| Unit | a change | a Bounded Context |
| Artifact lifespan | until merge, then archive | together with the system |
| Content | behavior scenarios | domain: aggregates, invariants, events |
| Code architecture | up to the agent | fixed by the pattern |
| Verifying the result | checklist completed | rule-coded review on every PR |
What's worth borrowing from them
Honesty requires naming the spec-driven tools' strong point: the change delta as a first-class artifact. A long-lived specification answers "how the system works," but "what exactly are we changing this time and why" they format better — proposal, requirements diff, checklist, archive. That mechanic layers well on top of a UCP spec: a change is proposed as a delta to the Bounded Context, implemented, the specification is updated, the delta is archived. The second lesson is the light entry path: not every edit deserves the full ceremony.
In short
- OpenSpec, Spec Kit and Kiro specify a change: proposal → scenarios → design → tasks → archive; UCP specifies a system: a Bounded Context with a domain model, living with the service.
- WHEN/THEN scenarios describe behavior, not the model: aggregates, invariants and lifecycle can't be expressed in them — yet that is what code and tests derive from.
- Spec-driven tools end at checklist implementation; UCP continues into architecture and rule-coded review of every PR.
- Their strength is formatting the change delta; that mechanic is compatible with UCP and complements the long-lived spec.
- The choice: a change trail for the agent — any of the three tools; a source of truth about the domain and equally correct code — UCP.
What to read next
- The Use Case specification — the structure of a Bounded Context spec.
- UCP vs BMAD-METHOD — part one: process frameworks.
- The executable standard — what happens after the spec: rules and skills.