По данным Gartner, в 2025 году около 60% крупных компаний тестировали генеративный искусственный интеллект в процессах разработки программного обеспечения. На фоне роста интереса к автоматизации разработки усиливается роль технических лидеров, отвечающих за архитектуру и устойчивость систем, где цена ошибки измеряется стабильностью продукта и пользовательским опытом.
О практическом применении искусственного интеллекта в мобильной разработке, роли архитектуры и инженерных решений в масштабируемых системах рассказал Алексей Абдулин — руководитель направления мобильной разработки и ведущий разработчик. Более десяти лет он занимается разработкой мобильных продуктов для ритейла, электронной коммерции и корпоративного сектора. С 2018 года работает в Kolos Studio (ООО «Колос Групп»), где прошел путь от мобильного разработчика до ведущего разработчика и технического лидера мобильного направления. В его профессиональном опыте — разработка масштабируемых мобильных платформ, высоконагруженных приложений, защищенных корпоративных решений и собственных инженерных продуктов.
В вашей роли технического лидера какие части мобильной разработки первыми выигрывают от генеративного искусственного интеллекта?
В корпоративной разработке эффект от генеративного искусственного интеллекта проявляется в ускорении рутинных этапов: подготовка типовых экранов, вспомогательных модулей, тестовых сценариев, документации. Это позволяет перераспределить ресурсы в сторону архитектуры, интеграций и бизнес-логики.
Ключевое ограничение сохраняется: искусственный интеллект работает на уровне отдельных фрагментов кода и не учитывает поведение системы в целом. В сложных мобильных продуктах это критично, поскольку устойчивость определяется взаимодействием всех компонентов.
Например, использование ИИ-агента Codex, помогло мне сократить время на прототипирование задач или целого MVP от 2 до 5 раз. Также удалось повысить скорость верстки экранов, создания наборов тестовых данных и новых компонентов для экранов в 3 раза.
В каких проектах на вашей практике архитектура играла ключевую роль в бизнес-результате?
Один из наиболее показательных проектов — мобильные приложения аптечной сети «Озерки». Изначально рассматривалась модель отдельных приложений под каждый бренд, что вело к росту затрат на разработку и поддержку.
Мной было принято решение о переходе к единой масштабируемой платформе с конфигурируемой логикой. Общие модули: каталог, поиск, карточка товара, корзина, оформление заказа, интеграция с серверными сервисами — были унифицированы, различия реализованы через конфигурации интерфейса и бизнес-правила. Это позволило примерно в три раза сократить затраты на разработку и сопровождение, сохранив возможность развивать приложения каждого бренда независимо.
Эффект стал заметен уже на этапе перехода на новую архитектуру. На Android после начала миграции в апреле 2022 года количество сбоев сначала сократилось примерно в 8 раз, а после полного завершения внедрения в сентябре 2022 года — уже в 24 раза по сравнению с исходным уровнем. На iOS после начала перехода в октябре 2022 года количество сбоев снизилось примерно в 12 раз, а после полной раскатки архитектуры в июле 2023 года — в 36 раз.
Одновременно были практически устранены ошибки бизнес-логики. Время запуска приложения сократилось до менее одной секунды на обеих платформах, отображение каталога стало практически мгновенным вместо 3 —5 секунд. За счет кэширования данных и оптимизации работы с сетью существенно повысилась стабильность приложения при нестабильном мобильном интернете. Это отразилось и на пользовательских оценках: на iOS рейтинг вырос с 4,6 до 4,8, на Android — с 4,2 до 4,8.
Были ли в вашей практике проекты, где критичными стали требования к безопасности и ограничению среды устройства?
Да, например, я работал над корпоративным приложением для проведения опросов с повышенными требованиями к защите данных.
Ключевая задача заключалась в том, чтобы исключить возможность использования устройства вне приложения: ограничить выход из рабочей среды, контролировать доступ к системным функциям и снизить риск вмешательства в процесс сбора данных. Для этого использовался режим контролируемого устройства, при котором пользователь мог работать только в рамках заданного сценария приложения без доступа к сторонним функциям устройства.
Отдельное внимание уделялось защите данных на самом устройстве. Данные опросов сохранялись локально в зашифрованной базе данных, а ключи шифрования хранились в защищенном хранилище устройства. Такой подход позволял безопасно поддерживать офлайн-режим: приложение продолжало работать без постоянного доступа к интернету, а собранные данные оставались защищенными до момента контролируемой передачи.
Передача данных на сервер не выполнялась автоматически при появлении сети. Синхронизация запускалась только в определенных точках и только пользователем с административными правами: администратор входил в защищенный режим, вводил пароль и вручную подтверждал отправку данных. Это позволяло контролировать момент передачи, исключать несанкционированную отправку и сохранять управляемость процесса сбора информации.
В результате мне удалось обеспечить целостность данных, снизить риск искажения результатов и сохранить стабильную работу приложения даже в условиях нестабильного подключения к сети.
Как в таких системах проявляется эффект от генеративного искусственного интеллекта?
Наибольший эффект он дает в задачах с повторяемыми паттернами: типовые экраны, шаблонные сценарии, вспомогательный код, тестирование отдельных модулей.
В моих проектах уровня «Озерки» это ускоряет сопровождение существующей кодовой базы. По внутренней оценке, использование ИИ-инструментов в анализе кода, подготовке тестовых сценариев и ревью помогло снизить количество повторяющихся дефектов примерно на 35 процентов.
Любое решение, предложенное системой, проходит архитектурную проверку, что снижает риск накопления технического долга.
Есть ли в вашей практике примеры сложных инженерных продуктов вне корпоративных систем?
Да, Speaker Box Lite — мобильное приложение для проектирования акустических систем, предназначенное для профессиональных аудиоинженеров и энтузиастов акустики.
Это мой продукт, который объединяет инженерные расчёты, моделирование акустических характеристик, построение трёхмерных моделей и подготовку чертежей для изготовления. По сути, это инженерная система, перенесённая в мобильную среду.
Одной из ключевых задач стала реализация математической модели симуляции поведения динамика в корпусе по модели 1D Duct, а также преобразование трёхмерной модели акустического короба в одномерную модель для симуляции распространения звуковых волн. Это потребовало объединения математических моделей, 3D-логики и пользовательского интерфейса в единую архитектуру, пригодную для мобильного устройства с ограниченными ресурсами.
Как в вашей роли меняется баланс между генерацией кода и архитектурными решениями?
Часть рутинной разработки уходит в автоматизацию, но полный цикл разработки нельзя передавать искусственному интеллекту. Любой сгенерированный код должен проверяться и дорабатываться техническим лидером.
Архитектурные решения — структура системы, взаимодействие модулей, масштабируемость — ИИ самостоятельно принимать не может. Технический лидер должен задавать архитектуру и рамки использования ИИ в проекте.
По моему опыту, генеративные системы плохо справляются с нестандартными задачами, аналитической геометрией и сложными алгоритмами. Большие задачи тоже работают хуже: их необходимо декомпозировать на небольшие части. Чем точнее разбивка, тем качественнее результат. С ростом автоматизации возрастает и роль технического лидера, который отвечает за качество реализации и целостность архитектуры.
Как трансформируется роль разработчика в корпоративной мобильной разработке?
Роль смещается от написания кода к управлению архитектурой и системой решений.
В проектах уровня «Озерки» важно не просто реализовать функциональность, а обеспечить устойчивость системы при росте нагрузки и расширении функционала.
Архитектура определяет стоимость сопровождения продукта, поэтому ключевая компетенция разработчика сегодня — проектирование системы.
Как внедрение генеративного искусственного интеллекта влияет на структуру команды разработки?
За счет автоматизации рутинных задач для выполнения того же объема работы требуется меньше разработчиков. Если раньше проекту могли понадобиться четыре разработчика среднего уровня и два ведущих разработчика, то сегодня аналогичный объем задач могут закрывать два сильных ведущих разработчика с ИИ-инструментами. Это не обязательно ведет к сокращению команд. Чаще появляется возможность разбивать разработку на небольшие изолированные направления и параллельно запускать больше задач.
При этом усиливается роль технических лидеров: они отвечают за архитектуру, качество реализации и контроль технического долга.
Еще один эффект — снижение потребности в начинающих разработчиках. Раньше именно им отдавали типовые задачи, которые теперь частично автоматизированы. В перспективе это может привести к дефициту опытных инженеров.
