One of the recurring questions I hear about Spec-Driven Development is this: where does the spec end and the implementation begin? The line is often blurry. Specs leak into class names. Implementation choices sneak into use case descriptions. After a few weeks, nobody can tell anymore what is intent and what is accident.
The AI Unified Process (AIUP) draws this line differently. Instead of two layers (spec and code), AIUP works with three: What, Harness, and How. The middle layer is where most of the leverage lives, and it is what makes AIUP different from other SDD approaches.
Let me walk you through each layer.
The What: Use Cases and Entity Model
The What is the problem space. It describes the system without saying anything about how the system is built.
Two artefacts live here:
Use cases describe behaviour. They follow Ivar Jacobson’s Use-Case 2.0 thinking: a use case is a slice of value that a user wants from the system. A use case has a goal, a main success scenario, alternative flows, and acceptance criteria. It is written in the language of the domain, not the language of the code.
The entity model describes structure. What are the business objects? What are their attributes? What are the invariants and relationships between them? Again, this is domain language. No tables, no columns, no JPA annotations.
Together, the What forms a complete picture of the problem. A domain expert or a business owner should be able to read it and say “yes, that is the system we want.” If they cannot, the What is not finished.
This is the same idea as classic requirements engineering. Nothing new so far. The interesting part starts with the next layer.
The How: The Implementation
Let me jump to the How first, because it is the layer most developers think about. The How is the actual code that runs in production: Spring Boot services, Vaadin views, jOOQ queries, REST endpoints, configuration files.
In a traditional project, developers write all of this by hand. In an AI-assisted project, much of it is generated. Either way, the How is the solution. It changes often. It depends on technology choices. It can be replaced without changing the What.
The question is: how do you make sure the How actually reflects the What? In small projects, you can rely on a good developer who has read the spec. In larger projects, or in AI-assisted projects, this does not scale. You need something in between.
That something is the Harness.
The Harness: Where the Architect Lives
The Harness is the bridge between the What and the How. It is the set of guardrails that shape every piece of implementation, whether it is written by a human or generated by AI. The Harness is the architect’s main deliverable.
The Harness has three parts:
Skills encode repeatable know-how. A skill might describe how to build a Vaadin view that follows the project’s layout conventions. Another skill might describe how to write a jOOQ query that respects the data access patterns. Another might describe how to write a Karibu test for a view. Skills are reusable. They are written once and applied many times. They are what make AI-generated code feel consistent across modules.
MCP servers give the AI access to the context and tools it needs. A jOOQ MCP server lets the AI inspect the actual database schema instead of guessing. A Karibu Testing MCP server lets it run tests. An Atlassian MCP server gives it access to the use cases stored in Confluence or Jira. Without MCP, the AI works blind. With MCP, it works with the same information a senior developer would have.
Guidelines set the rules. Naming conventions. Package structure. Test strategy. Which libraries to use and which to avoid. What goes into a service layer and what stays in a view. These are the rules a good codebase always has, but usually only in the heads of two or three senior developers. With AIUP, they are written down and applied automatically.
Together, skills, MCP servers, and guidelines form executable architecture. This is the part I find most interesting. In traditional projects, architecture often ends as a slide deck or a Confluence page nobody reads. In AIUP, the architecture is the Harness, and the Harness shapes every line of code the AI produces. If the architect changes a guideline, every future artefact reflects it. If a skill is improved, every future view built with it gets better. Architecture stops being documentation and becomes a live system.
The Diagram
Here is how the three layers fit together:
The What flows into the Harness. The Harness shapes the How. Traceability runs in both directions: every piece of code should map back to a use case, and every use case should be covered by tests that exercise the code.
Two Jobs of the Harness
The Harness does two things at once, and both matter.
It enables the AI. Skills tell it how to build things. MCP servers tell it what is there. Without enablement, the AI works from generic patterns and produces generic code. The result is correct in isolation but inconsistent with the rest of the project.
It also constrains the AI. Guidelines tell it what not to do. They prevent the AI from inventing a new package structure, picking a different test framework, or using a library the project does not want. Without constraint, every module looks different and the codebase drifts.
A Harness that only enables is permissive. It produces working code that does not fit. A Harness that only constrains is restrictive. It blocks the AI without helping it. A good Harness does both.
Why This Separation Matters
Three reasons.
Specs stay clean. When the architect owns the Harness, the spec can stay free of implementation details. There is no temptation to write “use a Vaadin Grid here” in a use case, because there is a proper place to capture that decision: the Harness.
Architecture becomes real. Instead of a deliverable that ends up in a drawer, architecture becomes a working part of the development environment. The architect’s value is measurable: better skills, better guidelines, better MCP integration lead directly to better code.
AI scales without chaos. In ad-hoc AI usage, every developer prompts differently and the codebase drifts. In AIUP, the Harness is shared. The AI behaves consistently because the guardrails are consistent.
What This Means for the Roles
The roles change too.
The requirements analyst owns the What. Use cases and entity model. No technology. Validated by domain experts.
The software architect owns the Harness. Skills, MCP servers, guidelines. This is now a hands-on role. An architect who only draws diagrams is not enough. An architect in AIUP writes skills, configures MCP servers, and maintains guidelines.
The software engineer works mostly in the How, but in a different way than before. Instead of writing every line by hand, the developer drives the AI through the Harness, reviews the result, and refines either the code or the Harness when something does not fit.
The test engineer sits across all three layers. Tests are derived from use cases (the What), run against the implementation (the How), and use the testing skills and MCP tools the architect provides (the Harness).
Closing Thought
Most SDD discussions stop at “separate the spec from the implementation.” That is correct but incomplete. The real question is what sits in between. AIUP answers it with the Harness: a layer of executable architecture that turns specs into code in a repeatable, controlled way.
If you are building business applications with AI assistance, the Harness is where I would invest first. The best use cases in the world will not save you if every developer prompts the AI differently. And the most powerful AI will not help you if it has no guardrails. Build the Harness, and both sides start working together.
If you want to learn how to apply this in practice with Spring Boot, Vaadin, and jOOQ, take a look at my Spec-Driven Development Workshop or visit unifiedprocess.ai.
