User stories are popular in agile teams. They are short, readable, and focused on user value. For planning work, they can be very useful.

However, when the goal is Spec-driven Development, classic user stories are not enough. They push teams toward plans and task lists instead of stable, long-living specifications. This becomes a serious problem in AI-assisted development, where the specification must be precise and machine-readable.

The problem is not the idea of user stories. The problem is how and where they are used.

User stories describe work, not the system

A typical user story looks like this:

“As a user, I want X, so that Y.”

This sentence expresses intent, but it does not describe system behavior. There are no rules, no flows, no edge cases, and no constraints.

To make it actionable, teams always add more steps:

user story
→ refinement
→ plan
→ tasks

At this point, the story is no longer a specification. The real knowledge lives in plans, tasks, comments, or code. The story itself becomes a coordination artifact for developers.

Spec-driven Development needs something different. It needs artifacts that describe the system, not the work to build the system.

User stories are inherently plan-driven

User stories fit very well into sprint planning. They assume that work will be decomposed into tasks such as:

  • create endpoint

  • change database

  • implement service

These tasks describe how something is built. They are short-lived and tightly coupled to technology and team structure.

AI does not need this. AI needs stable input:

  • business rules

  • workflows

  • domain concepts

  • constraints

User stories only become useful after a planning and task step. This makes them execution-driven, not spec-driven.

User stories mix intent and solution

During refinement, user stories often accumulate acceptance criteria, technical notes, and solution ideas. Intent and implementation get mixed in one artifact.

This makes change expensive. When requirements change, the story, its tasks, and its technical notes all have to be rewritten.

Spec-driven Development avoids this by separating concerns:

  • Requirements describe intent

  • Use cases describe behavior

  • Models describe structure

User stories collapse all of this into one place, which looks simple but does not scale well.

User stories are developer-centric

Despite their name, user stories mainly serve developers and sprint planning:

  • Business stakeholders do not see full workflows

  • Testers do not get precise, testable behavior

  • Architects do not get stable system boundaries

Spec-driven Development needs shared artifacts that work for all roles, including AI tools. User stories rarely achieve this on their own.

Why use cases are a better fit

Use cases focus on system behavior. They describe how an actor interacts with the system step by step. They make flows, alternatives, and exceptions explicit.

Use cases provide:

  • clear behavior instead of vague intent

  • full workflows instead of fragments

  • testable scenarios

  • a natural bridge to automation and AI

Most importantly, use cases describe what the system does, not how the team plans to implement it. That makes them a strong foundation for Spec-driven Development.

AI Unified Process and the right place for user stories

The AI Unified Process (AIUP) at https://aiup.dev does not reject user stories. Instead, it puts them in the right place.

In AIUP, user stories live in the requirements catalog. There, they serve a clear purpose:

  • capture business intent

  • express user goals in simple language

  • provide traceable identifiers

At this level, user stories are not plans and not tasks. They answer why something is needed.

Behavior is then described using system use cases, and structure is captured in entity models. Together, these artifacts form the executable specification of AIUP.

This separation is crucial. User stories capture intent. Use cases define behavior. Models define structure. None of them require a planning or task step to be useful.

Specifications must survive change

Software changes constantly. Requirements evolve, regulations change, and domains grow.

In a spec-driven approach like AIUP, change starts in the specification. User stories in the requirements catalog may change, use cases are updated accordingly, and everything else follows.

With classic user stories used for sprint planning, the opposite happens. Stories are marked done, tasks change, code evolves, and the original intent is lost.

For AI-assisted development, this is fatal. AI needs a reliable, living specification. That cannot be built on completed sprint stories.

Conclusion

User stories are useful for capturing intent. They are useful for planning work. But they are not sufficient as the core artifact of Spec-driven Development.

Spec-driven Development needs precise, stable, and role-independent specifications. It needs artifacts that describe intent, behavior, and structure without relying on plans and tasks.

Use cases are a better fit for behavior. User stories still have value, but only when used correctly, as AIUP does, in the requirements catalog.

If specifications are meant to be the source of truth, they must describe the system, not the execution plan. Classic user stories push us toward tasks and plans. That is why they are not a good fit at the center of Spec-driven Development.