Мастерская декомпозиция: как правильно ставить задачи AI-ассистенту для Android-разработки (и не только)

Почему ваш AI-ассистент тупит? (И это не его вина)

Вы открываете Cursor, Claude Code или ваш локальный AI-монстр. Пишете: "Сделай экран логина для Android приложения". Ждете. Получаете код, который выглядит сносно, но не компилируется. Или компилируется, но не работает с вашей архитектурой. Или работает, но выглядит как код 2018 года.

Вы тратите час на правки. Злитесь. Пишете гневный промпт. Цикл повторяется.

Проблема не в модели (даже если вы используете не самый свежий GLM-4.7 или LFM 2.5). Проблема в том, как вы с ней разговариваете. Вы даете ИИ задачу уровня директора, а ожидаете работы senior-разработчика.

Сосредоточенная декомпозиция: методология, которая экономит часы

Мы отказались от поэтапного планирования (где ИИ сначала пишет план, потом код). На практике это порождает две проблемы: план получается абстрактным, а код не следует плану. Вместо этого мы используем сосредоточенную декомпозицию.

Суть: вы разбиваете задачу на атомарные, изолированные шаги. Каждый шаг — это отдельный, законченный запрос к агенту. Контекст между шагами передаете вы, а не он.

1 Декомпозируй, как для джуна

Представьте, что вы объясняете задачу junior-разработчику, который знает синтаксис, но не понимает контекста проекта.

Как НЕ надо: "Добавь экран профиля пользователя с аватаром, именем и историей операций."

Почему это плохо? Агент начнет гадать. Какой стек? Jetpack Compose или XML? Какая архитектура? MVVM, MVI? Как интегрировать с существующим кодом? Он сделает предположения. 90% этих предположений будут неверными.

Как надо: Разбейте на атомарные шаги. Каждый шаг — это конкретное, проверяемое действие.

1. "Создай новый Composable функцию с именем UserProfileScreen. Функция должна принимать один параметр типа User (data class уже определена в пакете model). Добавь пустой Box для контента."
2. "Внутри UserProfileScreen добавь Column. Вверху Column размести круглый Image (используй rememberCoilPainter) для аватара. URL аватара берется из user.avatarUrl. Размер изображения — 64.dp."
3. "Под изображением добавь Text для отображения user.fullName. Используй стиль MaterialTheme.typography.h6. Отступ сверху — 8.dp."
4. "Ниже добавь LazyColumn для списка операций. Операция — это data class Transaction в пакете model. Покажи просто Text с transaction.description и transaction.amount."

Звучит многословно? Да. Но это занимает 2 минуты на написание. Экономит 40 минут на переделку.

2 Контекст — ваш козырь. Не доверяйте его агенту

Современные агенты, особенно с подключением через MCP (как в системе Second Brain), умеют читать код проекта. Это ловушка.

Вы думаете: "Он видит, что у нас используется Hilt для DI, значит, внедрит зависимости правильно". Агент видит Hilt. Но также видит 10 других способов внедрения зависимостей в коде (потому что проект большой и legacy). Он выберет случайный. Или придумает свой.

Правило: Явно передавайте архитектурный контекст в каждом запросе, где это критично.

// Вместо: "Создай ViewModel для экрана логина"
// Пишите:
"Создай класс LoginViewModel, который extends BaseViewModel из пакета core.mvvm.
Используй StateFlow для состояния (uiState).
Используй инжектированный LoginUseCase из пакета domain.useCases.
Обработай ошибки через sealed класс Result."

Вы — единственный источник истины о проекте. Агент — исполнитель. Не надейтесь, что он "поймет" ваши conventions.

3 Технические спецификации: запрещайте импровизацию

Android-разработка в 2026 — это не только Kotlin и Compose. Это специфичные версии библиотек, правила линтинга, требования безопасности (особенно в банковских приложениях).

Без этих указаний агент сгенерирует код, который не пройдет code review. Вы потратите время на замечания типа "используй rememberUpdatedState вместо remember" или "этот метод deprecated с API 33".

Реальный кейс: платежный модуль за 3 часа вместо 2 дней

Наша команда в банке получила задачу: добавить экран подтверждения перевода с динамическим расчетом комиссии. Раньше на это ушло бы 2 дня (дизайн, верстка, логика, тесты).

Сосредоточенная декомпозиция заняла 3 часа. Вот как мы разбили задачу для AI-ассистента:

• Шаг 1 (UI-каркас): "Создай Composable ConfirmTransferScreen с параметрами recipientName, amount. Используй Scaffold с TopAppBar. В content размести Column с отступами 16.dp."
• Шаг 2 (Блоки данных): "Внутри Column создай 3 Card-компонента. Первый Card для получателя (иконка + текст). Второй Card для суммы перевода (большой Text). Третий Card для комиссии."
• Шаг 3 (Логика комиссии): "Создай функцию calculateFee(amount: Double, isUrgent: Boolean): Double. Комиссия 0.5% для обычных, 1% для срочных. Добавь переключатель (Switch) для isUrgent, который пересчитывает комиссию."
• Шаг 4 (ViewModel): "Создай ConfirmTransferViewModel с useCase CalculateFeeUseCase. Реализуй логику обновления комиссии при изменении amount или isUrgent."
• Шаг 5 (Интеграция): "Свяжи ConfirmTransferScreen с ViewModel через hiltViewModel(). Обработай состояния загрузки через uiState."

Каждый шаг — отдельный промпт. После каждого шага — проверка. Агент не перегружен. Не теряет контекст. Не импровизирует.

Ошибки, которые сведут на нет всю методологию

Даже с идеальной декомпозицией можно облажаться. Вот что убивает эффективность:

1. Экономия на промптах. "Сделай похоже на тот экран" — не работает. Агент не понимает "похоже". Он либо скопирует код один в один (со всеми багами), либо сделает что-то свое. Потратьте 30 секунд, чтобы описать конкретные отличия.

2. Игнорирование зависимостей. Вы просите создать репозиторий, но не говорите, откуда брать данные (Room, Retrofit, мок). Агент выберет самый простой путь — заглушку. Потом вы тратите время на переделку.

3. Отсутствие примеров кода. Если в проекте есть устоявшийся паттерн (например, обработка пагинации), дайте агенту ссылку на существующий файл. "Сделай как в TransactionRepository, но для UserRepository". Это работает лучше абстрактных описаний.

4. Попытка сделать "идеально" с первого раза. Это нереально. Методология не исключает итерации. Она минимизирует количество итераций. Будьте готовы к правкам, но эти правки будут точечными, а не переписыванием всего экрана.

А как же другие инструменты и модели?

Методология работает с любым ассистентом: Cursor, Claude Code, локально запущенный GLM-4.7 через Ollama, даже GitHub Copilot в IDE.

Разница только в одном: более мощные модели (типа Claude 3.7 Sonnet) лучше справляются с чуть менее детализированными промптами. Но суть не меняется. Даже лучшей модели вы должны сказать: "Иди туда, сделай это, вот так".

Для сложных задач, где нужен поиск по кодовой базе или документации, настройте Agent Skills правильно. Но сам процесс выполнения задачи все равно разбивайте на атомарные шаги.

Что в итоге? (Цифры из нашего бэклога)

За последний квартал в команде из 8 Android-разработчиков:

• Время на разработку стандартного экрана сократилось с 6-8 часов до 2-3.
• Количество критических багов, внесенных ИИ (требующих hotfix), упало с 3-4 в месяц до нуля.
• Code review проходят быстрее, потому что код соответствует стандартам с первого раза.
• Самое главное — разработчики меньше раздражаются. Они перестали бороться с агентом и начали им управлять.

Это не магия. Это дисциплина. Вы перестаете требовать от ИИ понимания. Вы начинаете давать инструкции.

Попробуйте завтра. Возьмите небольшую задачу из бэклога. Потратьте 5 минут, чтобы разбить ее на 5-7 атомарных шагов. Дайте агенту первый шаг. Потом второй. Не ждите, что он "сам все поймет".

Вы удивитесь, насколько это просто. И насколько это эффективно.

P.S. Если хотите глубже погрузиться в архитектуру AI-агентов для кода, посмотрите 19-часовой курс по созданию AI Coding Agent. Но предупреждаю: даже самый продвинутый агент не заменит вашу способность декомпозировать задачи. Это ваш навык. ИИ его только усиливает.