The post has been translated automatically. Original language: Russian
This is the first post in a series about Spec-Driven Development. In the second section, we will analyze the steps and an example in practice. In the third section, we'll talk about the pros, cons, and limits of applicability.
With the advent of AI assistants for programming, code began to appear faster than we have time to comprehend it. A typical situation is when we formulate a task in one line of an outline, get an externally working result, and a week later it turns out that it does not take into account half of the requirements. One of the answers to this problem was the Spec-Driven Development (SDD) approach.
What is SDD?
Spec-Driven Development, or specification-based development, is an approach in which a detailed structured specification, rather than code, becomes the main artifact of a project. First, the team describes what the system should do and why, and only then proceeds to how to implement it.
The code in this model is secondary: it is derived from the specification and, if necessary, regenerated when requirements change.
How SDD differs from "just write a prompt"
| Vibe coding | SDD | |
| Starting point | Short request | Formalized specification |
| The Source of Truth | Code | Specification |
| The context for AI | Lost between sessions | Saved in documents |
| Result | Fast but unpredictable | Slower at the start, but reproducible |
How SDD differs from TDD and BDD
The approach does not arise from scratch, it has "neighbors":
- TDD (Test-Driven Development) starts with tests: first we write a test, then the code that passes it. The focus is on the correctness of individual code fragments.
- BDD (Behavior-Driven Development) describes the expected behavior of a system in scenarios that are understandable to both business and developers.
- SDD raises the level higher: the specification describes the purpose, scenarios, limitations, and acceptance criteria of an entire function. The plan, tasks, and tests are then derived from it.
The approaches do not exclude each other. BDD tests and scenarios can be part of the specification.
What is the SDD for?
- Reduce uncertainty. Discrepancies in understanding the task are identified before writing the code, not after.
- Give AI agents a qualitative context. The more precisely the task is described, the more predictable the generation result.
- Maintain knowledge about the project. The specification is in the repository and helps new participants to understand the system faster.
- Simplify the changes. The requirements have changed: we are updating the specification and revising the plan, rather than rewriting the code at random.
Result
SDD shifts the center of gravity from the code to the intention: first we agree on what we are building, and then we build. In the next post, we'll look at what the process consists of and what this specification looks like.
Это первый пост серии о Spec-Driven Development. Во втором разберём этапы и пример на практике. В третьем поговорим о плюсах, минусах и границах применимости.
С появлением AI-ассистентов для программирования код стал появляться быстрее, чем мы успеваем его осмыслить. Типичная ситуация: формулируем задачу в одной строке промпта, получаем внешне работающий результат, а через неделю выясняется, что он не учитывает половину требований. Одним из ответов на эту проблему стал подход Spec-Driven Development (SDD).
Что такое SDD
Spec-Driven Development, или разработка на основе спецификаций, это подход, при котором главным артефактом проекта становится подробная структурированная спецификация, а не код. Сначала команда описывает, что должна делать система и зачем, и только потом переходит к тому, как это реализовать.
Код в этой модели вторичен: он выводится из спецификации и при необходимости перегенерируется, когда требования меняются.
Чем SDD отличается от «просто написать промпт»
| Vibe coding | SDD | |
| Отправная точка | Короткий запрос | Формализованная спецификация |
| Источник истины | Код | Спецификация |
| Контекст для AI | Теряется между сессиями | Сохраняется в документах |
| Результат | Быстрый, но непредсказуемый | Медленнее на старте, но воспроизводимый |
Чем SDD отличается от TDD и BDD
Подход не возникает на пустом месте, у него есть «соседи»:
- TDD (Test-Driven Development) начинается с тестов: сначала пишем тест, потом код, который его проходит. Фокус на корректности отдельных фрагментов кода.
- BDD (Behavior-Driven Development) описывает ожидаемое поведение системы сценариями, понятными и бизнесу, и разработчикам.
- SDD поднимает уровень выше: спецификация описывает цель, сценарии, ограничения и критерии приёмки целой функции. Из неё затем выводятся и план, и задачи, и тесты.
Подходы не исключают друг друга. Тесты и сценарии BDD могут быть частью спецификации.
Для чего нужен SDD
- Снизить неопределённость. Расхождения в понимании задачи выявляются до написания кода, а не после.
- Дать AI-агентам качественный контекст. Чем точнее описана задача, тем предсказуемее результат генерации.
- Сохранить знания о проекте. Спецификация лежит в репозитории и помогает новым участникам быстрее разобраться в системе.
- Упростить изменения. Требования поменялись: обновляем спецификацию и пересматриваем план, а не переписываем код наугад.
Итог
SDD переносит центр тяжести с кода на намерение: сначала договориться о том, что мы строим, а затем уже строить. В следующем посте разберём, из каких этапов состоит процесс и как выглядит настоящая спецификация.
Share
