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

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

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

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

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

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

Обе стороны имеют свои доводы.

Spec-Driven Development versus Vibe Coding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критика «водопада» не ошибочна. Она просто нацелена на плохой SDD, а не на SDD как таковой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подписаться

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