Суть SDD умещается в одно предложение: сначала описываем поведение системы — ЧТО она должна делать, — а потом агент строит КАК. Это звучит банально, но нарушается постоянно.

Большинство команд работают иначе: открывают чат, пишут «сделай форму регистрации», смотрят на результат, правят, снова правят — и так по кругу. Это и есть vibe coding. Проблема не в том, что это «плохо» эстетически — проблема в том, что агент каждый раз угадывает намерение заново, и намерение нигде не зафиксировано.

SDD меняет порядок: сначала появляется спека — Markdown-документ с требованиями, ограничениями и критериями приёмки. Только после этого агент получает задачу. Спека — это не тикет в Jira и не комментарий в коде. Это источник истины, к которому возвращаются на каждом шаге.

Представьте, что .c-файл — это спека, а бинарник — это код. Вы не правите бинарник напрямую; вы меняете исходник и пересобираете. В SDD спека играет ту же роль: код — артефакт сборки. Изменился продукт → меняется спека → агент генерирует обновлённую реализацию. Это не метафора для красоты — это буквально меняет то, что считается «главным документом» в проекте.

flowchart LR
    A["/specify"] --> B["/plan"]
    B --> C["/tasks"]
    C --> D["/implement"]
    D -->|"требование изменилось"| A

GitHub Spec Kit реализует этот цикл четырьмя командами-слэшами:

/specify — агент задаёт уточняющие вопросы и помогает написать спеку: user stories, acceptance criteria, edge-кейсы. На выходе — spec.md.

/plan — агент читает спеку и предлагает архитектуру: какие модули создать, какие зависимости, что решить до написания кода. На выходе — plan.md.

/tasks — спека и план превращаются в конкретный список задач. Каждая задача привязана к конкретному требованию. На выходе — tasks.md.

/implement — агент берёт задачи по одной и пишет код. Он знает контекст (из спеки), архитектуру (из плана) и критерий «готово» (из задачи).

Вот как выглядит фрагмент spec.md для фичи «регистрация пользователя»:

## Требования

### FR-01 Регистрация через email
WHEN пользователь отправляет форму с email и паролем
THE SYSTEM SHALL создать учётную запись и отправить письмо с подтверждением.

**Acceptance criteria:**
- [ ] Дублирующийся email возвращает ошибку 409
- [ ] Пароль не менее 8 символов
- [ ] Письмо отправляется в течение 30 секунд

А вот фрагмент tasks.md, который из этого получается:

## Tasks

- [ ] Реализовать POST /auth/register (→ FR-01)
  - [ ] Валидация email-формата и уникальности
  - [ ] Хэширование пароля (bcrypt, cost=12)
  - [ ] Генерация и отправка письма-подтверждения

Обратите внимание: задача явно ссылается на FR-01. Если требование изменится — сразу видно, какие задачи нужно пересмотреть. Это не просто порядок — это трассируемость.

Vibe coding выглядит так: написали агенту «сделай форму регистрации», посмотрели на результат, добавили «и письмо с подтверждением», получили новый результат, снова поправили. Каждый промпт — отдельная мысль, агент реконструирует намерение из предыдущего кода плюс новый запрос.

При SDD вы один раз инвестируете в спеку — прописываете поведение, ограничения и edge-кейсы — и агент с первого захода имеет полный контекст. Меньше итераций, меньше «а я думал, вы хотели по-другому».

Важная оговорка: SDD не устраняет итерации полностью. Спека тоже эволюционирует. Разница в том, где происходит уточнение — до кодирования (в спеке) или после (в правках кода). Менять документ дешевле, чем рефакторить уже написанный код.

Термин «context engineering» шире, чем prompt engineering. Промпт — один запрос. Контекст — всё, что агент получает как вводные: предыдущие сообщения, файлы, история. Хороший контекст сужает пространство допустимых решений ещё до того, как агент начинает генерировать.

Спека — это именно такой refined context. Она не говорит агенту «напиши функцию авторизации» — она говорит: вот требования, вот ограничения (Redis для сессий, JWT с 15-минутным TTL), вот что значит «готово» (acceptance criteria). Агент перестаёт угадывать и начинает реализовывать.

Разрыв между «промптом» и «спекой» — это не про длину текста. Это про структуру: требования выделены, ограничения явные, критерии измеримы. Спека может быть совсем короткой — главное, что она снимает неоднозначность.

SDD — это смена порядка работы: сначала артикулируем ЧТО, потом строим КАК. Цикл /specify → /plan → /tasks → /implement даёт каждому следующему шагу структурированный артефакт от предыдущего. Спека не заменяет код — она его порождает. В следующем уроке разберём, чем SDD отличается от TDD, BDD и design docs — и почему они не конкуренты, а соседи по стеку.