Each phase runs short iterations where all disciplines work together, not in sequence. Phases overlap throughout the project lifecycle.
One diagram showing how the four phases interlock, from initial requirements through to production. Colors mark the phases: blue for Inception, green for Elaboration, red for Construction, orange for Transition.
The name is deliberate. The Unified Process of the late 1990s got the fundamentals right: use cases as first-class artifacts, four phases, short iterations, architecture first. What it never had was a way to keep specifications, code, and tests in sync once the project got moving. That is exactly what AI is good at.
The same methodology adapts to two realities, a clean slate, or an existing system you can't break.
The AI drafts use cases and an entity model from the requirements; the Requirements Engineer revises and owns them, and /spec-review checks the specifications against each other before any code is written. The AI agent then generates code and tests directly from those artifacts. The Software Engineer reviews the result; every artifact traces back to a requirement.
Start from the running system. The Software Engineer reverse-engineers the entity model, use case model, and specifications from the existing code. Software Engineer and Requirements Engineer then review those artifacts together, establishing the spec baseline that future iterations build on. /spec-review can record the findings that already exist as a baseline, so only new problems fail the build.
Use cases describe single goals. The business process shows how they fit together, and that is exactly what the end-to-end tests have to cover.
The business process is modeled in BPMN 2.0 and stored in the repository next to the other artifacts. Each activity corresponds to one use case: put the use case id in the activity name, for example "UC-009 Book visit", or it is matched to a use case by name.
Every path from the start event to an end event becomes one end-to-end test case. It chains the use cases of its activities in process order, and the lanes the path crosses become the test case's roles.
In a coding agent, /test-case docs/processes/order.bpmn derives the test cases. In AI Unified Studio, the process editor offers the same step with a Generate button, and the result arrives as a pull request.
Work rarely arrives as a brand new use case. It arrives as a feature request, a change, or a bug report, and all three are changes to a use case.
Adds a use case, or extends existing ones with new actors and new flows. The change ripples up into the requirements catalog, and a genuinely new capability may move the vision too.
Work item type: Enhancement.
Modifies a use case that already exists: a changed business rule, an extra field, a different alternative flow. The specification changes first, and everything downstream follows from it.
Work item type: Enhancement.
The specification and the code disagree. Usually the code is wrong. Sometimes the specification was wrong, or the test encoded the wrong expectation, and then the fix belongs in the spec.
Work item type: Bug.
Principles that ensure success in agile, iterative development.
Use cases are owned by requirements engineering and maintained for the life of the system, not prompts a developer writes and discards.
AI handles tedious work; humans focus on business logic.
Specs, code, and tests evolve together through short cycles.
Comprehensive tests ensure consistent behavior during AI regeneration.
Continuous validation with business users at every iteration.
Every line of code traces back to a business requirement.
Spec-driven development is not one thing. Everybody uses the term and everybody means something slightly different. The tools that carry the label sit at three very different levels, and the AI Unified Process is deliberately built for the second.
A specification is written before the code and handed to the AI agent as input. Once the feature ships, the specification has done its job and is dropped. Six months later nobody can say why the code looks the way it looks.
Lifespan: one change request. This is where most spec-driven tools sit today.
The specification stays in the repository and is updated with every change. It becomes documentation that is actually correct, because the agent reads it before it touches the code. That is what makes work on existing systems possible at all.
Lifespan: the life of the system. This is where the AI Unified Process sits.
The specification is the only artifact a human edits, and the code is generated from it every time. The most experimental of the three, and a familiar idea: model-driven development tried exactly this twenty years ago.
Lifespan: the specification is permanent, the code is disposable.
It's not about perfect specs, it's about iterative improvement.
Critics argue AI code generation only works with exhaustive specifications that force deterministic output. This assumes we need perfect requirements upfront.
Reality: Perfect specifications are impossible and unnecessary. The real value comes from iterative improvement.
Through short cycles, specifications become clearer, AI generation improves, and tests get stronger. Each iteration builds on the previous one.
Key insight: Tests ensure consistent behavior regardless of how the AI generates code. This enables safe evolution and modernization.
Workshops, consulting, and tailored rollouts of the AI Unified Process. Book a call to talk through how the AI Unified Process fits your stack and team.
