Vibe coding vs spec-driven: честный разбор без догматизма

Слово «vibe coding» стало ругательством в одних кругах и символом свободы — в других. Spec-driven development защищают как единственно правильный путь, а критикуют как бюрократию, которая замедляет работу. Истина, как обычно, скучнее: оба подхода нужны, оба работают — просто в разных ситуациях. Разберём честно, что это такое, в чём сила и слабость каждого, и как выбирать.

Что такое vibe coding

Термин появился в 2025 году и описывает способ работы с AI-агентами, который большинство разработчиков освоили интуитивно: вы даёте агенту задачу свободным текстом, смотрите на результат, правите промпт, смотрите снова. Итерируете «по ощущению» (vibe), пока не получится что-то близкое к нужному.

Как это выглядит в реальности:

«Сделай программу лояльности — клиенты копят бонусы и тратят их на заказы»

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

Vibe coding — это не плохой код. Это конкретный workflow, у которого есть своя применимость. И свои пределы.

Плюсы:

• Низкий порог входа: начинаете немедленно, без подготовки
• Хорошо работает для коротких задач с очевидным результатом
• Идеально для прототипа, который, скорее всего, выбросите
• Быстро показывает, работает ли идея вообще

Минусы:

• Цена каждой итерации растёт с размером задачи
• Агент галлюцинирует ровно там, где вы недосказали
• Нет артефактов: после работы — только код, без объяснения решений
• На командной работе каждый понимает задачу по-своему
• Накопленный технический долг становится невидимым

Что такое spec-driven development

Spec-driven — это инверсия vibe-coding: вы сначала письменно фиксируете, что должно получиться, и только потом отдаёте задачу агенту. Спецификация — не код, не задачи в Jira. Это документ, который однозначно отвечает на вопрос «что должно получиться и как мы поймём, что получилось».

Главный признак хорошей спеки: её нельзя понять двумя разными способами. Если два инженера прочитают её и реализуют по-разному — спека плохая.

В spec-kit (инструмент для Claude Code, подробнее — в статье про spec-driven development) поток выглядит так:

1. /speckit.specify — превращает идею в структурированную спеку с пользовательскими историями и требованиями
2. /speckit.clarify — убирает неоднозначности, закрывает все вопросы до единственного толкования
3. /speckit.plan — строит технический план и прогоняет Constitution Check
4. /speckit.tasks — режет план на атомарные задачи, привязанные к требованиям
5. /speckit.implement — пишет код по задачам

Вы видите всю цепочку: от идеи — через спеку — до PR. Каждое решение объяснено.

Плюсы:

• Проблемы находятся на стадии спеки, а не кода — это несравнимо дешевле
• Агент не галлюцинирует на пустых местах: контракт заполнен заранее
• Артефакты остаются: ревьюер видит не только код, но и почему он такой
• Прослеживаемость: от критерия успеха — до конкретной задачи
• Хорошо масштабируется на команду и на несколько агентов параллельно

Минусы:

• Затраты на входе: надо написать спеку до кода
• Избыточно для мелких задач — получается бюрократия
• Требует дисциплины: искушение «просто начать» сильное
• Если спека неполна, агент всё равно упрётся в дыру

Когда упираешься в стену: поучительный кейс

Представьте: вы через vibe-coding делаете программу лояльности для CoffeeCRM. Агент написал начисление и списание бонусов. Всё работает — пока не выясняется, что при отмене заказа баллы не откатываются. В коде этого случая вообще нет.

Правильная реакция — не «дописать проверку», а остановиться и понять: это дыра в спеке, а не в коде. Что должно происходить с баллами при отмене? Это продуктовое решение. Пока оно не зафиксировано письменно, любой код будет гаданием.

Именно здесь spec-driven approach показывает свою силу: дыру закрывают в контракте, а не в коде наспех. Это и отличает инженера от vibe-кодера в контексте работы с агентами.

Таблица выбора

Вот критерии, которые реально работают на практике:

Критерий	Скорее spec-driven	Скорее vibe coding
Размер фичи	Средняя / крупная, несколько слоёв	Мелкая, локальная правка
Неизвестных много?	Да — продуктовые решения нужны	Нет — всё очевидно
Цена ошибки	Высокая: данные, деньги, прод	Низкая: черновик, эксперимент
Командная работа	Несколько людей или агентов	Соло, на выброс
Срок жизни кода	Останется надолго, будет развиваться	Прототип или скетч

Три реальных кейса

Чтобы не оставаться на уровне абстракций — три конкретные ситуации:

Кейс 1: «Поменять цвет кнопки и текст лейбла в карточке клиента». → Vibe coding. Задача мелкая и очевидная, цена ошибки нулевая, нет никаких продуктовых решений. Писать спеку на смену цвета — это карго-культ, а не инженерия.

Кейс 2: «Программа лояльности — клиенты копят бонусы и тратят их». → Spec-driven. Затрагивает данные и деньги, куча неизвестных (проценты начисления, можно ли уйти в минус, что при отмене заказа, сгорают ли баллы). Фича останется надолго. Десять итераций vibe-coding тут стоят дороже, чем один хороший спека-сессии.

Кейс 3: «Накидать за вечер демку графика выручки, чтобы показать заказчику». → Vibe coding. Прототип на выброс, скорость важнее контракта, заказчик, скорее всего, попросит переделать с нуля. Если демку решат довести до прода — вот тогда переписываем через spec-driven.

Ложная дилемма: их можно смешивать

На реальном проекте разумный выбор выглядит так: вы работаете spec-driven на уровне фич и vibe-coding на уровне конкретных реализационных решений внутри задачи.

Спека фиксирует «что», Constitution Check следит за архитектурными принципами — а агент имеет свободу в деталях реализации (accrue() и redeem(), конкретные имена методов, устройство миграции). Это не противоречие, а разделение ответственности.

Подробнее о том, как выглядит полный поток — в статье про spec-kit и его команды.

Вывод

Spec-kit — не религия, и vibe-coding — не грех. Применять spec-driven ко всему подряд так же плохо, как итерировать через vibe-coding на задаче с деньгами и командой. Сильный инженер выбирает инструмент под задачу: контракт там, где дорого ошибиться, и наитие там, где дёшево переделать.

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

Если хотите освоить оба подхода системно — на реальном проекте CoffeeCRM от пустого репозитория до деплоя — смотрите полный курс по Claude Code.