Spec-driven development vs vibe coding: что меняется после прототипа
Spec-driven development и vibe coding — два режима разработки с AI, которые по-разному хранят намерение. В spec-driven development ожидаемое поведение зафиксировано в проверяемой спецификации и проходит через план, реализацию и валидацию. В vibe coding намерение развивается в диалоге с моделью, а результат оценивается через быстрый интерактивный цикл.
Оба режима могут дать полезный код. Главный вопрос — что должно пережить текущую сессию: только найденная идея или ещё и воспроизводимый контракт для следующего изменения.
Что такое vibe coding
Термин vibe coding предложил Андрей Карпаты в 2025 году, описывая работу, где разработчик принимает предложения модели, запускает результат, сообщает об ошибках и продолжает цикл, не разбирая каждую строку кода.
Это не синоним любой разработки с AI. Если инженер формулирует требования, читает diff, проверяет инварианты и отвечает за результат, AI остаётся инструментом реализации. Vibe coding начинается там, где основной контракт существует в разговоре и в ощущении «похоже, работает».
Такой режим полезен для исследования:
- проверить, возможна ли интеграция;
- собрать disposable prototype интерфейса;
- сравнить несколько способов обработки данных;
- сделать внутренний скрипт с ограниченным риском;
- обнаружить неизвестные до фиксации требований.
Его сила — короткая дистанция между гипотезой и наблюдаемым результатом.
Что такое spec-driven development
Spec-driven development — подход, в котором спецификация становится рабочим контрактом между намерением и реализацией. Она описывает наблюдаемое поведение, границы, ошибки и критерии приёмки до того, как агент выбирает конкретный код.
GitHub Spec Kit оформляет один из
вариантов процесса как Spec → Plan → Tasks → Implement. Каждый артефакт
сужает пространство решений: spec фиксирует что и зачем, plan — как это
встраивается в систему, tasks — в каком порядке менять код, а реализация
проверяется против исходного намерения.
SDD не требует заранее знать всё. Неизвестные превращаются в явные вопросы, решения попадают в plan, а обнаруженное во время реализации возвращается в спецификацию, если меняет ожидаемое поведение.
Где проходит граница после прототипа
Прототип отвечает: «может ли эта идея работать и как она ощущается?» Продуктовый релиз отвечает на другие вопросы:
- что происходит с ошибочным вводом;
- какие данные сохраняются и кто их видит;
- что будет при недоступности интеграции;
- какое поведение считается регрессией;
- как другой инженер продолжит работу;
- как безопасно откатить изменение.
Пока эти вопросы не важны, разговорный контекст может быть достаточным. Когда результат получает пользователей, данные, деньги или обязательство поддержки, неявное намерение становится риском. Переход к SDD нужен не потому, что прототип «плохой», а потому, что меняется стоимость неоднозначности.
Как меняется работа
1. Промпт превращается в контракт
В vibe coding запрос оптимизируется под ближайший результат: «добавь загрузку CSV и покажи график». В SDD фиксируется наблюдаемое поведение: допустимые форматы, размер и ошибки файла, правила парсинга, состояние пустых данных, доступность и критерии готовности.
2. Успешный запуск перестаёт быть единственной проверкой
Прототип можно принять после ручного сценария. Релиз требует тестов на контракт, статического анализа, review и production-сборки. Тест должен быть способен упасть при нарушении требования, иначе он не доказывает поведение.
3. Diff становится предметом ответственности
Скорость генерации не отменяет побочные изменения. SDD ограничивает touch points планом и требует объяснить отклонение. Это снижает вероятность того, что агент вместе с фичей незаметно поменяет архитектуру или формат данных.
4. Решения переживают чат
Новая сессия агента не должна восстанавливать требования по коду и догадкам. Spec, ADR и проектные правила становятся внешней памятью. История разговора остаётся рабочим материалом, а не единственным источником истины.
Не waterfall и не BDD
SDD иногда ошибочно принимают за большое ТЗ, написанное до первой строки кода. От waterfall его отличает итеративность: контракт уточняется вместе с обнаруженными ограничениями, а изменение может идти небольшим вертикальным срезом.
BDD описывает поведение через примеры и сценарии; TDD начинает с исполняемого теста. Оба подхода могут быть частью SDD, но не заменяют всю систему. Spec связывает цель, границы и acceptance criteria; BDD/TDD дают способы проверить часть этого контракта.
Практичный гибрид
Рабочий процесс не обязан запрещать vibe coding. Его можно ограничить фазой исследования:
- Сформулировать гипотезу и допустимый риск.
- Собрать disposable prototype в отдельной ветке или каталоге.
- Записать, что стало известно: ограничения API, UX-решения, модель данных.
- Решить, какой код можно сохранить, а какой нужно выбросить.
- Перед продуктовой реализацией зафиксировать spec и критерии приёмки.
- Реализовать, доказать тестами и провести review против спецификации.
Это сохраняет скорость исследования, но не переносит его случайности в production.
Когда переход обязателен
Формальный контракт особенно нужен, если изменение затрагивает:
- аутентификацию, права и персональные данные;
- платежи, лимиты или необратимые операции;
- миграцию данных и совместимость;
- несколько систем или команд;
- публичный API;
- сценарий, который будет поддерживаться после передачи продукта.
Для одноразовой визуальной гипотезы spec может состоять из нескольких ясных критериев. Для критичного workflow он будет подробнее. Глубина зависит от цены ошибки, а не от моды на методологию.
Итог
Vibe coding оптимизирует исследование ближайшего результата. Spec-driven development оптимизирует воспроизводимость намерения, проверку и сопровождение. Первое уместно, когда код помогает узнать ответ; второе — когда код сам становится обязательством.
Если прототип уже доказал идею и пора определить границы первого релиза, опишите задачу. Можно разобрать пользовательский сценарий, неизвестные и критерии, которые должны стать контрактом до production.