Most Code Already Exists
Spec-Driven Development works great when you start a new project. You write the specs first, and the AI agent implements them. But most of us don’t work on new projects. We work on systems that are five, ten or twenty years old. Often there are no specs at all, or the specs are outdated.
So the first question in many of my workshops is: How do we get specs for the code we already have?
The answer is reverse engineering. The AI agent reads the existing code and creates the specs from it. Then you review them, fix them, and from then on you can work spec-driven.
In this post, I show what the AI Unified Process offers for this, and how other spec-driven tools handle existing code.
The Reverse-Engineer Skill of the AI Unified Process
The AI Unified Process has a skill called /aiup-core:reverse-engineer. You run it in an existing project, and it creates three kinds of artifacts:
- A use case diagram in PlantUML with all actors and use cases of the system.
- One use case specification per use case with actors, preconditions, main success scenario, alternative flows, postconditions and business rules.
- An entity model with a Mermaid ER diagram and attribute tables with data types and validation rules.
The skill reads controllers, views, services and the database schema. From this, it derives what the users can do with the system and which data the system manages.
These are the same artifacts that you create in a new project with the AI Unified Process. So after the reverse engineering, there is no difference anymore between a new and an existing project. You use the same skills for the next steps: /aiup-core:spec-review to check the quality of the specs, and then the implementation and test skills.
Of course, the generated specs are only a first draft. The code shows what the system does, not why. Business rules that are hidden in the code need a review by people who know the domain.
What Other Spec-Driven Tools Do
I looked at the popular spec-driven tools and some community projects. All of them have some support for existing code, but they create very different results.
Kiro (AWS) has a feature called “Generate Steering Docs”. It analyzes the code and creates three files: product.md, tech.md and structure.md (Kiro blog). These files give the agent context about the product, the tech stack and the code structure. They are not specs of the features.
BMAD Method has the document-project workflow. It scans the project and documents the current state, for example architecture and modules. For smaller needs, there is generate-project-context, which captures conventions and patterns (BMad docs). The output is project documentation that later feeds the PRD.
GitHub Spec Kit does not do reverse engineering on its own. The official guide says that specify init does not infer specs for existing behavior. It recommends writing specs only for the changes you plan (Spec Kit guide). For reverse engineering, there are community extensions like Brownfield Bootstrap with /speckit.brownfield.migrate (PR #2145).
There are also smaller community tools:
- InferSpec creates OpenSpec specs, one per capability. It uses code, git history and docs, and links every requirement back to file and line. For gaps, it asks the user questions.
- StackShift is a Claude Code plugin with a six-step process. The output is for Spec Kit or BMAD.
- CoDD has
codd extract, which creates design documents from the source code. - spec-driven-dev has a
/retrofitcommand that goes through discovery, “archaeology”, gaps and finally specs.
| Tool | Command | What it creates |
|---|---|---|
| AI Unified Process | /aiup-core:reverse-engineer | Use case diagram, use case specs, entity model |
| Kiro | Generate Steering Docs | Product, tech and structure context files |
| BMAD Method | document-project | Project documentation (architecture, modules) |
| Spec Kit | Community extensions | Constitution and feature specs |
| InferSpec | /inferspec-scan | OpenSpec capability specs |
| CoDD | codd extract | Design documents |
Context for the Agent or Requirements for the Team?
When you look at the results, you see two different goals.
Most tools create context for the AI agent. Kiro’s steering files and BMAD’s project documentation tell the agent which framework is used, how the code is structured and which conventions to follow. This is useful, but it describes the technology, not the business.
Other tools create feature or capability specs. InferSpec and the Spec Kit extensions go further and describe behavior. But their format is specific to the tool, and they don’t model the data.
The AI Unified Process creates requirements that people can read and discuss. Use cases and entity models have been used in requirements engineering for decades. A business analyst, a product owner or a domain expert can review a use case specification without knowing the code. And the entity model shows the data, which is often the most valuable part of a business application.
This matters because reverse-engineered specs are never correct on the first try. Someone from the business must check them. If the specs are written for the agent, only developers can do this review. If the specs are use cases, the whole team can do it.
Conclusion
Reverse engineering is the door to Spec-Driven Development for existing systems. Many tools offer it, but they answer different questions. Kiro and BMAD help the agent understand the code. InferSpec and the Spec Kit extensions describe features in their own format.
The AI Unified Process creates use cases and an entity model. These are artifacts the whole team understands, and the same artifacts you use in a new project. So you can start with an existing system and continue with exactly the same process.
Try it on one of your projects and tell me what you think. You find the AI Unified Process at unifiedprocess.ai.
All information about the other tools is as of October 2026. These tools change fast, so please check their documentation for the current state.
