ИИ написал приложение. Теперь бизнесу приходится переписывать проект заново

Нейросети в разработке быстро прошли путь от инструмента ускорения до способа продавать бизнесу видимость готового продукта.

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

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

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

Демо не равно продукт

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

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

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

Главный тест - можно ли изменить логику

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

«Лишь через несколько недель становится ясно, можно ли изменить бизнес-логику без участия разработчика», - говорит Евгений Мошняцкий, коммерческий директор НТЦ АРГУС.

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

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

Безопасность ломается вместе с архитектурой

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

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

Облако не спасает плохой продукт

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

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

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

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

Как проверять подрядчика

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

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

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

Рынок изменится, но инженерия не исчезнет

Вайбкодинг не уничтожит IT-аутсорсинг. Он снизит стоимость простых прототипов, лендингов, ботов и небольших внутренних сервисов, где цена ошибки невысока. Но крупные и критичные проекты не станут дешевыми только потому, что код можно генерировать быстрее.

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

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