Разработка по спецификациям против кодирования по настроению: водопад?

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

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

Спецификация-ориентированная разработка (Spec-Driven Development, SDD) вошла в 2026 год как серьезный ответ разработчиков на дрейф, характерный для вайб-кодинга.

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

На практике же в Hacker News это окрестили «Возвращением Водопада» (Waterfall Strikes Back).

Обе стороны имеют право на свою точку зрения.

Спецификация-ориентированная разработка против вайб-кодинга

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

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

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

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

Инструменты для AI-разработки – GitHub Spec Kit, Kiro, BMAD и растущий набор кастомных рабочих процессов Claude Code – все это воплощения этой идеи. Инструментарий реален. Интерес реален. И бэкланс (волна недовольства) тоже реален.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что меняет Спецификация-ориентированная разработка

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

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

Типичный рабочий процесс SDD проходит через пять фаз:

Спецификация. Описание проблемы, пользователи, цели, не-цели, критерии приемки, открытые вопросы.

Планирование. Архитектурные решения, затронутые модули, модель данных, контракты API, вопросы безопасности, стратегия тестирования.

Декомпозиция задач. Маленькие срезы реализации с явными критериями валидации и контрольными точками для человеческой рецензии.

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

Валидация. Тесты, линтинг, проверки типов, критерии приемки, дифф между спецификацией и кодом.

Агент участвует в большинстве фаз – черновик спецификации, генерация дизайна, предложение задач – но люди рецензируют артефакты перед началом реализации. Этот шаг рецензии – центральное различие между 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.