AI is changing how we build software. Code, tests, and even UI can be generated very fast. This is powerful, but it also exposes a big weakness in many projects.
AI does not understand intent by itself. AI only works well if the input is precise.
That is why system use cases are more relevant than ever.
In my projects, system use cases are the central artifact. They guide AI, keep code and intent in sync, and make change safe and predictable.
This article explains why system use cases fit so well in the age of AI, where they come from, and what makes a system use case executable.
The Core Problem with AI-Assisted Development
AI can generate code. AI cannot guess what you really mean.
If requirements are vague, the generated code will be vague. If behavior is implicit, AI will invent details.
User stories, tickets, and free-text descriptions are written for humans. They leave room for interpretation. That worked when humans wrote all the code. It does not work well when AI is part of the development process.
System use cases solve this problem by describing observable system behavior in a precise and structured way.
Where System Use Cases Come From
System use cases come from classic software engineering and requirements engineering. They focus on what the system does from the outside.
A system use case does not describe implementation details. It describes behavior that can be observed, tested, and validated.
System use cases can be created in different ways:
- Derived from structured requirements in a new project
- Refined from business processes and domain knowledge
- Extracted from an existing system during modernization
- Reconstructed from real user interactions
In modernization projects, this is especially important. Before changing code, I first extract system use cases from the running system. This makes hidden behavior explicit and creates a stable base for AI-assisted change.

Business Use Cases vs System Use Cases
Business use cases describe what the business wants.
System use cases describe how the system behaves.
Business use cases are useful for discussion and alignment.
System use cases are useful for implementation and automation.
AI needs system use cases, not business narratives.
What Makes a System Use Case Executable
Executable does not mean “running code”. Executable means that the use case can be used directly by tools and AI.
An executable system use case has clear structure and no ambiguity. It always includes:
- A clear trigger
- Explicit actors
- A structured main flow
- Explicit alternative and error flows
- Stable domain language
This structure removes guessing and enables automation.
Good Example: Executable System Use Case
The following example shows a good, executable system use case.
System Use Case: Register User
ID: UC-001
Primary Actor: Visitor
Supporting Actors: Email Service
Trigger: Visitor submits the registration form
Preconditions
The visitor is not authenticated.
Postconditions
A new user account exists with status pending verification.
A verification email is sent to the user.
Main Flow
- The visitor enters email address and password.
- The visitor submits the registration form.
- The system validates the input.
- The system creates a new user account.
- The system sends a verification email.
- The system confirms successful registration.
Alternative Flows
A1: Email address already exists
- In step 3, the system detects an existing account.
- The system rejects the registration.
- The system shows an error message.
A2: Invalid input
- In step 3, the system detects invalid input.
- The system rejects the registration.
- The system shows validation errors.
Why This Use Case Is Executable
This use case works well with AI because:
- The trigger is explicit
- Actors are clearly defined
- Each step describes observable behavior
- Validation and error handling are explicit
- Domain terms are consistent
From this single use case, AI can generate backend code, validation logic, persistence, UI behavior, and tests. When the use case changes, AI can update the existing code instead of regenerating everything.
Bad Example: Non-Executable Use Case
Now compare this with a bad example.
This kind of description is very common.
Use Case: User Registration
Users should be able to register easily.
The system must be secure and user friendly.
When a user signs up, the system checks the data and creates an account.
If something goes wrong, the user should get a helpful message.
After registration, the user receives an email.
Why This Use Case Is Not Executable
This description fails for AI-assisted development.
The trigger is unclear.
It is not defined when the use case starts.
Actors are missing.
It is not clear who interacts with the system.
The flow is unstructured.
There are no ordered steps and no clear system reactions.
Validation is vague.
“Checks the data” and “something goes wrong” are not observable behaviors.
Error handling is implicit.
There are no defined alternative flows.
The language is subjective.
Words like “easy”, “secure”, and “user friendly” cannot be translated into code or tests.
What Happens If AI Uses This
If AI gets this input:
- Code differs on every generation
- Validation rules are guessed
- Error handling is incomplete
- Tests are weak or missing
- Small changes cause large code diffs
AI is forced to invent behavior instead of implementing it.
What “Executable” Really Means in Practice
Executable system use cases act as a stable reference point.
From them, AI can:
- Generate code and tests
- Update existing code safely
- Keep behavior consistent across layers
Code is not regenerated blindly.
It is synchronized with the use case.
This is important because AI is not a compiler. Generated code is not identical every time. The use case keeps everything aligned.
Not Big Upfront Design
This approach is not about big upfront design.
System use cases are written incrementally:
- One use case
- One generation or update
- One review
- One change at a time
This fits perfectly with modern development and with how AI works best today.
Conclusion
In the age of AI, code is no longer the best place to describe system behavior.
Code is an outcome.
Executable system use cases provide precision, stability, and traceability. They work for humans and for AI. That is why system use cases are at the center of how I build software today.


