Vibe coding: когда это нормально, а когда дорого

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

Граница проходит ровно там, где появляется цена ошибки. Пока код можно выбросить без последствий, читать его незачем. Как только на нём кто-то зарабатывает или чьи-то данные лежат в базе, непрочитанный код становится риском, а не экономией.

Разработка веб-приложений и сервисовот 250 000 до 900 000 ₽сроки: 6-16 недель

Где это отлично работает

Прототип для проверки идеи. Нужно показать заказчику или инвестору, как будет выглядеть сервис. Данные захардкожены, авторизации нет, ошибок нет. Три часа вместо трёх дней. Здесь читать код действительно не нужно: он живёт до первой встречи.

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

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

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

Черновик, который потом переписывается. Легитимный сценарий, если решение о переписывании принято заранее, а не «потом посмотрим».

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

Что накапливается на длинной дистанции

Проблемы начинаются, когда прототип не выбросили, а запустили.

Никто не знает, как это устроено. Код написан, но не прочитан, поэтому в голове нет модели системы. Первая нетривиальная правка требует сначала изучить собственный проект, и это дороже, чем было бы написать его осознанно.

Дублирование. Одна и та же логика лежит в четырёх местах в четырёх вариантах, потому что каждый раз генерировалась заново. Правка цены, комиссии или условия скидки требует найти все четыре. Одну обязательно пропустят.

Правки идут по кругу. Меняешь одно - ломается другое, потому что модель переписывает файл целиком, а не вносит точечное изменение. На каком-то объёме проекта скорость правок падает ниже той, что была бы при обычной разработке.

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

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

Нет тестов, потому что нечего фиксировать. Тесты пишутся к понятному поведению. Когда поведение никто не формулировал, писать их не к чему, и любая правка становится риском.

Сравнение

Vibe coding против инженерной разработки

Оценка по осям, которые определяют стоимость владения. Чем выше значение, тем лучше показатель.

А Vibe coding Б Инженерная разработка

0255075100

Скорость до первой версии

А 95

Б 30

перевес А на 65 Вечер против 2-3 недель

Цена проверки гипотезы

А 95

Б 25

перевес А на 70 Идеальный сценарий для vibe coding

Стоимость правок через полгода

А 20

Б 90

перевес Б на 70 Правки по кругу против точечных

Предсказуемость сроков

А 25

Б 85

перевес Б на 60

Безопасность данных и денег

А 15

Б 95

перевес Б на 80 Права, ключи, загрузки, ограничение запросов

Передаваемость другому разработчику

А 20

Б 90

перевес Б на 70

Готовность к росту нагрузки

А 20

Б 90

перевес Б на 70

Сколько стоит переход через границу

Считаю на понятном примере: личный кабинет с регистрацией, ролями, оплатой подписки и историей операций. Собранный целиком по наитию, он появляется за неделю-полторы и внешне работает.

Что выясняется при выводе в бой. Роли проверяются на фронтенде, значит любой пользователь может дёрнуть админский эндпоинт. Пароли хранятся с быстрым хешем. Вебхук платёжной системы не проверяет подпись, то есть оплату можно подделать запросом. История операций считается пересчётом всей таблицы, и на десяти тысячах записей страница открывается восемь секунд. Ни одной миграции базы нет, схема менялась руками на боевом сервере.

Привести это в порядок - это переписать авторизацию, доступы, платёжную часть и слой данных. То есть примерно всё, кроме интерфейса. По моим оценкам таких работ выходит 60-70% от стоимости разработки с нуля, плюс интерфейс, который приходится подгонять под новую логику. Итого около 130-150% от цены нормально сделанного проекта, и это без учёта времени, потерянного на запущенной версии.

Личный кабинет у меня стоит от 150 000 до 500 000 ₽, веб-сервис - от 250 000 до 900 000 ₽. Переделка кабинета, собранного по наитию, обычно попадает в верхнюю половину вилки, потому что к работе добавляется разбор чужих решений и перенос живых данных.

Как понять, на какой вы стороне

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

Есть ли у сервиса внешние пользователи, кроме вас и коллег. Хранятся ли персональные данные. Проходят ли через него деньги, свои или чужие. Будет ли проект жить дольше трёх месяцев. Будет ли его поддерживать кто-то, кроме автора.

Если на все пять «нет» - работайте как удобно, читать код не обязательно. Это честный ответ, и я сам так делаю на внутренних задачах.

Смешанный режим, в котором работаю я

Это не выбор между двумя крайностями. На боевых проектах я генерирую много кода, но принимаю его иначе.

Решения принимаются до генерации: схема данных, границы модулей, где проверяются права, что происходит при ошибке. Это письменный документ, а не «спрошу у модели».

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

Авторизация, роли, платежи и загрузка файлов пишутся руками. Там цена ошибки не «некрасиво», а утечка или потеря денег.

На всё, что генерировалось пачками, есть тесты. Когда я мигрировал 500+ файлов на Vue 3, тесты были единственной причиной, по которой миграция уложилась в месяц: модель ломала реактивность молча, без ошибок сборки, и находилось это только проверками.

Итог по скорости честный: экономия 20-25% времени на проекте, а не в разы. Зато код можно передать другому разработчику, и он не начнёт с предложения всё переписать.

Что с этим делать, если прототип уже запущен

Ситуация частая и не безнадёжная. Порядок такой.

Сначала закрыть безопасность: перенести проверку прав на сервер, убрать ключи из фронтенда, включить проверку подписи вебхуков, ограничить частоту запросов, проверить загрузку файлов. Это дни, а не недели, и это снимает главный риск.

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

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

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

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