Приложение на вайбкодинге: как довести прототип до рабочей системы

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

Ниже — маршрут эксплуатации: что происходит с приложением после того, как оно собрано за вечер и заработало. Что именно отличает демо от системы. Где живут данные приложения и что требует часть 5 статьи 18 закона о персональных данных. Как в приложении появляются роли и права. Как оно забирает контрагентов и остатки из 1С и CRM. Почему очередной запрос к модели ломает работавший сценарий и чем это лечится. Кто чинит систему в понедельник утром и по каким признакам прототип приходится переписывать. Сам подход разобран отдельно — что такое вайбкодинг и зачем он бизнесу; выбор инструмента — в сравнении ИИ для вайбкодинга.

Чем прототип отличается от рабочей системы?

Коротко: числом людей, реальностью данных и тем, что происходит в день сбоя.

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

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

Где живут данные приложения и что требует 152-ФЗ?

Коротко: у платформы-генератора данные лежат на её инфраструктуре за пределами страны, а закон требует держать базу с данными россиян в России.

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

Опорная норма сформулирована прямо:

При сборе персональных данных, в том числе посредством интернета, оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение персональных данных граждан РФ с использованием баз данных, находящихся на территории Российской Федерации — Федеральный закон № 152-ФЗ, статья 18, часть 5, КонсультантПлюс.

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

Цена вопроса изменилась. С 30 мая 2025 года действует новая редакция статьи 13.11 КоАП, введённая законом № 420-ФЗ: утечка данных от тысячи до десяти тысяч человек обходится организации в 3–5 млн рублей, свыше ста тысяч человек — в 10–15 млн, биометрия — в 15–20 млн. За повторную утечку предусмотрен оборотный штраф 1–3% годовой выручки с минимумом 20–25 млн и потолком 500 млн рублей, а неуведомление Роскомнадзора об инциденте стоит 1–3 млн (обзор изменений, КонсультантПлюс). Скидка за быструю уплату к этим составам не применяется.

Масштаб самой проблемы при этом не астрономический, и это стоит знать, чтобы не пугаться цифр из заголовков. По данным Роскомнадзора, которые ведомство привело 22 января 2026 года, в 2025 году зафиксировано 118 случаев компрометации баз персональных данных на 52 млн записей против 135 случаев и более 710 млн записей годом раньше (ComNews, 22 января 2026). Утечек стало меньше, штраф за попадание в эту статистику — заметно больше.

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

Как в приложении появляются роли и права доступа?

Коротко: их проектируют отдельно, потому что в прототипе роль ровно одна — автор, которому можно всё.

Сгенерированное приложение по умолчанию считает, что любой открывший его человек имеет право на любое действие. Так вышло из постановки задачи: модель просили сделать форму заявок, разграничение доступа к чужим заявкам в запросе не звучало. Именно на этом ломались публичные истории 2025 года с приложениями, раздававшими посторонним чужие данные, — разбор в статье что такое вайбкодинг.

Разграничение строится в четыре слоя, и пропуск любого из них обесценивает остальные:

1. Вход в систему. Кто пользователь и чем он это подтверждает. Общий пароль на отдел означает, что журнал действий бесполезен: в нём все действия сделаны «сотрудником».
2. Роли. Набор действий под должность: менеджер, руководитель отдела, бухгалтер, администратор. Роли переживают увольнения, персональные настройки — нет.
3. Права на записи. Менеджер видит своих клиентов, руководитель — весь отдел. Проверка обязана стоять на стороне сервера: спрятать кнопку в интерфейсе недостаточно, запрос к данным уходит и без кнопки.
4. Журнал действий. Кто, когда и что изменил. Без него разбор любого спора превращается в опрос сотрудников.

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

Как связать приложение с 1С и CRM?

Коротко: приложение не заводит свои справочники, а забирает их из систем-хозяев и возвращает туда результат.

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

Разграничение владения снимает большую часть споров:

• 1С владеет контрагентами, номенклатурой, ценами и деньгами. Оттуда приходят реквизиты, остатки и лимиты.
• CRM владеет клиентом и сделкой. Оттуда приходят ответственный менеджер и стадия работы.
• Приложение владеет своим процессом. Заявками, замерами, маршрутами, чек-листами — тем, ради чего его и собирали. Обратно уходит результат: документ, статус, сумма.

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

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

Что происходит с приложением при следующем запросе к модели?

Коротко: правится то, о чём просили, и иногда ломается то, о чём не спрашивали.

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

Отраслевые замеры показывают, что материал для таких поломок накапливается. Исследование GitClear «The Maintainability Gap», вышедшее в июне 2026 года на 623 млн изменений кода за 2023–2026 годы, фиксирует восемь сигналов качества. Дублирование блоков кода выросло на 81%, копирование внутри одного изменения — на 41%, конструкции, маскирующие ошибки, — на 47%, а перемещения строк, по которым видно рефакторинг, упали на 70% к уровню 2022 года. Смысл для владельца прикладной: один и тот же расчёт лежит в нескольких местах, и правка в одном из них оставляет остальные работать по-старому.

Второе наблюдение — про темп. Отчёт DORA «State of AI-assisted Software Development», опубликованный Google Cloud 23 сентября 2025 года по опросу почти 5000 специалистов, показал: ИИ применяют 90% респондентов, скорость поставки изменений выросла, а связь с устойчивостью поставки осталась отрицательной. Вывод авторы формулируют как усиление: ИИ увеличивает то, что в команде уже есть, и зрелости сам по себе не добавляет. Там, где нет автоматических тестов и быстрой обратной связи, растёт число изменений вместе с числом аварий.

Отсюда минимальный набор страховок, который отделяет систему от прототипа:

1. Тесты на денежные и учётные сценарии. Расчёт суммы, скидка, проведение документа, обмен с 1С. Прогоняются до выкладки, пока изменение ещё не дошло до пользователей.
2. Отдельный контур для проверки. Копия системы на тестовых данных, где изменение живёт до попадания в работу.
3. История версий и возврат назад. Возможность откатить последнюю правку за минуты, вместо сборки системы заново по памяти.
4. Фиксация того, что изменилось. Короткая запись «что и зачем» к каждой правке: через полгода она стоит дороже самого кода.

Кто чинит приложение в понедельник утром?

Коротко: тот, кого назвали заранее; при отсутствии такого человека чинить начинает тот, кто громче жалуется.

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

• Доступы. Хостинг, база, домен, почтовый сервис оформлены на компанию. Если ключи в личном аккаунте сотрудника, который собирал прототип, у компании есть работающее приложение и нет системы.
• Журналы и мониторинг. Ошибки записываются и видны, а не выясняются по скриншотам из мессенджера. Проверка доступности приложения сообщает о падении раньше пользователей.
• Резервные копии. Делаются по расписанию и проверяются восстановлением. Копия, которая ни разу не разворачивалась, остаётся надеждой.
• Названный владелец. Человек в компании, который решает, что считать аварией, и расставляет очередь на исправление.
• Сопровождение. Договорённость о том, кто чинит код и в какие сроки. Внутри команды или у подрядчика — но зафиксированная заранее, до первого инцидента.

Разбор поломки в сгенерированном приложении отдельно дорог. По опросу Stack Overflow Developer Survey 2025, где ИИ-инструменты используют или планируют использовать 84% разработчиков, главная жалоба — решения, «почти правильные, но не совсем» (66%), а вторая по частоте — то, что отладка сгенерированного кода отнимает больше времени (45%). Это про профессионалов, читающих код. Для приложения, собранного человеком, который код не читал, поиск причины начинается с чтения всего проекта заново.

На каком объёме прототип приходится переписывать?

Коротко: на форме нагрузки и на стоимости очередной правки; счётчик пользователей об этом говорит мало.

Вопрос «сколько человек выдержит» задают чаще всего, и он почти всегда неверный. Двадцать человек, читающих справочник, живут спокойно. Пятеро, одновременно меняющих один и тот же остаток, ломают приложение, в котором не предусмотрена одновременная запись. Смотреть надо на признаки.

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

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

Что нужно, чтобы приложение заработало у вас?

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

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

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

Коробка или система под свой процесс?

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

Вторая причина смотреть шире коробки — связность. Приложение бесполезно в отрыве от контрагента, остатка и суммы, а они лежат в 1С и CRM. Без двустороннего обмена оно становится ещё одним местом, где те же данные хранятся отдельно и расходятся с учётом. Развилку между готовым решением и системой под свой процесс мы разбирали отдельно — своя система или коробка.

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

Мы в INCUBE AI доводим такие приложения до рабочего состояния как заказную разработку: переносим данные в российский контур, настраиваем роли и права, строим обмен с 1С и CRM, заводим журналы, мониторинг и тесты, обсуждаем сопровождение вместе с проектом. Работаем по договору, данные остаются в РФ. Сайт, который вы читаете, и конвейер публикации его статей собраны в связке человек плюс ИИ-агент — с той разницей, что каждое изменение проходит тесты и ревью. Есть прототип, который прижился в отделе, и вопрос, что с ним делать дальше — расскажите о задаче: посмотрим, что в нём стоит сохранить, что построить заново и во что обойдётся эксплуатация.

Источники

• Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ, статья 18, часть 5, КонсультантПлюс — требование вести запись, систематизацию, накопление, хранение, уточнение и извлечение персональных данных граждан РФ с использованием баз данных на территории России
• Персональные данные: новые штрафы с 30 мая 2025 года, КонсультантПлюс — редакция статьи 13.11 КоАП по закону № 420-ФЗ: 3–5 млн рублей за утечку данных 1–10 тыс. человек, 10–15 млн при объёме свыше 100 тыс., 15–20 млн за биометрию, оборотный штраф 1–3% выручки за повторную утечку, 1–3 млн за неуведомление Роскомнадзора
• ComNews, 22 января 2026: Роскомнадзор о числе утечек персональных данных за 2025 год — 118 случаев компрометации баз и более 52 млн записей в 2025 году против 135 случаев и свыше 710 млн записей в 2024-м
• GitClear. «The Maintainability Gap: 2026 AI Code Quality Research», июнь 2026 — 623 млн изменений кода за 2023–2026 годы: дублирование блоков выросло на 81%, копирование внутри изменения на 41%, конструкции, маскирующие ошибки, на 47%, перемещения строк (рефакторинг) упали на 70% к уровню 2022 года
• DORA. «State of AI-assisted Software Development», Google Cloud, 23 сентября 2025 — опрос почти 5000 специалистов: ИИ применяют 90% респондентов, связь внедрения ИИ со скоростью поставки положительная, с устойчивостью поставки — отрицательная
• Stack Overflow Developer Survey 2025, раздел AI — 84% используют или планируют использовать ИИ-инструменты; главные жалобы: решения «почти правильные, но не совсем» (66%) и возросшее время отладки сгенерированного кода (45%)