ИИ написал приложение, и бизнесу приходится писать проект заново
Нейросети в разработке все чаще используют не только для ускорения работы, но и для создания видимости готового продукта. Подрядчик может быстро собрать сервис, показать эффектную демонстрацию и представить ее как полноценную разработку, сообщает Код Дурова.
В профессиональной команде искусственный интеллект помогает подготовить прототип, написать типовые фрагменты кода или проверить гипотезу. Однако при слабом инженерном контроле такой подход может привести к созданию проекта, который выглядит рабочим только на первом показе.
Коммерческий директор НТЦ «АРГУС» Евгений Мошняцкий отметил, что через несколько недель становится понятно, можно ли менять бизнес-логику без постоянного участия разработчика.
Внешне такой сервис может производить хорошее впечатление. У него есть аккуратный интерфейс, работают кнопки, чат-бот отвечает, калькулятор считает, а личный кабинет открывается.
Проблемы проявляются позже. Может выясниться, что в проекте нет продуманной архитектуры, модель данных собрана формально, ошибки не обрабатываются, тестирование отсутствует, документация не отражает реальную работу системы, а безопасность не проверялась.
Для компании дешевый запуск в таком случае может обернуться большими затратами. Если систему приходится выбрасывать и писать заново, бизнес сначала платит за демонстрационный образец, затем — за аудит и полноценную разработку.
Вайбкодинговые проекты обычно хорошо выглядят во время первого показа. Подрядчик демонстрирует заранее подготовленный сценарий: бот отвечает на стандартные вопросы, приложение начисляет бонусы, форма отправляет данные, а калькулятор рассчитывает доставку.
Для руководителя без технической экспертизы этого бывает достаточно, чтобы решить, что продукт почти готов. Но за пределами демонстрации появляются нестандартные данные, сбои внешних сервисов, рост нагрузки, новые бизнес-правила и дополнительные интеграции.
Именно в таких условиях становится ясно, есть ли внутри инженерная система. Если архитектура продумана, команда может объяснить модель данных, зависимости, программные интерфейсы, порядок выпуска обновлений и отката изменений.
Если полноценного продукта нет, любая доработка превращается в поиск причин ошибок и попытку разобраться в сгенерированном коде.
Отдельный риск связан с информационной безопасностью. Сервис может внешне работать, но содержать слабую авторизацию, открытые точки входа, небезопасное хранение токенов, уязвимые зависимости и ошибки в настройке базы данных.
Такие проблемы не всегда видны пользователю. Основные сценарии могут выполняться, но при проверке выясняется, что один клиент способен получить доступ к чужим данным, права настроены формально, а журналы не позволяют восстановить действия в системе.
Еще одна сложность возникает при попытке перенести сервис в облако, подключить новые интеграции или подготовить его к росту нагрузки. На этом этапе могут обнаружиться неоптимальные запросы к базе, формальное резервное копирование, бесполезные журналы, отсутствие мониторинга и документация, не описывающая реальные зависимости.
Облачная инфраструктура сама по себе не исправляет слабую архитектуру. Она лишь быстрее показывает проблемы системы, если та изначально собрана как набор случайных решений.
Главная защита для бизнеса — не пытаться определить, писал ли код искусственный интеллект. Само использование нейросетей не является проблемой. Важно другое: несет ли подрядчик инженерную ответственность за результат.
Заказчику стоит оценивать не только интерфейс, но и репозиторий, документацию, описание архитектуры, модель данных, программные интерфейсы, тесты, список зависимостей, проверку уязвимостей, порядок релиза, резервного копирования и отката.
Для критичных сервисов особенно важны права доступа, хранение персональных данных, журналирование, мониторинг и восстановление после сбоя.
Вайбкодинг может снизить стоимость простых прототипов, лендингов, ботов и небольших внутренних сервисов, где цена ошибки невысока. Но крупные и критичные проекты не становятся надежными только из-за быстрой генерации кода.
По мере развития таких инструментов в смете может уменьшиться доля типового программирования, но вырастет значение архитектуры, интеграций, безопасности, тестирования, эксплуатации и поддержки.
Искусственный интеллект остается полезным инструментом профессиональной команды. Однако он не заменяет понимание бизнес-задач, проектирование, контроль качества и ответственность за жизненный цикл продукта.
Рекомендуем также:
- Переросшие кабачки не выбрасываю: убираю середину и запекаю с фаршем — гарнир уже не нужен
- Домашнее лечо получается почти как суп: одна привычка с овощами дает слишком много жидкости
- Почему бабушки никогда не резали горячие пироги сразу после духовки: простая привычка меняла мякиш
- Яблочное повидло приходится варить часами: одна ошибка в начале добавляет лишнюю воду
- Курица дает много воды и никак не подрумянивается: одна ошибка превращает жарку в тушение
