Spec-driven development (SDD)Why AI brought specifications back into development (Category Engineering)

The hot topic of spec-driven development seems to me a reincarnation of old bearded approaches. V-Model or RUPIn the area of the two thousandth were used to describe engineering processes. I was wondering why this happened and why this post came out:)

The old spec-driven approach was to first describe requirements, then design, then implementation, then verification. V-Model showed this symmetry well: each design level corresponds to its validation/verification level. The pros were in tracing from code requirements and verifiable expectations, and the cons were in bureaucracy and the gap between documents and code.

With AI, things have changed. The specification became a working interface between a human and an agent. If the code is written or the agent helps to write a lot, then the main question is not how quickly I will write the implementation with my hands. The main question is how accurately I can articulate intent, limitations, acceptance criteria, and how to verify the result. It's not enough for an agent to say "do a feature." It needs context: what needs to change, what doesn't have to break, what scenarios count as success, what tests to run, where are the limits of the task.

Therefore, modern spec-driven development looks something like this: intent -> acceptance criteria -> plan -> tasks -> implementation -> verification.

Documents now become executable context for the agent. Specta is used to make a plan, the plan is decomposed into tasks, tasks are delegated, tests and logs become proof of performance, and review checks not only diff, but also compliance with the original intention.

There are different approaches to this projectile

1️⃣ GitHub Spec Kit SDD is a process of first determining what to build, then letting the AI coding agent implement. There's a chain. spec -> plan -> tasks -> implementChecklists, clarify/analyze steps and integrations with different agents. The agent-agnostic idea is that the specification becomes a portable contract rather than a prompt for a single IDE.

2️⃣ Kiro from AWS It goes a similar way, but more productively. Their specs are usually decomposed into requirements.md, design.md, tasks.mdseparately there are steering files for constant knowledge about the project: architecture, stack, conventions, structure. This is very similar to trying to make AI coding a manageable feature or bugfix development process.

3️⃣ Codex approach harness engineering They show the third option. It's important. AGENTS.mdKnowledge of the repository, configured dev environment, tests, logs, PR review and the ability to run multiple tasks in parallel. In such a world, prompt begins to resemble a well-written GitHub issue: purpose, context, constraints, expected behavior, verification commands.

4There is also a lightweight variant that seems to be the most practical for many teams right now: PRD/RFC/issue + acceptance tests + CI + agent instructions. No separate framework. The main thing is that the task has a clear definition of done, and the agent can prove that he has achieved it.

In practice, there are several advantages. Less uncertainty - an agent works worst where the person has not decided what he wants Large tasks are easier to delegate – they can be cut into independent pieces and checked in parts There is a tracing between intention, solution design, tasks and tests. Review ceases to be just reading diff – it becomes a test: “Have we achieved the goal we set?”

Not everything is so cloudless - spec-driven development (SDD) It does not in itself guarantee quality. A weak specification simply produces the wrong code faster.

#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign