Spec-driven development: что это и как написать ТЗ, по которому построит AI-команда

Spec-driven development появился, когда команды заметили: AI-агенты отлично пишут код и ужасно угадывают, что вы имели в виду. В spec-driven development источником истины является короткая версионируемая спецификация, а код генерируют из нее AI-агенты, которыми управляют и которых проверяют старшие инженеры. Меняется продукт - сначала меняется спецификация, потом перегенерируется то, чего она коснулась. Именно поэтому AI-first команда сдает тот же объем вчетверо дешевле и вчетверо быстрее ручной разработки: споры происходят на одной странице до начала работы, а не на протяжении четырех месяцев переписываний.

Мы ведем так каждый проект с тех пор, как перешли на AI-пайплайн, поэтому ниже - то, что мы просим от клиентов, а не пересказ README какого-то инструмента.

Что такое spec-driven development (и чем он не является)

Определение, которое выдерживает проверку: спецификация декларирует намерение, код его реализует. Остальное - вопрос степени. Сообщество различает три уровня:

• Spec-first. Спецификация запускает первую генерацию, дальше код расходится с ней, а документ забывают. Дешево и почти ничего не стоит уже на второй неделе.
• Spec-anchored. Спецификация и код развиваются вместе, а автоматические тесты доказывают, что код до сих пор делает то, что написано. Здесь должны быть продакшен-системы, и здесь находимся мы.
• Spec-as-source. Люди редактируют только спецификацию и никогда не трогают сгенерированный код. Реально для эмуляторов и портов, но еще не для продуктов, которые встречаются с клиентами.

Это не возвращение к ТЗ на 80 страниц. Спецификация для MVP, по которой можно строить, - это две-пять страниц в репозитории, которые редактируют чаще, чем README. И это не инструмент. GitHub Spec Kit выпустил v1.0.0 21 августа 2026 года и в том же месяце перешагнул 132 000 звезд, у AWS есть Kiro, а Claude Code, Cursor и Codex имеют режимы планирования, но инструменты лишь закрепляют привычку. Thoughtworks именно поэтому держит spec-driven development в кольце Assess своего Technology Radar, и мы считаем это правильным: перенимайте дисциплину и не привязывайтесь к тулингу.

Почему spec-driven development выстрелил в 2026 году

Объясняют три цифры. JetBrains выяснил, что 90% профессиональных разработчиков пользовались AI-агентами для кода как минимум еженедельно в мае-июле 2026 года, а 68% - ежедневно. McKinsey сообщил, что почти треть организаций отказалась от покупки как минимум одного программного продукта, потому что смогла собрать его внутри с помощью агентов. А волна вайб-кодинга 2025 года оставила после себя поколение приложений, которые красиво выглядят на демо и падают на реальных пользователях; об этом мы писали в статье как довести приложение после вайб-кодинга до продакшена.

Сложите это вместе: софта генерируют больше, чем когда-либо, по промптам, которые никогда не были достаточно точными, чтобы с ними сверяться. Спецификация - и есть недостающий артефакт. Ранние пользователи сообщают о в несколько раз более высокой доле задач, которые агент закрывает с первой попытки, когда работает по спецификации, а не по треду чата; это цифры вендоров, но они совпадают с нашим пайплайном. Агент со спецификацией и тестом, который надо пройти, доводит задачу до конца. Агент с абзацем текста угадывает или слишком рано объявляет победу.

Неудобная часть в том, что спецификация - человеческий документ. Клиенты не врут на discovery, но описывают продукт, который хотели бы уже иметь. В "MVP" шесть интеграций и собственный дашборд. Спецификация - это место, где на них давят, пока несколько не отпадут.

Как написать ТЗ, по которому может строить AI-агент (или агентство)

Семь частей, именно в таком порядке. Если части не хватает, агент заполнит ее статистически самым вероятным ответом, и это редко будет ваш бизнес.

1. Одна работа. Одно предложение: кто что делает и что для него меняется. Если нужно "и", это два продукта.
2. Пользователи и роли. Каждая роль и для каждой - что она видит и что может менять. Этот раздел предотвращает самый дорогой класс багов, когда один пользователь читает данные другого. В Pulzio правило зафиксировали до того, как появилась схема: анонимность живет в модели данных, а не в текстах интерфейса, так что ответы с первого дня хранили без связи с сотрудником, потому что такую гарантию невозможно добавить задним числом.
3. Основной сценарий, а потом его сбои. Опишите счастливый путь пронумерованными шагами. Дальше для каждого шага - что будет, когда он сломается: банк отклонил платеж, вебхук пришел дважды, файл весит 400 МБ. Вайб-кодинг пропускает этот раздел, и продакшен находит его вместо вас.
4. Модель данных простыми словами. Сущности, как они связаны, какие поля никогда не могут быть пустыми. SQL не нужен. В Sanction Finder ключевым было одно требование: сопоставление имен не может быть ни точным совпадением строк, ни настолько свободным, чтобы завалить клиента ложными срабатываниями; это предложение определило весь слой поиска.
5. Критерии приемки, которые агент может проверить. Используйте форму события: КОГДА пользователь бронирует слот, который только что заняли, СИСТЕМА ДОЛЖНА отклонить бронирование и показать три следующих свободных слота. Каждый критерий становится тестом, который агент обязан пройти, прежде чем задача считается выполненной.
6. Что не делаем. То, что сознательно не входит в эту версию, записано, чтобы никто, ни человек, ни агент, не построил это "из лучших побуждений".
7. Определение "готово". Тесты зеленые, старший инженер просмотрел изменение, выкатано на staging, есть мониторинг. Агент доложит об успехе на коде, который не запускается; так вы перестаете верить ему на слово.

Спецификация из этих семи частей помещается на нескольких страницах, а основатель и старший инженер пишут ее за два-три дня, в основном над частями 2, 3 и 6.

Spec-driven development против вайб-кодинга и классического ТЗ

Из-за средней колонки многие основатели вздрагивают от слова "спецификация". Правая колонка - другое дело: она ближе к хорошо написанному тикету, чем к договору.

Что написанная спецификация меняет в стоимости и сроках

Это наши цифры. Они низкие, потому что спецификация убирает часы, которые традиционные проекты тратят на перестройку не того, и потому что код генерирует AI, а старшие инженеры управляют и проверяют. Традиционная ручная разработка обычно стоит вчетверо больше и длится вчетверо дольше на том же объеме.

Полные диапазоны по уровням есть в нашем разборе стоимости разработки MVP. Здесь главная - последняя строка: когда спецификация лежит в репозитории, изменение - это правка на страницу и перегенерация, а не новые переговоры.

Как мы работаем по spec-driven development в DForce

Первые дни проекта мы проводим как стресс-тест, а не как медовый месяц. Давим на must-have, пока несколько не отпадут, спрашиваем, что выйдет в релиз, если дашборда не будет, и спрашиваем, кто на самом деле пользователь, потому что основатель часто месяцами не разговаривал ни с одним. Результат - спецификация, и это первое, что мы отдаем.

Дальше AI-пайплайн генерирует код по спецификации, задача за задачей, а старшие инженеры отвечают за то, что дорого сделать неправильно: архитектуру, модель данных, авторизацию, платежи и все, что касается продакшен-данных. Каждый критерий приемки - тест, который агент должен пройти, потому что лучшее, что мы сделали для скорости своих агентов, - перестали верить им на слово. Спецификация обновляется с каждой фичей, так что следующий инженер, человек или агент, читает один актуальный документ вместо года чат-логов.

Частые вопросы

Что такое spec-driven development? Spec-driven development (SDD) - это подход к разработке, в котором источником истины является короткая версионируемая спецификация, а код генерируется из нее, обычно AI-агентами под руководством инженеров. Спецификация описывает пользователей и роли, основной сценарий и его сбои, модель данных, критерии приемки и то, что сознательно не делается. Когда требования меняются, сначала меняют спецификацию, а потом перегенерируют код, которого это касается. В 2026 году подход стал мейнстримом как лекарство от вайб-кодинга, где агенты писали правдоподобный код, который расходился с тем, что нужно продукту.

Это просто waterfall с AI? Нет. Спецификация в waterfall - документ, который написали один раз, подписали и забыли, пока код от него отдалялся. В spec-driven development спецификация короткая, лежит в репозитории рядом с кодом и редактируется каждый раз, когда меняется продукт, поэтому не успевает устареть. Ошибаться тоже значительно дешевле: неправильная спецификация стоит день и одну перегенерацию, а не квартал написанного вручную кода. Thoughtworks до сих пор держит SDD в кольце Assess, а не Adopt, и это честно: дисциплина важнее инструментов.

Нужно ли писать ТЗ до того, как нанимать команду разработки? Нужно знать ответы, а не писать документ. Хорошая команда пишет спецификацию вместе с вами на discovery и считает ее первым результатом работы: кто пользователи, какая одна работа продукта, что происходит, когда что-то ломается, и что сознательно не входит в эту версию. Прийти со списком фич - нормально. Прийти с подписанным списком фич, который никто не проверил на прочность, - так проекты теряют месяц на четвертой неделе.

Сколько длится и стоит спецификация? С AI-first командой discovery и написанная спецификация занимают 2-3 дня и стоят $375-1,125 (≈16 900-50 700 грн), которые засчитываются в стоимость разработки. Сама разработка дальше идет вчетверо дешевле и вчетверо быстрее, чем традиционная ручная, потому что AI-пайплайн генерирует код по спецификации, о которой инженеры уже поспорили, и на переделки уходит намного меньше часов. Простой MVP по спецификации стоит $1,500-3,750 (≈67 500-168 800 грн) и занимает 5-10 дней.

Если у вас есть идея продукта и список фич, который, как вы подозреваете, на самом деле список желаний, запишитесь на discovery-звонок, и мы за пять дней превратим его в спецификацию из семи частей с фиксированной ценой и датой.

Суммы в гривнах указаны по курсу НБУ на 22.10.2026 (1 $ = 45,03 грн).