Spec-driven development is suddenly everywhere. Many AI tools claim to support it, and many teams say they are already doing it. But when I look closer, what I often see is something very different.

The typical flow looks like this:

requirements -> plan -> tasks

The requirements are quickly translated into a plan, and the plan is broken down into very concrete tasks. These tasks are then given to an AI agent with very detailed instructions. Step by step. Do this, then that.

This is not spec-driven development. It is task scripting.

Why task-driven AI is not a specification

Task-driven AI focuses on short-term productivity. The goal is to tell an AI exactly what to do so that it can generate code quickly. This can work surprisingly well for small features or throwaway prototypes.

The problem is sustainability.

A real specification describes intent, not steps. It explains what the system must do and why, without encoding the how in the form of instructions. Task lists do the opposite. They mix requirements, design decisions, and implementation details into one fragile artifact.

As soon as something changes, everything breaks.

If a requirement changes, the tasks must be rewritten.
If the architecture evolves, the tasks no longer fit.
If a new team member joins, there is nothing stable to learn from.

There is no shared understanding, only a sequence of commands that made sense at one point in time.

This approach is also strongly developer-centric. It optimizes for code generation, not for communication. Other roles in the project are effectively excluded.

Requirements engineers cannot validate intent.
Testers do not know what behavior really matters.
Product owners see tasks, not business value.

The result is fast output, but weak foundations.

What spec-driven development actually means

Spec-driven development starts from a different mindset.

The specification is the source of truth.
Code is a consequence, not the center.

A good specification captures three things:

Requirements that describe intent and constraints.
System use cases that describe observable behavior and flows.
An entity model that defines the domain concepts and language.

These artifacts are stable. They change slower than code. They are readable by humans, and precise enough for AI.

Most importantly, they are shared. Everyone in the project can read them, discuss them, and validate them.

This is what makes a system evolvable.

The AI Unified Process perspective

With the AI Unified Process (AIUP), I take this idea seriously and apply it to the entire development lifecycle.

AIUP is not about controlling AI agents with better prompts. It is about creating durable specifications that humans and AI can work with together.

Requirements, system use cases, and the entity model form an executable specification suite. They are stored as text and diagrams as code. They use stable identifiers. They are versioned. They are traceable.

AI plays an important role, but not as a task executor.

AI helps to:

  • refine and validate requirements

  • check consistency between use cases and entities

  • generate code, tests, and documentation from the spec

  • assess the impact of changes

Humans stay in control of intent and decisions.

This works for all roles involved in software development: requirements engineers, software engineers, testers, and product owners. Everyone works from the same source of truth.

But what about user stories?

AIUP does not reject user stories. It puts them in the right place.

User stories are useful for capturing needs and conversations. In AIUP, they live in the requirements catalog. They help express goals and context.

What they are not used for is planning AI tasks.

User stories are refined into system use cases and domain models. These become the real specification that drives implementation and automation.

This avoids the common mistake of treating user stories as executable instructions.

AI as a long-term accelerator

Task-driven AI feels powerful at first. You get results quickly. But the system becomes harder to change with every iteration.

Spec-driven development is slower at the beginning, but much faster over time.

When specifications come first:

  • changes start at the right level

  • impact becomes visible early

  • regeneration is possible

  • modernization is realistic

That is the difference between using AI as a productivity trick and using it as a long-term accelerator.

If you want AI to help you build systems that can evolve, you need more than tasks. You need specifications.

That is what AIUP is about.

Learn more at https://aiup.dev