90 приложений за год: реальный опыт использования ИИ для мобильной разработки

Разработчик издал более 90 мобильных приложений за год, активно используя ИИ-ассистентов, и делится выводами о том, где искусственный интеллект действительно ускоряет работу, а где без человека всё равно не обойтись.

ИИ-ассистенты для кодирования не заменили ту часть работы, которая требует суждения. Они заменили ту часть, которая требовала терпения.

В последнее время появилось много шума вокруг ИИ-инструментов для программирования: кто-то в восторге, кто-то скептически хмыкает. Один независимый разработчик решил проверить на практике, что из этого — реальность, а что — маркетинг. За год он выпустил более 90 мобильных приложений, и большинство из них созданы с существенной помощью ИИ-ассистентов, в основном Claude Code. Важно понимать, что речь не о 90 стартапах с разными командами, а о небольших, часто узкоспециализированных утилитах и играх, сделанных одним человеком. Его опыт — ценный повод разобраться, как на самом деле выглядит работа мобильного разработчика в эпоху ИИ.

Главный прорыв — не в скорости печати кода

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

Разработчик перестал воспринимать ИИ-агента как продвинутый автодополняющий инструмент и начал обращаться с ним как с младшим инженером, который никогда не устаёт от рутинных задач. Именно такой подход сделал возможным «портфельный» выпуск десятков приложений. Вручную поддерживать 90 кодовых баз один человек физически не может. Но один человек плюс агент, которому можно указать на репозиторий и сказать: «Сборка сломана, исправь», — может.

Настоящая сложность — в публикации в магазинах

Написание самого приложения никогда не было узким местом. Настоящая головная боль — это требования App Store Connect и Google Play Console. У обеих платформ есть десятки мелких, легко упускаемых из виду условий, которые никак не связаны с тем, работает ли ваш код:

• Для приложения с подпиской в описании должна быть ссылка на лизионное соглашение (EULA), иначе скрипт автоматически отклонит заявку ещё до того, как её увидит живой человек.
• Бесплатные пробные периоды, настроенные только для части регионов, пройдут ревью в одной стране, но выдадут ошибку покупки в другой.
• Удаление записи приложения в App Store Connect не освобождает идентификатор пакета (bundle ID) — он резервируется навсегда, что критично при быстрых итерациях.
• Классификатор Google Play может заблокировать приложение из-за упоминания в описании фразы вроде «читает системные логи Android», даже если запрашиваемое разрешение используется совершенно безобидно. А процесс обжалования не очевиден.

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

ИИ отлично находит скучные баги, которые вы бы пропустили

Наибольший урон наносили не ошибки в бизнес-логике, а совсем другие вещи. Например, оставшаяся от удалённого плагина зависимость от старого рекламного SDK, вызывающая краш только при холодном запуске на определённых версиях Android. Или проверка локали, которая работала на всех симуляторах, но давала сбой на реальных японских устройствах из-за неожиданного поведения реализации Intl в JS-движке.

Здесь ИИ-агент был полезен не хитроумием, а упорством и широтой охвата. Можно попросить его просканировать все 90 репозиториев в поисках конкретной антипаттерна — незадействованной зависимости, захардкоженного URL тестового сервера, несовпадающих иконок между лаунчером и описанием в магазине — и получить ответ за минуты вместо того, чтобы провести выходные, выполняя поиск вручную. Ценность такого подхода растёт именно с увеличением портфеля приложений: для трёх приложений это было бы просто «поиск и замена с дополнительными шагами».

Где автор до сих пор не доверяет ИИ-агенту полностью

Разработчик честно признаёт ограничения, и это важная часть картины:

• Всё, что связано с реальными деньгами — настройка внутриигровых покупок, цен на подписки, вебхуки Stripe — каждый раз проходит ручную проверку. ИИ хорошо сопоставляет паттерны из прошлых ошибок, но не способен поймать неправильную цену, если ему точно не сказать, что проверять.
• Деструктивные операции (принудительные пуши в Git, миграции баз данных, удаление записей, блокирующих ревью) никогда не делегируются полностью. Автор придерживается жёсткого правила: «агент предлагает, я одобряю» для любого необратимого действия.
• Долгие или нестабильные внешние процессы — сборка, которая периодически падает из-за общей временной директории, или CDN-кэш, который врёт о завершении распространения, — по-прежнему требуют человека, который заметит закономерность.

Что сделало эту модель устойчивой

Из всего опыта выделяются два ключевых привычки, оказавшихся важнее любого конкретного инструмента:

1. Фиксировать причины сбоев в письменном виде — в обычных файлах, которые агент может прочитать потом, а не полагаться на память. Если заявка во второй раз отклоняется по той же причине — это уже ошибка в процессе, а не случайность.
2. Считать верификацию обязательным этапом. Сообщение агента «сборка успешна» — это не доказательство чего-то, кроме того, что компилятор не выдал ошибок. Автор научился требовать реальную проверку артефакта: загружен ли бинарный файл, отражается ли он в списке магазина, запускается ли приложение — и только потом считать задачу выполненной.

Честный итог такой: ИИ-ассистенты для кодирования не заменили ту часть работы разработчика, которая требует профессионального суждения и ответственности. Они прекрасно справились с другой частью — той, что требовала кропотливости и внимательности. Это чтение каждой строчки в сотне строк изменений, запоминание, какое из 90 приложений всё ещё использует устаревшее разрешение, повторное выполнение одного и того же 15-шагового чек-листа для отправки в магазин без пропуска шага №11 от усталости.

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