Spec-driven development is a popular term at the moment. Everybody uses it, and everybody means something slightly different. Birgitta Böckeler from Thoughtworks wrote a helpful article on martinfowler.com where she looked at tools that call themselves spec-driven. Her main finding: spec-driven development is not one thing. There are three levels.

In this post, I explain the three levels in simple words, place some popular tools on them, and then answer a question I get often: where does the AI Unified Process sit?

Level 1: Spec-first

You write a spec before you write code. The spec becomes the input for the AI coding agent. When the feature is done, the spec is not needed anymore. For the next change, you write a new spec.

Spec-first is already much better than writing a prompt and hoping for the best. But the spec is a throwaway artifact. Six months later, nobody knows why the code looks the way it looks.

Level 2: Spec-anchored

The spec stays in the repository after the feature is done. When the feature changes, you update the spec and the code together. The spec is the long-term reference for humans and for the AI.

This is the level where specs become documentation that is actually correct, because the agent reads it before every change. It is also the level where brownfield systems become possible. You can write specs for an existing system and anchor future changes to them.

Level 3: Spec-as-source

The spec is the only thing a human edits. The code is generated from the spec. Humans never touch the code.

This is the most radical idea. It is also the least proven. Böckeler compares it to model-driven development from twenty years ago. Back then, we wrote models in UML or a DSL and generated code with custom generators. It never took off for business applications. The abstraction level was awkward, and the constraints were too strict. Now the LLM replaces the generator. That removes the constraints, but it adds non-determinism. Generate the same spec twice and you get two different implementations.

Where are the tools?

Kiro and spec-kit are spec-first. Both create a spec, a design, and a task list per feature. Spec-kit even creates a new Git branch per spec, which shows that the spec lives as long as the change request, not as long as the feature.

BMad is a method with agent personas. An analyst writes a brief, a product manager writes a PRD, an architect writes an architecture document, and a scrum master cuts stories that a developer agent implements. The PRD and the architecture document stay in the repository, so there is a durable planning layer. But the unit of work is the story, and a story is consumed and done. In practice, BMad is a spec-first workflow with good planning documents on top.

OpenSpec is spec-anchored, and it is honest about it. There are two spaces: a specs folder that describes the current behavior of the system, and a changes folder where each change is a self-contained package with a proposal, a design, tasks, and delta specs. When the change is done, you archive it, and the delta is merged into the main specs. That is the right idea for brownfield work: describe the diff, not the whole world.

Where is the AI Unified Process?

Also at level 2: spec-anchored.

In the AI Unified Process, the requirements catalog, the use case diagram, the use case specifications, and the entity model are not throwaway prompts. They live in the repository, next to the code, for the whole life of the system. When a use case changes, you change the specification first. Then the agent changes the code. The tests are linked to the use cases with the @UseCase annotation, so you can navigate from spec to test to code and back.

The difference to OpenSpec is not the level, it is the content. OpenSpec gives you a lightweight structure for requirements and scenarios. The AI Unified Process brings the discipline of requirements engineering with it: actors, use cases with main and alternative flows, business rules, an entity model, and traceability from the requirement down to the test. This is what enterprise teams already know from RUP and Use-Case, now adapted for AI agents.

And it works on brownfield systems. Most enterprise work is not greenfield. You can reverse-engineer use cases and an entity model from an existing system, and from that moment on, every change is anchored to a spec.

But you never write code anymore. Isn’t that level 3?

I get this question a lot, because in practice I rarely type code myself anymore. The agent does it. So is this level 3?

No, and this is on purpose. Level 3 is not only “the human does not type code”. It has three parts:

  1. Humans never edit the code.
  2. The code is regenerated from the spec. Change the spec, run the build, get new code.
  3. The spec maps one to one to code files.

The AI Unified Process matches the first part in practice. It does not match the other two, and it should not:

The code is not regenerated. The agent evolves it. The existing code is input for the next change, not output of a build. That is the only way brownfield works. Nobody regenerates a fifteen-year-old ERP from a spec.

The specs are at use case level, not at file level. One use case maps to views, services, queries, migrations, and tests. This is the abstraction level business people and developers can talk about. A spec per file is a spec for developers only.

The code stays a first-class artifact. You review it. You can read it. You can change it if you want, and you should when it is faster. The tests link it back to the use cases. Nobody puts a “do not edit” comment on top.

You get most of the productivity of level 3 without depending on a non-deterministic compiler. And you keep something that level 3 gives up: a team that understands its own system.

Conclusion

Spec-first is a good start. Spec-anchored is where the value is over time. Spec-as-source is an interesting experiment, but for business applications in the enterprise, we have been there before with model-driven development, and the lesson was not “try harder”.

The AI Unified Process is a spec-anchored method. The specs are the source of truth for the requirements. The code is the source of truth for the implementation. Both are kept, both are linked, and both are owned by the team.

References