Many spec-driven tools assume that the specification comes first and the code follows. In an existing system, the code came first. The AI Unified Process is designed for that.
/reverse-engineer reads code, configuration, schema, and tests and writes the use case diagram, one specification per use case, and the entity model. These are the same artifacts a new project starts with, so every later step works the same way.
When a use case changes, the agent reconciles the existing code with it. It doesn't throw the code away and generate it again. Your code, your conventions, and your history stay. Tools that generate the whole application from the specification can't do that.
/spec-review checks the specifications against each other. An old system has old gaps, so it records the findings that exist today as a baseline. From then on, only new problems fail the build.
A large codebase gets its artifacts split by module. You review and adopt the module you change next. There is no big-bang documentation project before the first change.
/stack reads the build files and the source tree and records the layers the project already has. The construction skills then follow it. No migration to a new framework is needed just to start.
Use cases in business language replace the knowledge that left with the people who built the system. /use-case-coverage shows where code and tests have drifted from the specification.
Both paths start the same way: reverse-engineer what exists, and let the Requirements Engineer and the Software Engineer review the result together. After that they go different ways.
The system stays on its stack. A new feature, a change, or a bug always changes a use case first, and the AI Unified Process sorts it into a Bug or an Enhancement. The agent reconciles the code with the changed use case, writes the tests the specification asks for, and the coverage audit shows what is still open. The specification and the code never drift apart again.
The old system becomes the requirements source for the new one. Use cases describe behavior in business terms, not in code, so they don't depend on the old technology. /stack records the new layers, /use-case-implement and /use-case-test build them one use case at a time, and test cases and business processes define the journeys the new system has to pass. You move module by module instead of in one big rewrite.
Install the open-source plugins in your coding agent and open the repository you already have.
/reverse-engineer:
derive the use case diagram, the use case specifications, and the entity model from the code.
/spec-review:
check the specifications against each other and accept today's findings as the baseline.
/stack:
record the layers the project already has (or the new ones, if you modernize).
/next:
ask which command comes next. From here on, every change starts with a use case.
The Spring PetClinic showcase has two branches: start, right after reverse engineering, and main, with every use case implemented and guarded by tests. The whole brownfield path is one diff.
For us at WBS GRUPPE, the AI Unified Process is the ideal method for analyzing and evolving existing products in a structured way. With requirements and use cases consistently at the center, we stay in full control even in an established codebase. Particularly remarkable: thanks to the precise specifications, the subsequent implementation was surprisingly fast. A highly efficient framework for agile software development in the AI era.
I used AIUP for both a green-field and an existing brown-field project. Both worked, and both approaches were as efficient as they were fun to use. Moreover, for the first time in agentic engineering, it felt like control was given back to me, the developer: a feeling I had missed since leaving the AI-prompting phase and venturing into 'vibe-coding'. Because the aiup-vaadin-jooq tech stack was not feasible for my existing brown-field project, I contribute to AIUP by providing the aiup-angular-jpa plugin.
Yes. The specification comes first, and the tests come from the specification, not from the code. /use-case-test uses the use case as the oracle: a test that disagrees with the code stays failing instead of being bent to match. That is how an old system shows you where it doesn't do what the business expects.
No. A large codebase gets its artifacts split by module, and you review and adopt the module you change next. The baseline in /spec-review keeps the old findings from blocking the build while you work through the rest.
Yes. Reverse-engineer the old system, review the use cases, and record the new layers with /stack. The use cases describe behavior, not code, so they carry over to the new technology. /use-case-implement and /use-case-test then build the new system one use case at a time, and you can move module by module.
Workshops, consulting, and tailored rollouts. Book a call to talk through how the AI Unified Process fits your existing system: maintaining it, evolving it, or moving it to a new stack.