Разработка по спецификации против Vibe Coding: водопад?

Спецификации как источник истины или медленная церемония?

Содержимое страницы

Разработка, управляемая спецификациями, вошла в 2026 год как серьезный ответ разработчиков на дрейф, вызванный «вайб-кодингом» (импульсивным кодингом).

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

На практике пользователи Hacker News окрестили этот подход «Возвращением водопада».

У обеих сторон есть основания.

Разработка, управляемая спецификациями, против вайб-кодинга

Аргументы в пользу SDD в мире вайб-кодинга

Вайб-кодинг – практика написания свободного промпта и итерации над тем, что производит AI-агент – remarkably хорошо работает для небольших, исследовательских и временных задач. В первые шесть месяцев 2025 года это был доминирующий паттерн программирования с ИИ. Разработчики выпускали скрипты, прототипы и простые инструменты быстрее, чем когда-либо.

Затем проекты выросли. Многофайловые функции начали терять согласованность. Ограничения, установленные в первой сессии, забывались к третьей. Предположения о безопасности игнорировались. Архитектурные решения менялись посреди разработки фичи, потому что у агента не было устойчивой памяти о намерениях.

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

GitHub Spec Kit, Kiro, рабочие процессы Claude Code SDD и BMAD, а также другие инструменты сообщества, являются реализациями этой идеи. Инструментарий реален. Интерес реален. Отторжение тоже реально.

В чем хороша вайб-кодинг

Прежде чем отвергать вайб-кодинг, стоит точно определить, что он делает хорошо.

Исследовательские прототипы. Когда вы не уверены, что хотите построить, самый быстрый путь – создать нечто грубое и отреагировать на результат. SDD требует знания того, что нужно специфицировать. Если вы еще не знаете, спецификации преждевременны.

UI-эксперименты. Визуальную раскладку и ощущение взаимодействия трудно описать заранее. Вайб-кодинг позволяет быстро увидеть варианты, отбросить большинство из них и прийти к тому, что действительно правильно. Документ с требованиями здесь не поможет.

Временная автоматизация. Одноразовые скрипты, задачи по извлечению данных, помощники для миграции – им редко нужен документ с дизайном. Цена небольшой ошибки низка. Цена медленного, церемониального процесса реальна.

Быстрая обратная связь. Когда вам нужно быстро что-то узнать – работает ли этот API так, как я думаю? – вайб-кодинг сокращает цикл обучения до минут. SDD замедлил бы этот процесс без какой-либо пользы.

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

Где вайб-кодинг дает сбой

Вайб-кодинг предсказуемо деградирует по мере увеличения масштаба и ставки.

Изменения в нескольких файлах. Как только функция затрагивает пять и более файлов, окно контекста агента начинает терять инварианты. Без документа с дизайном каждый промпт должен заново устанавливать контекст, который был установлен и забыт в предыдущей сессии.

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

Забытые ограничения. «Только аутентифицированные пользователи могут инициировать это» – это предложение в документе требований. В сессии вайб-кодинга это то, что вы упомянули однажды в первой сессии, и агент не помнит об этом в четвертой сессии, когда пишет новый эндпоинт.

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

Передача задач в команде. Если вы создали это через итеративное промптирование, артефактом, который записывает, что было решено и почему, является… git log. Удачи с этим.

Что меняет разработка, управляемая спецификациями

SDD не претендует на устранение итераций. Хорошие версии SDD явно итеративны. То, что они меняют, – это место, где происходят итерации. Полное определение – включая то, как SDD отличается от TDD, BDD и формальных методов, – см. в Что такое разработка, управляемая спецификациями?

Вместо итераций над кодом и вывода намерений из диффов, вы итерируете над спецификацией, а затем реализуете. Спецификация становится артефактом, который записывает, что было решено, почему и что находится вне области применения – выполняя функцию, аналогичную Записям архитектурных решений но ориентированную на намерения функции, а не на системные решения. Код реализует это намерение.

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

Почему разработчики называют это водопадом

Критика в стиле водопада не ошибается. Она просто направлена на плохой SDD, а не на сам SDD.

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

Когда разработчик использует Spec Kit и генерирует список задач на 200 строк, прежде чем написать одну строку кода, а затем проводит два дня, полируя документ с требованиями, прежде чем агент коснется чего-либо, – это водопад. Это водопад с использованием markdown вместо UML, но режим отказа идентичен.

Один комментатор на HN описал использование Spec Kit для небольшого CLI-инструмента и назвал его «слишком медленным, слишком много настройки перед тем, как увидеть код». Это плохая версия. Пользователь был прав, отвергая это для этой задачи.

Полезная критика не в том, что «спефикации плохи». Она в том, что «длительное планирование на старте до получения обратной связи – плохо». Это разные утверждения.

Полезная золотая середина

Хороший SDD избегает ловушки водопада, сохраняя спецификации небольшими и начиная реализацию рано.

Маленькие спецификации. Документ требований для одной функции должен помещаться на одном экране. Если спецификация занимает десять страниц, это либо дизайн платформы, либо ее нужно разбить на меньшие функции. Слишком большие спецификации занимают слишком много времени на проверку и быстро устаревают.

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

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

Живая спецификация. Когда реальность отличается от дизайна – а она будет – обновляйте спецификацию, а не только код. Спецификация полезна только тогда, когда она отражает то, что было фактически построено.

Тесты как исполняемая обратная связь. Каждый критерий приемки должен соответствовать хотя бы одному тесту. Набор тестов – это машиночитаемая версия спецификации. Если в спецификации сказано «только аутентифицированные пользователи могут инициировать это», должен быть тест, который проверяет, что неаутентифицированные запросы отклоняются.

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

Когда SDD побеждает вайб-кодинг

Используйте SDD – даже облегченный SDD – когда цена ошибки реальна.

Рискованная бизнес-логика. Биллинг, разрешения, миграции данных, идемпотентность – любая логика, где неправильное поведение дорого или трудно обратимо. Вайб-кодинг оставляет такие требования неявными. SDD делает их явными и проверяемыми до реализации.

Изменения производственного API. Любое изменение контракта публичного или внутреннего API должно иметь документ с дизайном. Документ с дизайном – это то, что вы проверяете, прежде чем агент напишет код, который сломает вызывающие системы.

Рабочие процессы с несколькими агентами. Когда несколько агентов реализуют разные части функции, спецификация является общим источником истины. Без нее каждый агент оптимизирует локально, и части могут не подойти друг другу.

Передача задач в команде. Если другой разработчик или другой агент продолжит эту работу, спецификация – это артефакт передачи. Git log и README недостаточно.

Значительные рефакторинги. Рефакторинги, затрагивающие основные абстракции, требуют явного заявления о том, что должно остаться неизменным (поведение), и что разрешено менять (структуру). Без этого агент может нарушить контракты, которые, как вы думали, были сохранены.

Когда вайб-кодинг все еще лучше

SDD – это накладные расходы. Иногда накладные расходы того не стоят.

Быстрые скрипты. Скрипт на 50 строк для переименования файлов или трансформации JSON не нуждается в документе требований. Напишите промпт, проверьте вывод, выпускайте.

Эксперименты. Если вы изучаете, жизнеспособен ли подход – исследуете API, тестируете библиотеку, валидируете гипотезу, – вам нужна скорость, а не структура. Экспериментируйте сначала, специфицируйте, если эксперимент успешен.

UI-скетчи. Дизайн взаимодействия выигрывает от просмотра, а не от спецификации. Быстро постройте несколько грубых вариаций, отреагируйте на то, что видите, и специфицируйте только то, что вы действительно собираетесь выпускать.

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

Соло-прототипы. Если вы единственный человек, который когда-либо увидит этот код, и цель – обучение, а не производство, вайб-кодинг быстрее, и недостатки ограничены.

Простая рамка принятия решений

Практический вопрос не в том, «SDD или вайб-кодинг?». Вопрос в том, «сколько спецификации нужно мне для этой конкретной задачи?».

Используйте вайб-кодинг, когда:

  • Задача занимает меньше дня
  • Вы исследуете или учитесь
  • Артефакт одноразовый или с низкой ставкой
  • Вы единственный человек, который будет с этим работать
  • Скорость обратной связи важнее, чем корректность

Используйте облегченный SDD, когда:

  • Задача занимает два или более дней
  • Затрагиваются несколько файлов
  • Существуют явные требования безопасности или корректности
  • Другой человек или агент продолжит работу
  • Вам нужно написать тесты, соответствующие требованиям

Используйте полный SDD, когда:

  • Функция затрагивает публичный интерфейс или контракт данных
  • Участвуют несколько агентов или членов команды
  • Организация требует рецензии дизайна перед реализацией
  • Требуется соблюдение нормативных требований или аудит

Самая распространенная ошибка – применение полного SDD к задачам, которым нужен только облегченный SDD, и отсутствие спецификации вообще для задач, которым нужна хотя бы облегченная спецификация. На каком бы уровне вы ни остановились, спецификация остается полезной только тогда, когда что-то продолжает проверять ее против кода; Сохранение синхронизации спецификаций, тестов и кода в ИИ-разработке охватывает проверки прослеживаемости, которые ловят тихо устаревающую спецификацию.

Плохой SDD – это водопад с markdown. Хороший SDD – это контролируемая итерация с устойчивыми артефактами. Вайб-кодинг – правильный инструмент для правильных задач – и неправильный инструмент для неправильных. Знание разницы – это навык.

Полезные ссылки

Подписаться

Получайте новые материалы про системы, инфраструктуру и AI engineering.