Code-centric development, typical spec-driven tools, and the AI Unified Process, side by side.
| Code-centric development | Typical spec-driven tools | AI Unified Process | |
|---|---|---|---|
| Source of truth | The code | The code; the spec is a prompt | The use cases (system behavior) |
| Who writes the spec | Nobody, or a document nobody updates | Developers | Business analysts and requirements engineers, AI drafts |
| Lifespan of the spec | Outdated after the first release | One feature, discarded after shipping | The life of the system, versioned in Git |
| Customer involvement | Requirements workshop, then acceptance | Rarely | Business review at the end of every iteration |
| Existing systems | Manual archaeology | Mostly new code | Brownfield workflow: reverse-engineer specs first |
| Changing the AI model or tool | Not applicable | Unpredictable | Safe: tests protect the specified behavior |
| Traceability | Manual, if at all | Per feature | Requirement → use case → code → test |
No. The process starts with a vision, business processes, requirements, and use cases written in plain language. Customers and end users validate them, business analysts and requirements engineers own them, and engineers generate and test the application from them. Stakeholders read and review the use cases as Markdown in the repository, or in AI Unified Studio in the browser without a repository checkout.
The project overview in AI Unified Studio →Use cases that describe what the system does, in their language, with generated diagrams and their current status. Every iteration ends with a business review of exactly those use cases, and acceptance tests follow them one by one. What was approved is what gets built, and what gets built is what gets tested.
The four phases and the business review →No. The AI Unified Process is iterative and incremental. Each short iteration ends with a business review, and specifications, code, and tests improve together. Specifications do not have to be complete up front: perfect specifications are impossible and unnecessary. What matters is that the current understanding is written down, reviewed, and kept in sync with the code.
Our iterative approach →The good parts of it, yes. It keeps the four phases, use cases, and short iterations of the Unified Process, and drops the artifact catalog, the role descriptions, and the ceremony. What makes it work today is that AI keeps specification, code, and tests consistent, which is the part the original process could only ask people to do by hand.
What was kept, dropped, and added →Yes. The AI Unified Process defines artifacts and how they flow into code and tests, not meetings. Iterations map onto sprints, the business review onto the sprint review, and use cases are a natural unit for the backlog.
AI drafts, people own. Commands generate the first version of requirements, entity model, use cases, and test cases; analysts review and refine them. The time goes where it pays off: clarifying behavior before the code exists instead of reworking code afterwards. Teams report that implementation becomes “surprisingly fast” once the specifications are precise.
Free guide: Writing Use Cases for AI →Those are coding agents, and the AI Unified Process runs inside them. Without a method, the agent works from prompts and the knowledge ends up in chat histories. With it, the agent works from versioned use cases: results are reviewable, reproducible, and traceable from requirement to test.
Most spec-driven tools are developer-centric: a developer writes a spec to describe the next piece of code, and the spec is effectively discarded once the code ships. In the AI Unified Process, the specification describes the behavior of the system, is owned by requirements engineering, validated by customers, and stays in the repository for the life of the system: spec-anchored, not spec-first.
The three levels of spec-driven development →No. The plugins are skill files that follow the open Agent Skills and Agent Plugins standards. They run in Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, and OpenCode, and can be installed with Tessl for any of them. The commands and the generated files are the same in every tool.
Use the plugins with other AI coding tools →Four stack plugins are ready to use: Vaadin with jOOQ, Angular with JPA, Blazor with .NET, and NestJS with Next.js. The core plugin is stack-independent, so any other stack works too: a stack plugin encodes your frameworks and architecture decisions, and your team can write one along the stack guide, or have it built together with the harness around it.
All plugins on the tools page → Create your own stack →Agent = model + harness. The harness is everything around the model: agent instructions such as AGENTS.md or CLAUDE.md, the architecture document, skills, documentation servers, tests, linters, and CI gates. Everyone uses the same models; the harness decides whether the generated code fits your architecture. Setting it up for your repository is offered as a service, together with a stack plugin for your stack.
Read: Harness Engineering and a good architecture document → Talk to us →Generated code arrives as a pull request and is reviewed like any other code. Tests derived from the use cases protect the behavior, a coverage check finds use cases without tests, a spec review lints the specifications and can gate the build, and the AI Unified Process Navigator traces every test back to its use case.
Traceability from spec to code and tests →In your own environment. All artifacts live in your Git repository. The plugins run in your coding agent's session, so you choose the agent and the model provider. AI Unified Studio triggers generation in the CI of your own repository, and the result arrives as a pull request. Your AI access token is stored only as a secret at your Git provider, never in the Studio.
How generation runs in your CI →Yes, and that is where it pays off most. The brownfield workflow reverse-engineers use cases, entity model, and test cases from the existing code first, so the specification catches up with reality. From then on, changes, new features, and bug fixes flow through the use cases, and functionality can move out of the legacy system step by step.
Greenfield vs. Brownfield →The agent plugins and the AI Unified Process Navigator are open source and free. AI Unified Studio is in private beta: access is by invitation, the free trial starts with the invitation, and pricing is announced at general availability. The book is sold by Apress; the guide is free. Workshops, coaching, stack plugins for your stack, harness engineering, and rollout support are offered on request.
Request a Studio invitation →Pick one application or one well-bounded area of an existing system as a pilot. A one-day hands-on workshop with your own domain gets the team to a use case catalog and a generated first iteration. From there, extend iteration by iteration.
The team workshop → Three ways to start →The AI Unified Process was created by Simon Martinelli, Java Champion, Vaadin Champion, and Oracle ACE Pro with more than 30 years of experience. He describes the method in full in his Apress book “Spec-Driven Development” and in the free guide “Writing Use Cases for AI”. The plugins are developed in the open on GitHub, and teams at companies such as WBS GRUPPE and centeractive use it in production work.
The book and the guide → About the author →Workshops, consulting, stack plugins, and harness engineering for your team. Or see the use cases of your own project in AI Unified Studio.
