Вайб-кодинг: когда он помогает, а когда дорого обходится.
Вайб-кодинг — это способ собирать программу через диалог с ИИ, когда человек описывает желаемое поведение, запускает полученный код и правит его новыми запросами. Он полезен для одноразового прототипа или узкой проверки гипотезы. Если код должен стать продуктом, быстрый старт не отменяет инженерную работу.
Сама по себе возможность получить работающий экран за несколько итераций не делает метод плохим. Проблема появляется, когда видимое поведение принимают за готовность к реальной эксплуатации. Пользователь видит успешный сценарий, но ещё не видит поведение на неполных данных, проверку доступа, восстановление после сбоя и последствия изменения одной части системы.
Поэтому вопрос не в том, «работает ли вайб-кодинг». Он может создавать работающее ПО. Правильный вопрос — какое решение команда хочет принять, какой риск допустим и что произойдёт с кодом после проверки. Ответ определяет, нужен ли одноразовый артефакт, рабочий MVP или продукционная система.
02 · Когда метод уместен
Граница задаётся не сложностью экрана, а ценой ошибки и судьбой кода после проверки.
01
Одноразовая демонстрация
Нужно показать идею в управляемых условиях, без реальных данных, обязательств по доступности и последующего развития.
02
Проверка понятности
Главный вопрос — понимает ли человек предложение и порядок шагов. Макет можно выбросить сразу после получения ответа.
03
Проверка технической возможности
Изолированный эксперимент может показать, получается ли обработать один тип входа. Он не обязан пока поддерживать весь процесс.
04
Внутренний инструмент с низким риском
Допустим узкий скрипт для автора, если его ошибка видна, результат можно пересобрать вручную, а зависимость от него не становится критичной.
Общее условие — команда заранее решила, что этот код можно не развивать. Если прототип неожиданно становится основой продукта, нужно остановиться и пересмотреть границы. Пользователи, данные и обязательства по поддержке меняют требования, даже если внешне сценарий остался тем же.
Для выбора между макетом и рабочим контуром полезно сначала определить, нужен ли фактический результат. Эта граница подробно разобрана в материале «MVP или прототип». Вайб-кодинг может быть способом создать оба формата, но не отменяет разницу между ними.
03 · Где возникает реальная стоимость
Проверка и понимание кода
Генерируемый код нужно прочитать и соотнести с задачей. Это не ритуал: проверяющий ищет неявные допущения, повторяющуюся логику, случайные зависимости и места, где поведение расходится с описанием. Если код некому объяснить, команда не контролирует собственный продукт, даже когда демонстрация работает.
Архитектура и данные
Быстрая сборка часто оптимизирует локальный путь: получить вход, вызвать сервис, показать ответ. Продукту нужны ещё границы компонентов, модель данных, правила изменения состояния, обработка повторов и ошибок. Если эти решения не были приняты в начале, их придётся принять перед реальным использованием. Ранняя экономия не исчезает, но она не равна стоимости готового продукта.
Тесты и исключения
В диалоге с ИИ легко проверять пример, который только что был описан. Система встречает неполный ввод, повторное действие, параллельное изменение, недоступную зависимость и неожиданную последовательность. Тесты фиксируют ожидаемое поведение и позволяют менять код, не полагаясь на память о прежней версии.
Безопасность и сопровождение
Прототип может хранить секрет в неподходящем месте, доверять входу без проверки или показывать данные не той роли. Пока он запускается локально на подготовленных данных, риск ограничен средой. При публикации появляются реальные учётные записи, данные, журналы событий, резервные копии и обновления зависимостей. Эту работу нельзя считать бесплатным следствием удачной демонстрации.
04 · Не путать с разработкой с ИИ
Инженерная команда тоже может использовать ИИ для написания кода, поиска вариантов или подготовки тестов. Отличие не в наличии модели, а в ответственности за решение. При инженерном подходе человек задаёт границы, проверяет результат, понимает зависимости и оставляет код в состоянии, которое другой инженер сможет развивать.
Непроверенный вайб-кодинг перекладывает эту работу на будущее. Инженерно проверенная разработка с ИИ выполняет её по мере сборки. Оба подхода могут дать быстрый видимый результат. Но только второй подход считает архитектуру, качество и передачу частью текущей работы, а не неожиданным долгом.
Это важно и для оценки команды. Фраза «мы используем ИИ» ничего не говорит о качестве. Полезнее спросить, кто принимает архитектурные решения, как проверяется код, какие ошибки покрывают тесты, как ограничен доступ и что будет передано после приёмки.
Если исходный прототип уже есть, инженерная проверка не обязательно означает полное переписывание. Сначала команда определяет, какие части понятны, покрыты проверками и подходят для дальнейшей работы. Опасные границы можно заменить последовательно, сохраняя видимое поведение и добавляя тесты. Такой переход всё равно требует времени и понимания кода, но позволяет использовать уже полученное знание, а не защищать каждую строку только потому, что она уже создана.
Обратная ситуация тоже важна: аккуратно написанный код не исправляет неясную гипотезу. Можно построить надёжную систему для сценария, который никому не нужен. Поэтому продуктовая граница и инженерная граница работают вместе. Первая не даёт собрать лишнее, вторая не даёт выдать демонстрацию за готовый продукт. Вместе они сохраняют быстроту проверки и честность вывода.
05 · Как выбрать формат
Назовите решение, а не продукт
Начните с вопроса, на который нужен ответ. Если команда хочет узнать, понятна ли идея, может хватить макета. Если нужно увидеть, проходит ли человек полный путь и использует ли результат, нужен рабочий контур. Если задача — поддерживать реальную работу после проверки, нужна продукционная версия.
Определите сигнал
До сборки запишите, какое наблюдение поможет принять следующее решение. Просьба «покажи красивую версию» создаёт неограниченный процесс правок. Гипотеза, участник, сценарий и сигнал дают границу. Пошаговая схема этой работы есть в руководстве «Как проверить продуктовую гипотезу».
Запишите судьбу кода
Если код будет выброшен, можно оптимизировать скорость получения сигнала. Если он может перейти в пилот, уже в MVP нужны понятные границы, воспроизводимая сборка, базовые тесты и передаваемые материалы. Если он сразу будет работать с внешними пользователями и данными, нужна инженерная проверка до публикации, а не после первого инцидента.
Зафиксируйте границы до первого промпта
Чат подталкивает сразу перейти к видимому результату, но хорошая проверка начинается раньше. Полезно отдельно записать, кто проходит сценарий, с какого события он начинается, какой результат должен получить участник и что команда не будет создавать. Такой список помогает остановить бесконечную цепочку улучшений, каждое из которых выглядит небольшим, но не приближает к решению.
Рядом стоит записать условия проверки. На каких данных можно запускать версию? Какое действие нельзя выполнять автоматически? Кто сможет остановить ошибочный путь? Как восстановить исходное состояние? Для одноразового прототипа ответы могут быть простыми: только подготовленный набор, только в тестовой среде, только под наблюдением команды. Главное — чтобы эти ограничения были явными и не исчезали после удачного показа.
06 · Связать с MVP
MVP — это не техника написания кода, а формат проверки. Он связывает одну гипотезу, полный сценарий и наблюдаемый сигнал. Вайб-кодинг может помочь собрать часть такого контура, но не определяет ни гипотезу, ни достоверность сигнала. Эти решения остаются работой команды.
Поэтому минимальность не стоит измерять количеством промптов или экранов. Продукт может быть визуально простым, но требовать точной логики, доступа и обработки ошибок. Или, наоборот, иметь несколько экранов и не выполнять реальную работу. Более точное определение даёт статья «Что такое MVP продукта».
Если гипотеза уже названа и нужен рабочий сценарий, посмотрите наш подход к разработке MVP для стартапа. Мы начинаем с вводного разговора, а отдельную диагностику обсуждаем только тогда, когда без неё нельзя определить границы проверки.
В итоге способ сборки выбирается после вопроса и границ проверки. Если нужен только сигнал, одноразовый контур может быть правильным. Если нужна основа для продукта, инженерные требования должны появиться до публикации, независимо от того, кто написал первую версию кода.
Выберем формат, который даст ответ без скрытого инженерного долга.
Для первого разговора достаточно описать гипотезу, участника, нужный сигнал и то, что вы планируете делать с кодом после проверки.