Я сократил время разработки Android вдвое с помощью ИИ — вот как это сделать

Лучшие программисты не просто немного лучше хороших. Они на порядок лучше, независимо от критериев: концептуальная креативность, скорость, изобретательность дизайна или способность решать проблемы, — Рэндалл Э. Стросс, «Путь Microsoft»

В ноябре прошлого года я потратил целый день  на написание ViewModel для экрана профиля пользователя. Управление состоянием, обработка ошибок, логика повторных попыток, внедрение Hilt — вся необходимая настройка для продакшена. Четыре часа работы, 280 строк кода на Kotlin.

На следующей неделе я описал те же требования ИИ-помощнику в структурированном запросе. Проверил и адаптировал результат. Выпустил за 47 минут.

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

Этот момент изменил мой подход к разработке Android-приложений. Не потому, что ИИ написал идеальный код — это не так — а потому, что он избавил меня от часов, потраченных на перевод уже известных архитектурных паттернов в шаблонный код, который я писал сотни раз до этого.

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

Проблема: 30% вашего рабочего дня не приносит никаких результатов

Вот как выглядит типичный рабочий день Android-разработчика:

• Написание шаблонного кода ViewModel + Repository + DAO в 50-й раз
• Поиск на Stack Overflow того самого граничного случая жизненного цикла фрагмента
• Отладка LaunchedEffect, который срабатывает дважды при ротации
• Написание модульных тестов, которые повторяют один и тот же шаблон настройки моков в 20 файлах
• Превращение Java-класса в идиоматический Kotlin (снова)

Опрос GitHub 2023 года показал, что разработчики тратят 28% своего времени на повторяющиеся задачи, которые не приводят к поставке новых функций. В частности, в Android эта цифра возрастает из-за площади платформы — управление жизненным циклом, изменения конфигурации, потоки разрешений, фоновые API.

Старый рабочий процесс выглядел так:

Read spec → Search for similar code → Copy from Stack Overflow → Modify for your project → Debug → Test → Repeat

Версия с поддержкой ИИ:

Read spec → Describe what you need with project context → Review generated code → Adapt → Test → Ship

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

Как выглядит внедрение контекста на практике

ИИ-помощники не знают ваш проект. Общий запрос типа «Как получить данные из API?» выдает общий код, который вы не сможете использовать.

Вот что выдает пригодный для использования результат.

Неясный промпт:

How do I fetch data from an API?

Контекстно-ориентированный промпт, генерирующий готовый к выпуску код:

I need a ViewModel that:
- Fetches user profile data using Retrofit
- Uses Hilt for dependency injection
- Manages loading, success, and error states with sealed classes
- Implements retry logic (3 attempts, exponential backoff)
- Follows our MVVM + Repository pattern

Our repository layer uses:
- Retrofit 2.9 for API calls
- Room 2.6 for local caching
- DataStore for preferences
- Kotlin coroutines with viewModelScope
Generate the ViewModel with proper error handling.

Второй промпт генерирует код, который я могу просмотреть, подправить и смерджить  за 15 минут. Первый же генерирует туториал, которое мне еще предстоит переписать с нуля.

Шаблон: сообщите ИИ свою архитектуру, свой стек и свои ограничения — затем запросите конкретный фрагмент кода.

Три примера использования, где ИИ сэкономил мне часы

1. Разработка функции: процесс аутентификации за 90 минут

Моей команде требовался процесс входа/регистрации: два экрана, хранилище токенов, биометрическая разблокировка, обновление сессии.

Я описал каждый компонент в контексте нашего проекта. ИИ сгенерировал:

• LoginViewModel и SignupViewModel с классами с sealed состояниями
• AuthRepository с зашифрованной обработкой токенов с использованием EncryptedSharedPreferences
• Compose экраны с состояниями загрузки/ошибки
• Настройка биометрического запроса с помощью BiometricManager

Общее время: 90 минут от спецификации до запроса на слияние.

Предыдущий базовый показатель для аналогичных функций: 5–6 часов. Это сокращение на 70% — не потому, что ИИ написал идеальный код, а потому, что он обработал структурный шаблон, пока я сосредоточился на бизнес-логике и граничных случаях.

2. Миграция устаревшего кода: Java в Kotlin + Compose

У нас был вспомогательный модуль на Java объемом 4000 строк кода 2019 года. Его ручная конвертация заняла бы целый спринт.

Я передал Claude разделы с инструкциями: «Преобразовать в идиоматический Kotlin. Заменить AsyncTask на корутины. Заменить Handler(Looper.getMainLooper()) на Dispatchers.Main. Отметить все устаревшие API».

ИИ обнаружил три случая использования AsyncTask, два шаблона IntentService (заменены на WorkManager) и один вызов LocalBroadcastManager. Каждая конвертация сопровождалась объяснением того, почему старый шаблон устарел.

Мы завершили миграцию за 3 дня вместо предполагаемых 2 недель. На 85% быстрее.

3. Расследование ошибки: утечка памяти в продакшене

Система отслеживания сбоев обнаружила утечку памяти, связанную с фрагментом, содержащим ссылку на RecyclerView.Adapter после onDestroyView.

Я вставил трассировку стека и код фрагмента в ИИ. В течение 30 секунд он определил проблему: ссылка на адаптер не обнулялась в onDestroyView, и ViewBinding поддерживала всю иерархию представлений в активном состоянии.

Он предложил решение, объяснил, почему имеет смысл делать binding = null в onDestroyView, и сгенерировал базовый класс фрагмента, который обрабатывал этот шаблон для всех будущих фрагментов.

Общее время отладки: 8 минут. Моя предыдущая оценка для поиска той же утечки: 2–3 часа.

Где ИИ терпит неудачу (будьте честны в этом вопросе)

ИИ — это не senior-разработчик. Вот где он постоянно терпит неудачу:

• Архитектурные решения — Он будет генерировать код для любого описанного вами шаблона, даже если этот шаблон не подходит для вашего случая. Он не будет возражать и говорить: «Здесь следует использовать StateFlow вместо LiveData», если вы его об этом не попросите.
• Ключевой для производительности код — Он генерирует функционально корректный код Compose, который перекомпоновывается 40 раз за кадр. Вам все равно нужно самостоятельно проводить профилирование, измерения и оптимизацию.
• Безопасность — Он будет хранить токены в SharedPreferences, если вы не укажете EncryptedSharedPreferences. Он не думает об угрозах.
• Ограничения контекстного окна — Передайте ему модуль из 2000 строк, и он потеряет связь с предыдущим кодом. Разбивайте задачи на сфокусированные фрагменты.
• Галлюцинаторные API — Я видел, как он генерировал Flow.collectAsStateWithLifecycle() с неправильными сигнатурами параметров. Всегда сверяйтесь с официальной документацией.

Правило: ИИ отвечает за «как» — вы отвечаете за «что» и «почему».

Распространенные ошибки при внедрении ИИ

Расплывчатые промпты приводят к созданию мусора. Если вы не укажете свою архитектуру, фреймворк внедрения зависимостей и уровень API, вы получите код, который не подходит для вашего проекта. Потратьте 2 минуты на написание контекста. Это сэкономит 20 минут на переписывании.

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

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

Начните работу на этой неделе

Вам не нужен собственный конвейер ИИ. Начните с этих трех шагов:

Шаг 1 — Выберите инструмент. GitHub Copilot для автозавершения кода в IDE, Claude или ChatGPT для генерации кода в диалоговом режиме. Cursor IDE объединяет оба варианта. Ежемесячная стоимость: 10–20 долларов.

Шаг 2 — Опишите контекст вашего проекта. Создайте Markdown файл , описывающий вашу архитектуру, технологический стек, стандарты кодирования и распространенные шаблоны. Вставляйте его в начало каждого диалога. Этот единственный шаг в 10 раз повышает качество результата.

// Example: your project context summary
val projectContext = """
    Architecture: MVVM + Repository
    DI: Hilt
    UI: Jetpack Compose (Material 3)
    Networking: Retrofit 2.9 + OkHttp
    Database: Room 2.6 with Kotlin Flow
    Async: Coroutines + viewModelScope
    Min SDK: 28, Target SDK: 35
""".trimIndent()

Шаг 3 — Начните с тестов. Создание модульных тестов — это самый простой и эффективный стартовый шаг. Опишите вашу ViewModel, скопируйте класс, запросите тестовые примеры. За один день вы увеличите покрытие кода с 10% до 60% и более.

Математика, которая убедила мою команду

Почасовая стоимость Senior Android-разработчика: 85-150 долларов
Экономия времени в день благодаря ИИ: 2-3 часа
Стоимость инструментов ИИ в день: 0,50-3,00 доллара
Чистая экономия в день: 170-450 долларов
Чистая экономия в месяц: 3400-9000 долларов

Инструмент окупается ещё до обеда в первый же день.

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

ИИ не заменил мои инженерные навыки. Он избавил меня от ежедневной платы за перевод этих навыков в код. Шаблоны уже были у меня в голове. ИИ занимается набором текста.

Какая самая повторяющаяся задача в вашем рабочем процессе Android прямо сейчас? С этого и нужно начать. Попробуйте это на одной функции на этой неделе и измерьте разницу.

Источник