An AI agent writes code fast. But it does not know what the system should do, and it does not know how the system must be built. The Unified Process has answered exactly these two questions for more than 25 years: with use cases for the what, and with an architecture for the how.
In this post, I focus on these two principles. First, I show what the Unified Process means by them. Then I show how the AI Unified Process supports use cases and architecture with AI, and why they matter more for AI agents than ever before.
The Unified Process in a Nutshell
The Unified Process is an iterative and incremental software development process. Ivar Jacobson, Grady Booch, and James Rumbaugh described it in 1999 in the book “The Unified Software Development Process”. The best-known variant is the Rational Unified Process (RUP). Other variants are OpenUP, the Agile Unified Process, and the Enterprise Unified Process.
Important: The Unified Process is not a fixed recipe. It is a framework that you adapt to your organization and your project.
Four principles shape it. The first three are already in the title of the book’s first chapter:
- Use-case driven: Use cases describe what the system must do for its users. They drive analysis, design, implementation, and test.
- Architecture-centric: A stable architecture is defined and validated early. It is the backbone for everything that follows.
- Iterative and incremental: The system grows in short iterations. Each iteration delivers working software.
- Risk-driven: The biggest risks are addressed first, not discovered at the end.
Phases and Disciplines
The Unified Process has two dimensions. Time runs through four phases. Across them run the disciplines, the work that is done. Each phase consists of one or more iterations and ends with a milestone.
| Phase | Goal | Milestone |
|---|---|---|
| Inception | Clarify vision, scope, and the most important use cases. Is the project worth it? | Lifecycle Objectives |
| Elaboration | Describe most use cases, define the architecture and validate it with a running skeleton, remove the big risks | Lifecycle Architecture |
| Construction | Build and test the system use case by use case | Initial Operational Capability |
| Transition | User acceptance, training, rollout to production | Product Release |
The disciplines are Business Modeling, Requirements, Analysis and Design, Implementation, Test, and Deployment. Supporting disciplines such as Configuration and Change Management, Project Management, and Environment complete the picture.
The key point: All disciplines run in all phases. Only the weight shifts. In Inception, Requirements dominates. In Construction, Implementation dominates. This is exactly what makes the Unified Process different from the waterfall.
Use cases and architecture are not a phase. They run through the whole project. That is why I take a closer look at them in the next sections.
Use-Case Driven: The Idea
A use case describes how an actor reaches a goal with the system. It tells the flow from the user’s point of view: the main success scenario, the alternative flows, and the rules that apply.
In the Unified Process, a use case is more than a requirement. It is the common thread through the whole project:
- Planning picks the use cases with the highest risk or value for each iteration.
- Analysis and design show in a use-case realization which parts of the system implement a use case.
- Tests check whether the scenarios of the use case work.
- User documentation describes the tasks a user performs with the system.
This keeps all work connected to a benefit for the user. The problem in practice was always the effort. Writing use cases, keeping them up to date, and connecting them to code and tests takes time. That is why many teams stopped maintaining them. I wrote more about modern use cases in Use-Case 2.0 and Use-Case 3.0.
Use Cases in the AI Unified Process
In the AI Unified Process, the use case is the unit of work. There are no tasks as an extra layer. I explain why in Spec-driven Development is not Task-driven AI. An agent gets a use case and implements it completely. AI takes over exactly the effort that was missing in the past.
Find and describe use cases. /requirements creates the requirements catalog with a glossary. /use-case-diagram derives actors and use cases from it, each with an ID like UC-001 and linked to its requirements. /use-case-spec writes the trigger, preconditions, postconditions, main success scenario, alternative flows, and business rules for each use case. The AI asks questions instead of filling gaps with assumptions.
Approve and review. A use case is only implemented when it has the status “Approved”. The business side makes this decision, not the AI. Before that, /spec-review checks the specification for contradictions, unclear terms, and requirements without a use case.
Implement and test. /use-case-implement implements the use case across all layers. The code carries markers with the use case ID and the business rule ID. I explain why this traceability matters in How and Why to Trace Use Cases and Tests. /use-case-test writes the tests. The specification is the oracle: A test that contradicts the code stays red. If the agent finds a gap, it does not invent anything. It writes an open question.
Prove coverage. /use-case-coverage shows for each step, flow, and rule whether code and tests exist. This is specification coverage, not line coverage. /test-case connects several use cases into an end-to-end journey.
Deliver. At the end, the use case is still the common thread. /acceptance-protocol creates the checklists for the acceptance test, /user-guide the user manual, and /release-notes the business release notes. All from the use cases, not from commit messages.
This makes real what the Unified Process always wanted: The use case drives planning, implementation, test, and documentation. And it stays up to date, because the code is not created without it.
Architecture-Centric: The Idea
In the Unified Process, the architecture is defined and validated early. This is the goal of Elaboration. At the end of this phase is the milestone “Lifecycle Architecture”: a running architecture that has removed the big technical risks.
This architecture is not created in a vacuum. It is developed and validated with the architecturally significant use cases. The non-functional requirements such as performance, security, and availability are added to this.
RUP describes the architecture with the 4+1 View Model by Philippe Kruchten. Four views show the system from different angles: logical, process, development, and physical. The “+1” are the scenarios, in other words the use cases. They connect the views and show that the architecture really meets the requirements. In A Paper from 1995 Describes How You Should Work with AI Agents, I show why this model fits AI agents so well.
Here too, the problem in practice was always the same. Architecture documents and code drift apart. After a few months, the document describes a system that no longer exists.
Architecture in the AI Unified Process
For an AI agent, architecture is not a document you read once. It gives the agent the guardrails it follows for every use case. In the AI Unified Process, I call this the harness (more in Harness Engineering). It consists of four parts.
Non-functional requirements and constraints. /requirements captures them in a measurable way, with IDs like NFR-003 or C-005. Important NFRs lead to their own tests, for example for security or performance.
Architecture decisions. /architecture-decision records every decision as an ADR: context, decision, consequences. Each ADR is linked to the NFRs and constraints it serves. The AI checks new ADRs against the existing ones and finds contradictions. This keeps the why of a decision traceable.
The stack. /stack describes the technical layers in one file: migration, persistence, service, API, UI, and end-to-end tests. For each layer, the file names the technology, for example Flyway, jOOQ, Spring Boot, and Vaadin, and which skill builds and tests it. The agents read this file before every implementation. I describe an example of such an architecture in An AI-Ready Architecture for Business Applications.
Quality gates. /spec-review runs in the CI pipeline and breaks the build when the specification is inconsistent. /use-case-coverage shows whether code and tests match the specification.
The AI Unified Process deliberately does not prescribe an architecture framework. Every company works differently. The stack file works next to arc42, C4, or the 4+1 View Model.
And just like in the Unified Process, the architecture is validated early. The first approved use cases are implemented as a walking skeleton through all layers. When this end-to-end slice works, the architecture is confirmed. Only then does the broad implementation start.
Through All Phases
The AI Unified Process takes over the four phases of the Unified Process and gives each phase the right AI skills. The specification lives as Markdown, PlantUML, and BPMN in the Git repository. This way, humans and AI agents work with the same documents.
Inception. AI turns the vision, meeting notes, and existing documents into a structured requirements catalog and a use case diagram. When several roles and use cases work together, /business-process models the business process in BPMN. Whatever is unclear goes into a central list with /open-questions. This is shift-left in practice.
Elaboration. In the age of AI, this is the most important phase. Here the specification is created from which the agents later build the code. Besides use cases, ADRs, and the stack, /entity-model creates the data model as an ER diagram with attributes and validations.
Construction. The agents implement and test one use case after the other. The humans check coverage and answer open questions.
Transition. The acceptance protocol, the user guide, and the release notes are created from the specification.
Across all phases. /next reads the state of the project and tells you which step comes next. The AI Unified Process Navigator plugin for IntelliJ and VS Code connects tests and specification with one click. And /spec-review runs as a quality gate in the CI pipeline.
How It Fits Together: What, Harness, How
Use cases and architecture are two sides of the same thing. The AI Unified Process separates them into three levels. The use cases describe the What. The architecture forms the Harness. The code is the How, and the agents write it.
The agents work autonomously. They are not guided step by step. That is why I see AI development as a workshop, not a factory. For this to work, the two upper levels must be good. If a use case is unclear, the agent builds the wrong thing. If the harness is weak, it builds the right thing in the wrong way.
That is why the work shifts. In the past, most of the effort went into the code. Today it goes into good use cases and a clear architecture. Exactly where the Unified Process always wanted it.
In the past, the specification was often a document that nobody read anymore once the code was there. With AI agents, this is different. The specification is the input for the agent. If it is bad, the code is bad too. That is why the work in Inception and Elaboration pays off today more than ever. Or, as I wrote before: Code Is No Longer the Bottleneck. Requirements Are.
The iterations also get shorter. An agent implements a use case in minutes instead of days. So the feedback from the business side comes much faster. This is exactly what the Unified Process wanted: early feedback and early risk reduction. That is why spec-driven development is not waterfall: Why Spec-Driven Development Can Be Iterative, Incremental, and Agile.
Conclusion
Use cases and architecture were always right in the Unified Process, but expensive. With AI, the math changes. AI helps to write and review use cases, keeps architecture decisions traceable, and connects both with code and tests. The AI Unified Process turns two old principles into a practical way of working with AI agents.
You can find more about the AI Unified Process and its skills at unifiedprocess.ai. An example project is on GitHub at ai-unified-process/petclinic.
Sources: Jacobson, Booch, Rumbaugh: The Unified Software Development Process, Addison-Wesley 1999 · Philippe Kruchten: The 4+1 View Model of Architecture, IEEE Software 1995 · Wikipedia: Unified Process · BA Wiki: Unified Process
