«Просто опишите словами» не сработало: почему ИИ-разработка возвращается к спецификациям

Полтора года назад главным обещанием ИИ-разработки было «больше не нужно ничего расписывать — опиши словами, модель сделает». А теперь GitHub выпускает Spec Kit — инструмент, который заставляет сначала написать спецификацию, потом план, потом список задач, и только потом пускает ИИ-агента к коду. И это не одиночная причуда: у инструмента больше 30 интеграций с разными агентами и сотня расширений от сообщества.

Маятник качнулся обратно. Причём качнули его сами вендоры ИИ-инструментов — те, кто год назад продавал скорость «без лишней бюрократии».

Spec-Driven Development — методология, где спецификация становится источником правды, а не разовым промптом в чате. GitHub Spec Kit раскладывает её на четыре фазы: Spec → Plan → Tasks → Implement. Сначала вы описываете, что строите. Потом это превращается в технический план. Потом в список конкретных задач. И только на последнем шаге ИИ-агент пишет код — уже внутри заданных рамок.

Формулировка на сайте инструмента прямая: «вместо того чтобы вайб-кодить каждый кусок с нуля». То есть вендор открытым текстом противопоставляет свой продукт бесконтрольной генерации.

И это шире одного GitHub. Тот же принцип «сначала опиши, потом строй» появился у разных игроков — и в IDE со встроенным spec-first, и в методичках «как писать хорошую спеку для ИИ-агента». За полтора года индустрия прошла путь от «планирование мертво» до «планирование обязательно».

Я на это смотрю без злорадства, потому что сам работаю так давно. У меня в рабочем окружении есть правило: продуктовое описание — источник правды, и при любом изменении скоупа я правлю сначала его, а потом код, а не наоборот. Не из любви к документам: без этого ИИ-агент на большой задаче начинает тихо ломать ранее принятые решения.

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

Спеки не новость — они были всегда. Новое в другом: их вернули туда, откуда обещали убрать, и сделали это те же люди, что обещали.

Тут легко впасть в другую крайность и объявить спецификацию спасением. Не спасение.

На технических площадках уже разложили слабое место, и оно справедливое: spec-driven development структурно похож на waterfall — ту самую «водопадную» модель, от которой индустрия уходила двадцать лет. Проблема waterfall в том, что подробная спецификация запирает вас в одно решение: как только нужны быстрые изменения, спека и код начинают расходиться. Через несколько итераций они совпадают только на бумаге.

Второе слабое место: спека написана на человеческом языке, а он неоднозначен. Нет автоматического способа проверить, что поведение системы всё ещё соответствует тексту. Документ устаревает молча — за ним никто не следит, если это не встроено в процесс.

Отсюда вывод: спека, написанная раз и забытая, хуже, чем её отсутствие. Она создаёт ложное ощущение порядка.

Живая спека, а не мёртвая. Разница вот в чём: если что-то не сходится, вы правите не код, а описание — и запускаете агента заново. Спецификация становится точкой входа в контекст, которую обновляют при каждом значимом изменении. Тогда вы снова в гибкой разработке, просто с внятной опорой для модели.

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

Для бизнеса, который заказывает разработку, всё это сворачивается в один практичный сигнал. Если исполнитель начинает с внятного описания и плана до кода и держит их живыми — это нормальный процесс. Если вам продают «просто опишите словами, ИИ всё сделает» без спеки, без плана и без тестов — вам продают вайб-кодинг. Он выглядит быстрым ровно до того момента, когда что-то ломается и оказывается, что описания, по которому это чинить, никогда не существовало.

Спеки вернулись, и это правильный разворот — но с важной оговоркой. Планирование до кода не бюрократия и не откат назад, если спека живёт вместе с проектом и служит контекстом для агента. Тот, кто пишет спеку один раз и забывает, получает waterfall на новой скорости: код и описание разъезжаются так же, как двадцать лет назад, только быстрее.

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

Чем спека для ИИ отличается от привычного техзадания?
ТЗ обычно пишут один раз и подписывают. Спека для ИИ-разработки живёт вместе с проектом: её обновляют при каждом изменении, и она служит рабочим контекстом для агента, а не документом «для галочки». Мёртвое ТЗ здесь так же бесполезно, как его отсутствие.

Мне, нетехническому заказчику, это зачем знать?
Чтобы задать один вопрос исполнителю: с чего начинается работа — с описания и плана или сразу с кода. Ответ «ИИ сам разберётся по ходу» — сигнал, что вам, скорее всего, соберут прототип, который развалится на доработке.

Если вы заказывали или делали ИИ-разработку — у вас спека жила вместе с проектом или превращалась в мёртвый документ через месяц? Где именно она у вас разъезжалась с кодом? Интересен реальный опыт.

Разбираю такие рабочие моменты из своей практики в канале: @dmitra_ai.