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

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

URL: https://posts.danashkin.ru/guides/vibecoding-v-prodakshene-realnye-proekty
Обновлено: 2026-08-15

---

## Коротко

**Главное**

- Мнение «вайбкодингом делают только игрушки» устарело. До живых пользователей доезжают и внутренние инструменты, и боты, и небольшие платформы с личными кабинетами.
- Граница проходит не по сложности кода, а по цене ошибки. Инструмент для себя и сервис, где лежат чужие деньги или персональные данные, живут по разным правилам.
- Первый барьер обычно бытовой: продукт работает, пока включён твой компьютер. Отвязка от него это отдельная развилка, а не мелочь настройки.
- Ломается переход к людям в пяти предсказуемых местах: данные, доступы, обновления, ошибки на глазах у пользователя и закон.
- Практическая рамка: если ошибка стоит времени, вези сам. Если денег, здоровья или чужих данных, зови человека, который отвечает за это профессионально.

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

**Главное**

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

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

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

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

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

**Главное**

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

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

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

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

Третье: платформа с кабинетами. Я сам держу в проде площадку, где ученики видят свои модули, записи и материалы, а этот блог с сотней страниц собран и опубликован тем же способом. Разбор одного такого продукта целиком есть в материале про [пульт управления бизнесом в мессенджере](/guides/telegram-bot-pult-upravleniya-biznesom-keys).

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

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

**Главное**

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

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

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

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

**Красная зона без обсуждения**

Персональные данные клиентов, платежи, медицина, всё, что связано с несовершеннолетними, и любые решения с юридическими последствиями. Тут [вайбкодинг](/concepts/vibecoding) годится максимум для прототипа, который потом переписывают взрослые люди с ответственностью и страховкой.

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

**Главное**

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

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

| Признак | Доедет | Скорее нет |
|---|---|---|
| Пользователи | ты, отдел, десятки человек | тысячи снаружи, круглосуточно |
| Цена ошибки | потерянное время, переделка | деньги клиента, здоровье, суд |
| Данные | свои, обезличенные, публичные | персональные данные третьих лиц |
| Источник данных | файл, таблица, открытый интерфейс сервиса | закрытая система без доступа наружу |
| Роли и права | одна-две роли | сложная матрица доступов |
| Требование к отклику | можно подождать минуту | миллисекунды, гарантии доступности |

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

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

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

**Главное**

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

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

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

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

Как проверять результат работы агента, когда сам не читаешь код, разобрано у меня в отдельном материале про [приёмку кода без технического бэкграунда](/guides/kak-proveryat-ai-kod-bez-teh-bekgraunda).

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

**Главное**

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

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

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

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

Что появляется в жизни продукта после переезда, подробно разобрано в материале про [деплой, базу и персональные данные](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

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

**Главное**

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

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

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

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

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

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

**Главное**

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

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

**Разработчик всё равно понадобится?**

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

**А нагрузку это выдержит?**

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

**Можно ли продавать то, что собрал сам?**

Можно, и люди продают. Но с момента, когда появляются платящие клиенты, добавляются обязательства: договор, возвраты, защита данных, ответственность за простой.

**Что делать с безопасностью?**

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

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

**Главное**

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

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

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

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

### Источники

- [Anthropic. Claude Code - официальная документация агента](https://docs.claude.com/en/docs/claude-code/overview)
- [Anthropic. Common workflows - типовые рабочие сценарии, включая подготовку к выкладке](https://docs.claude.com/en/docs/claude-code/common-workflows)
- [OWASP Top 10 - общепринятый список типовых уязвимостей веб-приложений](https://owasp.org/www-project-top-ten/)
- [Федеральный закон 152-ФЗ «О персональных данных» - требования к хранению данных граждан РФ](https://www.consultant.ru/document/cons_doc_LAW_61801/)