AI is changing software development quickly. Code generation is becoming cheaper and faster. With modern AI tools, writing code is often no longer the hardest part of building software.
The real challenge is something else: defining clearly what the system should do.
If the specification is vague, AI simply produces incorrect software faster.
Yesterday, at a meetup where I had a talk about Spec-Driven Development another speaker was talking about an applicaiton he made using the BMAD Method, a framework that tries to structure AI-assisted development. The idea is to replace chaotic prompting with a more disciplined process. Instead of using a single AI assistant, BMAD introduces multiple specialized AI agents that simulate a development team. One agent plays the role of an analyst, another acts as a product manager, another as an architect, and others focus on development or testing.
Each agent produces artifacts that are passed to the next stage of the workflow.
At first glance, this looks like a modern approach to AI-driven software development. But if you examine the structure more closely, it looks very familiar.
The BMAD process largely follows the classic product development flow:
Vision
→ Product Requirements Document
→ Architecture
→ User Stories
→ Implementation
The difference is that many of these artifacts are generated by AI agents.
The framework, therefore, focuses on organizing AI’s work.
But this raises an important question.
Is the real problem in AI-assisted development the lack of agent orchestration? Or is the problem something deeper?
The real bottleneck: specification clarity
Many teams experimenting with AI development discover the same issue. AI tools can generate large amounts of code very quickly. But they struggle when the description of the system behavior is vague.
User stories illustrate this problem well.
A typical story might say:
“As a user I want to upload a file so that I can share documents.”
For human teams this works reasonably well. Developers ask questions, product owners clarify missing details, and many assumptions are resolved during discussions.
AI does not work like that.
Large language models cannot easily infer missing information or challenge implicit assumptions. They rely entirely on the context they receive.
A typical user story rarely specifies important aspects of system behavior:
- the exact interaction steps
- validation rules
- alternative flows
- error handling
- state transitions
- system responses
Because of this, AI often generates code that is technically valid but does not match the intended behavior of the system.
Adding more AI agents or additional workflow steps does not eliminate this ambiguity. It simply moves the uncertainty from one artifact to another.
A specification-driven perspective
The AI Unified Process approaches this challenge from a different direction.
Instead of focusing on orchestrating AI agents, it focuses on creating precise specifications that become the foundation of development. AI is used to generate code, tests, and documentation, but the specification remains the central source of truth.
In this approach, the system is described through structured artifacts such as:
- functional requirements
- entity models
- system use cases
These artifacts form a coherent description of the system. When behavior changes, the specification changes first. Implementation, tests, and documentation follow.
This creates a stable relationship between the specification and the software.
AI works best in this environment because it receives clear and structured input.
System Use Cases as behavioral specifications
One important element of this approach is the System Use Case.
A system use case does not describe a vague goal. It describes how the system behaves step by step.
Example:
Actor: Customer
Main Flow
1 Customer opens order form
2 Customer enters order data
3 System validates the data
4 System creates the order
5 System confirms the order
Alternative Flow
3a Validation fails
System shows validation errors
This structure provides exactly the information AI needs:
- clear interaction steps
- explicit responsibilities
- defined alternative paths
- predictable system responses
From such a specification, AI can derive large parts of the implementation:
- backend logic
- user interface behavior
- tests
- validation rules
The specification becomes an executable description of the system rather than a vague requirement.
Two different strategies
When comparing BMAD and the AI Unified Process, the difference becomes clear.
BMAD structures the process around AI by introducing multiple agent roles and workflows.
The AI Unified Process structures the knowledge about the system through precise specifications that drive development.
Both approaches try to make AI-assisted development more predictable. But they address different aspects of the problem.
- BMAD focuses on organizing AI activity.
- The AI Unified Process focuses on improving the quality of the information given to AI.
In practice, the second problem often matters more.
The shift in software development
AI is not only accelerating coding. It is shifting the center of gravity in software development.
Implementation is becoming easier.
Specification is becoming more important.
Teams that continue to rely on vague requirements may generate code faster, but they will also generate incorrect behavior faster.
Teams that invest in clear behavioral specifications unlock the real potential of AI-assisted development.
There is another advantage that is often overlooked. Well-structured specifications are not only useful during implementation. They also become a durable description of the system itself.
Years later, when a system needs to be extended, migrated, or modernized, these specifications still explain how the system is supposed to behave. They provide a reliable reference that helps teams understand the intent of the software without having to reverse-engineer the code.
This makes specifications a sustainable asset. They survive technology changes, framework migrations, and architectural transformations.
The future of software engineering may therefore not depend primarily on better code generators.
It may depend on something much more fundamental: the ability to describe system behavior clearly and to preserve that knowledge in specifications that remain useful for decades.
