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. The AI Unified Process carries that legacy forward as use-case-driven development (UCDD) and architecture-centric development (ACD). What the original 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.
In the Unified Process, use cases drive every discipline: analysis, design, implementation, and testing. The AI Unified Process keeps that. A system use case is the unit the agent implements, the unit the tests are written against, and the unit the business reviews and accepts. Code that enforces a business rule carries a UC-XXX BR-YYY marker, and every test carries the id of its use case, so the use case stays the thread from the requirement to the running code.
In the Unified Process, the architecture is settled in Elaboration, before construction scales up, and every iteration builds on it. The AI Unified Process makes it explicit for the agent. The entity model, the stack file docs/architecture/stack.md, and the architecture decision records fix the layers, technologies, and conventions. The layer skills build every use case within them, and a deviation from an ADR is a question for a human, not a decision the agent takes alone.
Most projects start from a system that already runs and that you can't break. Some start from a clean slate. The same methodology covers both.
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. A large codebase is split by module, /stack detects the layers the project already has, and every later change reconciles the existing code with a changed use case instead of regenerating it. Maintain it or modernize it: the two paths →
The AI drafts use cases, business processes, and an entity model from the requirements, and first asks about what it cannot decide on its own; what nobody can answer yet goes into docs/open_questions.md until a product owner does; 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, within decision rights the team sets: what it decides alone, what it asks about first, and what it never does. The Software Engineer reviews the result; every artifact traces back to a requirement.
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, gets an id such as BP-001, and is stored in the repository next to the other artifacts. /business-process drafts it from the requirements and the use case diagram, with one lane per actor; business analysts refine it in any BPMN modeler. 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 BP-001 derives the test cases. In AI Unified Process Studio, the process editor offers the same step with a Generate button, and the result arrives as a pull request.
Use cases are normally disjoint: no step belongs to two use cases. A test case does not need use cases that overlap. The use cases are connected through data, because the postcondition of one use case fulfills the precondition of the next. An order created in one use case is the order approved in the next.
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 whenever AI changes the code.
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.
An agent that says “done” is making a claim. Guardrails make it prove that claim, in the build and in the session. The AI Unified Process PetClinic shows them working on a real application.
Architecture tests turn the architecture document into executable rules. Traceability tests connect requirements, use cases, business rules, test cases, and tests in both directions: a test that points at a renamed flow fails, and so does a use case that claims Status: Done while one of its alternative flows was never tested.
Key insight: The build catches drift, no matter who or what made the change.
Claude Code hooks hold the agent to the sensors. A Stop hook refuses to end the turn while changed code or specifications have not passed a fresh, green test run. A status guard refuses to set a use case to Done or Tested unless a coverage audit has finished first.
Key insight: Evidence is a test report or a finished audit, never console output that merely looks clean.
Status: lines, a Stop hook that requires green sensors, and a smoke test for the hooks themselves.
start, right after reverse engineering, and main, with every use case implemented, so the whole demo is one diff.
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.