AI-ассистенты пишут код быстро. Очень быстро. Но «быстро написать» ≠ «быстро сделать продукт». Если ИИ мгновенно генерирует код по непонятному ТЗ — вы получаете мгновенно неправильный код. Потом мгновенно переделываете. И снова.
Раньше узким местом было написание кода. Теперь узкое место — ясность того, ЧТО нужно написать. Spec-driven development — это ответ на эпоху AI-агентов.
Что такое spec-driven development
Подход, при котором:
- Спецификация — source of truth. Прежде чем писать код, фиксируем: что делаем, для кого, какие критерии приёмки, какие границы
- Код следует за спекой. ИИ (или человек) реализует то, что описано в спеке
- Изменения — через спеку. Нужно изменить поведение? Сначала меняем спеку, потом код
Thoughtworks включил spec-driven development в Technology Radar как emerging technique.
Анатомия хорошей спеки
- Контекст: Зачем это нужно? Какую проблему решаем?
- Критерии приёмки: Как понять, что сделано правильно?
- Границы: Что НЕ входит в scope?
- Примеры: Input → Output для типичных и граничных случаев
- Зависимости: От чего зависит? Что блокирует?
C4 для архитектуры
C4 model (Simon Brown) — способ описать архитектуру текстом и простыми диаграммами:
- Context — система в окружении (пользователи, внешние системы)
- Containers — основные «коробки» (веб-приложение, база, API)
- Components — внутренняя структура контейнера
- Code — классы и функции (только если нужна такая детализация)
Это не UML — это читаемые диаграммы, которые понимают и бизнес, и разработчики.
WIP-лимит на спеки: не начинайте новую, пока не закрыта текущая. Маленькие инкременты: спека на 1-2 дня работы, не на месяц. Разделение ролей: «редактор спеки» отдельно от «исполнителя».
Чем быстрее генерация кода — тем важнее качество спецификации. Spec-driven development: сначала ясность, потом скорость. Используйте C4 для архитектуры, маленькие инкременты для снижения риска.