Kotlin + Jetpack Compose: 12 промтов, которые заменяют Android-команду в дедлайн

Kotlin + Jetpack Compose: 12 промтов, которые заменяют Android-команду в дедлайн

Соло-разработчик Android в 2026 году — уже не экзотика. Kotlin стал основным языком платформы (Google объявила его таковым ещё в 2019 году), Jetpack Compose заменил XML-верстку в большинстве новых проектов, а Coroutines и Flow превратили асинхронность в читаемый код. Но есть нюанс: один человек физически не может одновременно проектировать UI, писать слой данных на Room, разбираться с состоянием и не забывать про миграции базы.

Здесь и включается LLM-ассистент. Не как «умный автокомплит», а как спарринг-партнёр, который держит контекст всего проекта. Проблема в том, что большинство промтов вида «напиши мне экран на Compose» дают бесполезный результат: код компилируется, но не следует идиомам Compose, путает remember с rememberSaveable, а Flow собирает в неправильном scope.

Ниже — 12 промтов, которые я оттачивал на реальных проектах. Каждый заточен под конкретную задачу: от генерации архитектурного скелета до отладки recomposition. Они дают код, близкий к тому, что писал бы опытный Android-инженер, и экономят часы на рутине. Официальные источники, на которые стоит опираться при проверке результатов: developer.android.com/compose, kotlinlang.org/docs/coroutines-guide.html, developer.android.com/training/data-storage/room.

Как пользоваться этой подборкой

Все промты построены по схеме проблема → решение → результат. Подставляйте свои значения в квадратные скобки. Если модель начинает «галлюцинировать» API, добавьте в конец промта: «Используй только стабильные API из androidx.compose.* и не выдумывай методы». Это резко снижает процент несуществующих функций.

Промт 1: Архитектурный скелет под соло-разработку

Для чего: когда начинаете проект с нуля и не хотите через месяц переписывать слои.

Ты — senior Android-инженер. Спроектируй структуру пакетов для
приложения [название] с одним разработчиком.
Стек: Kotlin, Jetpack Compose, Hilt, Room, Retrofit, Coroutines/Flow.
Требования:
- Clean-ish architecture без оверинжиниринга (не плоди UseCase на каждый чих)
- Разделение: data / domain / ui
- Покажи дерево пакетов и объясни, где что лежит
- Назови 3 типичные ошибки, которые допускают в такой структуре

Почему работает: модель вынуждена обосновать каждое решение, а не просто выдать шаблон. Кейс: на проекте-трекере привычек я получил дерево пакетов за 10 минут вместо обычного дня раздумий, и оно продержалось до релиза без крупных правок.

Промт 2: Идиоматичный экран на Compose

Для чего: генерация UI, который не стыдно показать на код-ревью.

Напиши Composable-экран на Jetpack Compose для [описание экрана].
Правила:
- Stateless-компонент + отдельный Stateful-враппер
- Состояние через immutable data class
- Превью (@Preview) с фейковыми данными
- Без бизнес-логики внутри Composable
- Используй Material 3
Покажи, как экран вызывается из NavHost.

Почему работает: разделение stateless/stateful — ключевая идиома Compose, которую новички игнорируют. Модель по умолчанию её тоже пропускает, поэтому её надо явно требовать.

Промт 3: Тема и дизайн-система

Для чего: быстро собрать согласованную тему Material 3.

Сгенерируй тему Material 3 для бренда с цветами:
primary [HEX], secondary [HEX], background [HEX].
Нужно:
- ColorScheme (light и dark)
- Типографика с 3 кастомными стилями
- Пример использования в Composable
- Объясни, почему НЕ стоит хардкодить цвета в экранах

Почему работает: заставляет модель связать палитру с системой токенов, а не выдать список Color. Это спасает от «зоопарка» цветов в больших проектах.

Промт 4: Дебаг лишних recomposition

Для чего: когда UI лагает, а виновник неизвестен.

Мой Composable [код] вызывает лишние recomposition.
Помоги найти причину. Проверь:
- Unstable-типы в параметрах (List вместо ImmutableList)
- Лямбды, создаваемые заново
- Чтение State внутри Composable, который мог бы быть stateless
Дай исправленный код и объясни, как проверить через
Layout Inspector и Compose Compiler Metrics.

Почему работает: Compose Compiler Metrics — реальный инструмент, и он позволяет доказать, что проблема в нестабильных типах. Без этого промта отладка превращается в гадание.

Промт 5: Состояние экрана без утечек

Для чего: правильные rememberSaveable, collectAsStateWithLifecycle и обработка конфигураций.

Покажи, как хранить состояние экрана [описание], чтобы оно
выживало при повороте и не терялось в фоне.
Сравни: remember, rememberSaveable, ViewModel.
Покажи сбор Flow через collectAsStateWithLifecycle и объясни,
почему НЕ через collectAsState.

Почему работает: collectAsStateWithLifecycle из lifecycle-runtime-compose учитывает жизненный цикл и не жрёт батарею. Многие об этом не знают — модель напомнит и обоснует.

Промт 6: Слой данных на Room

Для чего: сущности, DAO и миграции без боли.

Спроектируй Room-базу для [описание данных].
Нужно:
- @Entity с индексами
- DAO с Flow-запросами и suspend-вставками
- TypeConverter для [тип]
- Пример миграции с версии 1 на 2
Объясни, когда использовать Flow, а когда suspend-функцию.

Почему работает: Room + Flow — стандартная связка, но миграции все пишут с ошибками. Модель выдаёт рабочий Migration-объект, который можно сразу проверить.

Промт 7: Repository поверх Room и сети

Для чего: единый источник правды без дублирования.

Напиши Repository, который отдаёт данные из Room,
а при отсутствии — тянет из API и кэширует.
Стек: Room, Retrofit, Flow.
Покажи обработку ошибок через sealed class Result.
Объясни паттерн single source of truth.

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

Промт 8: Coroutines без race conditions

Для чего: асинхронный код, который не падает в проде.

Проверь мой код на Coroutines [код] на предмет:
- Неправильного scope (GlobalScope, lifecycleScope)
- Отсутствия обработки CancellationException
- Параллельных запросов через async без awaitAll
- Утечек через SupervisorJob
Предложи исправленный вариант с комментариями.

Почему работает: CancellationException нельзя глотать — это частая ошибка. Модель находит её в коде и объясняет, почему catch(e: Exception) ломает отмену.

Промт 9: Тесты для ViewModel

Для чего: быстрые unit-тесты без эмулятора.

Напиши unit-тесты для ViewModel [код] с использованием
kotlinx-coroutines-test (runTest, StandardTestDispatcher).
Покажи:
- Тест успешного сценария
- Тест ошибки
- Тест отмены корутины
Объясни, почему нельзя использовать runBlocking в тестах.

Почему работает: runTest и StandardTestDispatcher — официальный подход с 2021 года. Промт фиксирует это и убирает вечный Thread.sleep из тестов.

Промт 10: Рефакторинг XML-экрана в Compose

Для чего: миграция legacy-верстки без переписывания всего сразу.

У меня есть XML-разметка [код] и Activity [код].
Переведи это в Compose пошагово:
1. Соответствие View → Composable
2. Как перенести состояние
3. Как встроить ComposeView в существующий XML (если нужно)
Покажи финальный код.

Почему работает: Compose можно внедрять инкрементально через ComposeView — это официально поддержанный путь, и промт его использует.

Промт 11: Миграции и версионирование базы

Для чего: обновить схему без потери данных пользователей.

У меня Room база версии [N]. Нужно добавить поле [поле]
и новую таблицу [таблица] без потери данных.
Напиши Migration, обнови @Database(version = N+1),
покажи, как протестировать миграцию через MigrationTestHelper.

Почему работает: MigrationTestHelper — реальный класс из room-testing. Промт даёт не только код миграции, но и способ её проверить до релиза.

Промт 12: Финальное код-ревью перед релизом

Для чего: пройтись по проекту глазами сеньора за час.

Проведи код-ревью Android-проекта по фрагментам [код].
Ищи:
- Утечки контекста (Activity в ViewModel)
- Тяжёлые операции в главном потоке
- Отсутствие обработки ошибок сети
- Хардкод строк вместо stringResource
- Проблемы с ProGuard/R8
Дай список с приоритетами: critical / major / minor.

Почему работает: приоритезация превращает поток замечаний в план действий. На реальном проекте такой прогон выявил утечку Activity через ViewModel, которую не поймал линтер.

Что в итоге

Промты не пишут приложение за вас — они убирают рутину и заставляют модель следовать идиомам Kotlin и Compose, а не выдавать усреднённый код из интернета. Главное правило: всегда проверяйте результат на реальных API и запускайте тесты. LLM отлично генерирует структуру, но ответственность за корректность остаётся на разработчике.

Начните с промтов №1 и №12 — они дают максимальный эффект при минимальных усилиях. А если хотите глубже разобраться в Coroutines, Room и архитектуре Android — посмотрите материалы на asibiont.com, где теория подаётся через практические задачи, а не сухие слайды.