Вайбкодинг только для игрушек? Что реально доезжает до продакшена

Коротко

Откуда взялось мнение, что это только для игрушек?

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

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

Отсюда и ощущение обрыва. На самом деле там не обрыв, а просто другая работа: не про синтаксис, а про данные, ответственность и обновления.

Три живых примера того, что уже работает

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

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

Второе: бот в мессенджере. Собирает утреннюю сводку по отраслевым новостям, принимает голосовые заметки, напоминает про задачи. У одного из участников практикума такой бот работал ежедневно и в группе про него ни разу не рассказывалось, пока мы не сели один на один.

Третье: платформа с кабинетами. Я сам держу в проде площадку, где ученики видят свои модули, записи и материалы, а этот блог с сотней страниц собран и опубликован тем же способом. Разбор одного такого продукта целиком есть в материале про пульт управления бизнесом в мессенджере.

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

Где проходит настоящая граница?

Рамка, которой я пользуюсь и даю ученикам, простая. Задай себе один вопрос: что случится, если система ошибётся и никто этого сразу не заметит?

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

Между этими полюсами лежит широкая середина: внутренние процессы компании, где ошибка стоит переделки, а не иска. Именно её сейчас массово закрывают силами самих сотрудников, и это самая интересная зона.

Признаки задачи, которая доедет до прода

Собрал признаки в таблицу, чтобы можно было честно примерить свою идею.

Обрати внимание на строку про источник данных. Чаще всего проект встаёт не из-за кода, а из-за того, что нужные цифры лежат в системе, которая наружу их не отдаёт.

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

Пять мест, где демо ломается о реальность

Разберём по порядку, потому что каждое место лечится по-своему:

1. Данные. В демо они выдуманные, у людей настоящие и грязные. Прогонять на реальных надо до публикации, иначе ошибки вскроются на пользователях.
2. Доступы. Работало на твоём компьютере с твоими ключами, а на сервере ключей нет. Секреты хранятся отдельно от кода, и этому надо научиться один раз.
3. Обновления. Правка ломает то, что работало вчера. Спасают проверки перед выкладкой и привычка возвращаться на предыдущую версию.
4. Ошибки на глазах. Пользователь увидит непонятное сообщение и уйдёт. Нужен человеческий текст ошибки и место, куда о ней сообщить.
5. Закон. Персональные данные граждан России хранятся в базах на территории России, и это не рекомендация, а требование закона.

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

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

Как понять, что твой проект готов к людям?

Мой чек-лист перед тем, как звать первых живых пользователей:

1. Отключи свой компьютер и проверь, что всё работает. Это первое, обо что спотыкаются.
2. Прогони на реальных данных за настоящий период, а не на трёх примерах.
3. Перезапусти сервер и убедись, что продукт поднялся сам.
4. Сломай нарочно. Введи ерунду в форму и посмотри, что увидит человек.
5. Проверь резервную копию. Не наличие, а восстановление: копия, которая не разворачивается, копией не является.
6. Позови одного постороннего и молча смотри, как он пользуется. Одного хватает, чтобы увидеть половину проблем.

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

Что появляется в жизни продукта после переезда, подробно разобрано в материале про деплой, базу и персональные данные.

Сколько это стоит поддерживать?

Про деньги обычно спрашивают первым, а болит не это.

Инфраструктура для небольшого сервиса стоит примерно как один обед в неделю. Подписка на агента, если ты продолжаешь дорабатывать продукт сам, добавляет ещё сопоставимую сумму.

Настоящая цена во внимании. Живой продукт требует нескольких часов в месяц: обновить, проверить, поправить, ответить пользователю. Это и есть та причина, по которой половина внутренних инструментов тихо умирает, а не потому, что код плохой.

Метафора, которую я повторяю ученикам: продукт похож на ремонт, его нельзя закончить, можно только временно прекратить. Планируй не запуск, а жизнь после него.

Частые вопросы

Главный вывод

Соберу в одну мысль. Вопрос не в том, можно ли собрать продакшен таким способом, а в том, какую цену ошибки ты готов на себя взять.

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

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