Гонка за дешевизной убивает качество и разработка мобильных приложений не исключение. Сегодня любой менеджер с парой тысяч рублей может нагенерировать «код» через ChatGPT или Copilot и получить на экран сомнительное подобие мобильного приложения. Это звучит как магия: быстро, дёшево, без нудных собеседований с разработчиками. Но за этой видимой простотой скрывается минное поле для бизнеса. Тысячи компаний уже получили «технологические долги», о которых даже не подозревали, пока их ИИ-проект не рухнул под нагрузкой реальных пользователей.
43% компаний уже тонут в новом технологическом долге
Цифры не врут. Согласно исследованию HFS Research, проведенному среди Global 2000, 84% организаций ожидают снижения затрат от внедрения ИИ, но при этом 43% прямо заявляют: искусственный интеллект создает новый технический долг. Это не байки консерваторов. Когда вы генерируете код нейросетью, вы не просто получаете функцию - вы получаете черный ящик, прибитый гвоздями к вашему проекту.
Технический долг в ИИ-проектах растет экспоненциально. Представьте, что вы строите дом из пластилина. Быстро, дешево, форма есть. Но через месяц пластилин трескается, а добавить второй этаж невозможно - конструкция не держит вес. Так и с нейросетевым кодом. Исследование той же HFS показало, что в среднем только 18% бюджета на трансформацию уходит непосредственно на софт, остальное пожирают услуги по интеграции и обслуживанию. Компании тратят в 2-7 раз больше на поддержку того, что сгенерировали, чем на саму генерацию.
Пример из практики: средний показатель переиспользования кода в ИИ-сборках - жалкие 33%. Это значит, что две трети функционала команды переписывают каждый раз с нуля. Потому что понять, как связаны сгенерированные модули, невозможно. ИИ не оставляет архитектурных планов.
Проблема «Bus Factor»: Никто не понимает, как это работает
Bus Factor мрачный термин из мира разработки. Он означает: сколько человек должно попасть под автобус, чтобы проект умер. Для ИИ-приложений Bus Factor часто равен нулю. Даже тот, кто нажимал кнопку «сгенерировать», не понимает внутренней логики.
Когда LLM пишет код, она не строит архитектуру в том смысле, как это делает человек. Она предсказывает следующую лексему на основе обучающей выборки. В результате получается «спагетти» высшего уровня - внешне работающее, но с хаотичной структурой. Традиционные обзервалити-инструменты бесполезны. Вы видите, что сервис А упал, но почему? Какая скрытая зависимость дернулась?
Современные подходы к observability требуют создания «Живой Базы Знаний» (Living Knowledge Base) - графовой БД, которая в реальном времени отслеживает связи между сервисами, подами, узлами и вызовами. Но для этого нужно проектировать систему осознанно. ИИ этого не делает. Он не создаст граф зависимостей, не промаркирует эджы. Он просто выплюнет код.
Последствия: когда приложение ломается в 3 часа ночи, дежурный инженер видит стену текста. Нет документации, нет схемы, нет понимания, какой модуль за что отвечает. Починка превращается в угадайку. Тикеты висят днями. Клиенты уходят. Бизнес теряет деньги.
Отсутствие тестирования и «Синдром Слепого Доверия»
OWASP, организация, задающая стандарты безопасности, ввела специальный термин для этой проблемы: «Blind Trust» (Слепое доверие). Это риск номер один для citizen development. Разработчик видит, что код работает на его машине с одним сценарием, и предполагает, что он безопасен и корректен. Ошибка.
Исследования Armis Labs показали шокирующую вещь: 100% протестированных генеративных моделей не смогли написать безопасный код для высокорисковых зон - переполнение буфера, загрузка файлов, системы аутентификации. Более того, даже лучшие модели выдают уязвимости согласно OWASP Top 10 в 38.71% случаев. Треть кода - потенциальная дыра.
Самая частая проблема - CWE-770 (Allocation of Resources Without Limits). ИИ редко добавляет ограничения по таймаутам или памяти. Он напишет цикл, который в теории работает, но на практике ляжет сервер при первом же всплеске нагрузки. ИИ не знает про лимиты вашей инфраструктуры.
Где тестирование? Энд-ту-энд тесты, написанные ИИ, обычно проверяют «счастливый путь». А как насчет edge cases? Академическое исследование сравнения кода человека и ИИ (React Native) показало: ИИ генерирует рабочий, но «ломкий» код. Он хуже справляется с обработкой краевых случаев, верстка «плывет», компоненты не переиспользуются. Человек пишет структурированнее.
AI-тестирование мобилок сейчас пытается решить проблему «random wandering» - когда тестовый робот начинает тыкать куда попало, если промпт абстрактный. Это критично для CI/CD. Если тест недетерминирован, он может сегодня пройти, а завтра - сломаться без изменений в коде. Профессионалы решают это через zero-temperature настройки моделей, жесткие схемы (json schema) и гранулярные ассершны. В ИИ-поделке этого нет.
«Поддержка? Вы издеваетесь?» Реальность техобслуживания
Самое дорогое в софте не написание, а поддержка. Исследования показывают, что компании тратят до 70% бюджетов на сервисы и мейнтененс. ИИ усугубляет ситуацию, потому что генерирует «code sprawl» - разрастание кодовой базы без улучшения функционала.
Когда баг обнаруживается (а он обнаружется), исправление одной строчки вручную может сломать три другие функции. Почему? Потому что ИИ не понимает контекст. Он видит только локальный кусок задачи. Он не знает, что этот сервис еще используется в трех местах, не описанных в промпте. Получается эффект домино.
Паттерн «Vibe Coding» (когда ты просто описываешь ощущения, а код генерируется сам) порождает системы, в которых валидация и обработка ошибок «функции продукта», а не инженерные детали. Платформы вроде Koder.ai показывают: если нет жестких контрактов на входы и выходы (input/output schemas), ИИ начнет галлюцинировать. Он придумает ID, которых нет в базе, или просуммирует цифры неправильно.
Для нормальной поддержки нужны:
- Структурная валидация (JSON schema проверяет типы и наличие ключей).
- Семантическая валидация (существует ли этот customer_id в CRM?).
- Границы отказоустойчивости (circuit breakers, retries с экспоненциальной задержкой).
ИИ не добавит это по умолчанию. Ему плевать на ваши поллитры. Он просто хочет закрыть таск.
Уязвимости безопасности: Золотая жила для хакеров
Хакеры обожают ИИ-код. Потому что он предсказуем в своей уязвимости. Отчеты показывают: 59% компаний называют безопасность главной головной болью при масштабировании ИИ.
Сценарий атаки: вы просите ИИ написать код для загрузки аватарок. Он генерирует форму. Но он не проверяет MIME-типы должным образом или забывает про лимиты размера. Злоумышленник заливает шелл-скрипт вместо картинки. ИИ даже не подумал про virus scan или изоляцию загрузок. Вуаля, сервер скомпрометирован.
Другой вектор - внедрение зависимостей. ИИ часто использует последние версии библиотек или, наоборот, устаревшие, которые видел в трейне. Он не проверяет, нет ли в этой библиотеке CVE с критическим скорингом. Он просто берет то, что чаще встречалось в интернете.
Правила Google Play уже требуют от приложений на генеративном ИИ внедрения фильтров и классификаторов для блокировки нежелательного контента. Но кто будет писать эти фильтры в приложении, сделанном на коленке за вечер? Правильно, никто. Такое приложение полетит в бан с маркета, а вместе с ним - ваша репутация и деньги за публикацию.
Почему профи единственный вариант
Профессионал не пишет код «с нуля» каждый раз. Он использует архитектурные паттерны (Clean Architecture, MVVM с четким разделением слоев), которые ИИ не способен охватить целиком из-за ограничений контекстного окна. Специалист закладывает в проект инжекцию зависимостей, репозитории для работы с данными и юнит-тесты с покрытием 80%+.
Когда вы нанимаете команду, вы платите за:
- Управление состоянием: Профи знает, как поднять BLoC или Redux, чтобы UI не тормозил.
- Безопасность: Хранение токенов в Keychain/Keystore, сертификатный пиннинг, обфускация кода (ProGuard/R8).
- CI/CD пайплайны: Настройка билдов, автоматическое тестирование на фермах устройств, деплой в TestFlight и Google Play.
- Мониторинг: Интеграция Sentry или Firebase Crashlytics, логирование, дашборды производительности.
Специалист использует GPT как ассистента для генерации boilerplate кода, а не как архитектора. Он проверяет каждый сгенерированный фрагмент, переписывает его под стандарты компании и, главное, понимает, как эта строчка повлияет на систему вцелом.
Бизнес должен понять: экономия 5000 долларов на разработке ИИ обернется потерей 50000 на фиксах, судебных исках за утечку данных и упущенной выгоде из-за простоя. Инструменты вроде OutSystems или AppMaster могут ускорить разработку, но они лишь платформы. Кнопку «Опубликовать» должен нажимать человек с инженерным мышлением.
Не дайте иллюзии дешевизны убить ваш продукт. Если софт не игрушка, а инструмент для заработка, доверяйте его создание тем, кто умеет читать и писать код, а не просто генерировать его. ИИ мощный инструмент в руках мастера и опасная игрушка в руках дилетанта. Выбирайте мастеров.
