ИИ-агент может за час собрать интерфейс, подключить базу данных и показать прототип. Но в действующем сервисе ему приходится учитывать десятки бизнес-правил. Если часть условий отсутствует в задаче, агент принимает решения самостоятельно, а их последствия обнаруживаются только после релиза.
В результате чем быстрее появляется код, тем дороже обходятся пробелы в требованиях. Spec-Driven Development решает эту проблему. SDD — это подход к разработке, где подробная спецификация является главным документом для человека и ИИ, заменяя хаотичные промпты.
SDD предлагает заранее фиксировать поведение системы и ограничения, а затем проверять по ним результат. Разберём подход на одной задаче и посмотрим, что происходит с ней после релиза.
Почему короткого промпта хватает для демо, но не для релиза
Базовый пример — B2B-кабинет, через который клиенты оформляют заказы. Разработчик просит агента: «Добавь корзину, оформление заказа и интеграцию с ERP». Через пару часов готова первая версия: товары попадают в корзину, заказ создаётся, его статус виден пользователю.
На проверке выясняется, что агент взял цену из общего каталога, хотя для каждого клиента действуют свои договорные условия. Повторное нажатие кнопки создает второй заказ. А если ERP приняла заказ, но ответ потерялся из-за тайм-аута, кабинет сообщает об ошибке и предлагает повторить операцию. Так можно получить два заказа вместо одного.
Агент выполнил исходный запрос. Проблема возникла раньше: никто не определил, откуда брать цену, как обрабатывать повторное обращение и что делать, когда результат операции в ERP неизвестен. ИИ заполнил пробелы предположениями, которые оказались несовместимы с правилами бизнеса.
Ошибки можно исправить, но при следующем изменении возникнет новый вопрос: где искать основания принятых решений? Часть останется в коде, часть — в переписке и памяти разработчика. Восстановление контекста постепенно нивелирует выигрыш от быстрой генерации.
Что меняет Spec-Driven Development
В SDD команда фиксирует поведение функции, технические ограничения и критерии приемки. По ним агент планирует и выполняет задачи, а разработчик проверяет результат. Спецификация остается в проекте для следующих изменений.
Чем это отличается от обычного ТЗ? Актуальное и подробное ТЗ тоже может выполнять эту роль. В SDD спецификация непосредственно участвует в работе агента: связана с планом, задачами и проверками и остаётся доступной после завершения чата или смены разработчика.
Карточка в трекере может содержать краткую постановку задачи, CLAUDE.md — общие правила репозитория. Спецификация связывает их с поведением конкретной функции и границами допустимых решений.
Единого стандарта SDD пока нет. GitHub Spec Kit и Kiro предлагают собственные процессы. Для старта достаточно привычного ИИ-агента для разработки, Markdown-файлов и ревью — при условии, что документы действительно используются и обновляются.
От промпта к спецификации: разбираем оформление заказа
Чтобы исправить ошибки в нашем примере B2B-кабинета, команда уточняет правила: кто оформляет заказ, когда фиксируется цена, что происходит при повторном запросе и как узнать результат передачи в ERP.
Допустим, договорные цены уже рассчитывает отдельный сервис. Тогда в спецификации можно закрепить следующие условия:
- - Доступ. Оформлять заказ может пользователь с соответствующими правами, действующий от имени своего контрагента.
- - Цена. Перед подтверждением система повторно обращается к сервису договорных цен и сохраняет рассчитанную сумму в заказе.
- - Повторные запросы. Два обращения с одинаковым ключом идемпотентности и одинаковыми данными возвращают один заказ. Повторное использование ключа с другими данными вызывает ошибку.
- - Интеграция с ERP. Заказ сначала сохраняется внутри системы. Если ответ ERP потерян, его статус становится «Требуется сверка». До выяснения результата повторная отправка блокируется, если внешняя система не гарантирует безопасный повтор.
- - Приемка. Проверки охватывают права доступа, изменение цены, одновременные запросы и потерю ответа ERP.
Теперь требование «не создавать дубликаты» можно проверить тестом: два одновременных запроса с одним ключом должны создать одну запись. А условие про ERP заставляет выяснить, можно ли найти ранее принятый заказ по идентификатору и кто будет проводить сверку.
Агент может выявить пробелы и предложить варианты. Правила обработки заказов утверждают специалисты, отвечающие за бизнес-процесс и архитектуру. После этого можно переходить к техническому плану.
Как спецификация превращается в рабочий код
Агент изучает проект и предлагает, какие компоненты изменить. Если он планирует новый модуль расчета цен, инженер может вовремя указать на существующий сервис и остановить дублирование логики.
Затем работу делят на задачи: проверка прав, создание заказа, передача в ERP, отображение статуса. Агент пишет код, команда проверяет результат каждой части.
С тестами есть тонкость — если агент неверно понял требование, он способен повторить ошибку и в коде, и в собственных тестах. Тогда успешное прохождение проверок создаст ложное ощущение готовности. Поэтому критичные сценарии стоит согласовать заранее и проверять независимо от реализации, включая интеграционные тесты и ревью архитектурных решений.
Таким образом, команда может оценить предложенный способ решения до разработки, а затем проверить готовую функциональность по согласованным условиям.
Реальная проверка SDD начинается после релиза
Подготовка спецификации может увеличить срок первой задачи. Но её польза обязательно станет заметнее при следующих изменениях.
Допустим, через месяц заказчик вводит согласование заказов свыше определенной суммы. На первый взгляд, нужны кнопка и новый статус. Но раньше заказ отправлялся в ERP сразу после оформления. Теперь отправку нужно отложить до согласования, изменить права пользователей, уведомления и тесты.
Если прежние решения зафиксированы, команда уточняет спецификацию, а агент определяет затронутые компоненты. Уходит меньше времени на выяснение старых договоренностей, хотя реальный код всё равно нужно изучить.
Здесь появляется новая ответственность: спецификация должна отражать актуальное поведение системы. Иначе следующий агент получит устаревшие инструкции и внесет ошибки уже по ним. Поэтому изменение требований, тестов и кода проверяют совместно в одном пулл-реквесте.
Последующие изменения покажут, окупились ли первоначальные затраты на спецификацию.
Как проверить SDD в своей команде
Для пилота подойдет сервис с интеграциями и частыми изменениями бизнес-правил. Несколько завершенных задач дадут базу сравнения; следующие, сопоставимые по сложности, можно провести через SDD. Мелкие правки с низким риском лучше не включать: полный комплект документов им обычно не нужен.
Для новых задач команда согласует требования, технический план и критерии приемки. При сравнении учитываются затраты всех участников — от постановки до релиза — и расходы на модели.
Например, на спецификацию потратили четыре дополнительных часа, а первую реализацию ускорили на один. Пока результат отрицательный. При следующих изменениях выигрыш появится за счет меньших затрат на выяснение зависимостей и согласование.
Для оценки можно взять полное время до релиза, число возвратов на исправление, дефекты после выпуска и время погружения в уже реализованную функциональность. Если документов становится больше, а показатели не улучшаются, стоит пересмотреть глубину спецификаций или область применения SDD.
Код генерируется быстрее. Решения остаются дорогими
Выска вероятность, что через полгода никто в компании не вспомнит промпт, по которому агент добавил оформление заказа. Но разработчикам по-прежнему важно понимать, почему цена фиксируется перед подтверждением и как обрабатывается потерянный ответ ERP.
SDD сохраняет эти решения внутри проекта и ими могут пользоваться следующие разработчики и агенты, а их актуальность остается обязанностью команды.
По мере развития ИИ преимущество всё меньше зависит от скорости написания отдельных функций. Оно определяется тем, насколько уверенно команда способна изменять работающую систему, сохраняя контроль над её поведением. Именно на эту задачу нацелен Spec-Driven Development и он успешно её решает.
