От написания кода на Kotlin до управления агентами: новая роль инженера мобильных приложений

Агенты для кодирования больше не ограничиваются простым завершением строки кода. Они исследуют хранилище кода, планируют изменения, редактируют несколько файлов, запускают процесс сборки, анализируют ошибки и пробуют снова. Это ставит перед инженерами, работающими над мобильными приложениями, сложный вопрос: если агент пишет большую часть кода на Kotlin, является ли это всё ещё разработкой для Android или же это уже превратилось в написание запросов внутри IDE? В этой статье утверждается, что ни один из этих определений не подходит, и описывается, во что на самом деле превращается эта роль: составление точных спецификаций, создание условий, в которых работает агент, формулировка архитектурных ограничений и проверка результатов, которые вы сами не вводили.

Приведённые примеры касаются Android, но логика применима и к командам React Native, веб-разработчикам и специалистам по бэкенду, использующим аналогичные инструменты.

Насколько продвинулись ассистенты для кодирования

Классический рабочий процесс в Android хорошо знаком: открываем Android Studio, создаем класс, пишем код на Kotlin, работаем с Gradle, отловляем ошибки через Logcat, тестируем на устройстве и создаем pull request.

Помощь ИИ постепенно вошла в этот процесс. Сначала она заполняла отдельные строки кода, затем целые функции, а потом и всё классы. Современные инструменты действуют как агенты. На момент написания этого текста несколько продуктов прямо описывают такую функциональность:

• Режим агента Gemini в Android Studio принимает высокоуровневую цель разработки, составляет план, вызывает инструменты, редактирует несколько файлов, собирает проект и корректирует действия при возникновении ошибок на каждом этапе.
• Агент Cursor исследует кодовую базу, изменяет несколько файлов, выполняет команды терминала и устраняет ошибки, выполняя задачу целиком, вместо того чтобы предлагать следующую строку кода.

OpenAI Codex работает из терминала в качестве агента для программирования, который читает, модифицирует и выполняет код.

Функциональные возможности продуктов в этой области быстро меняются, поэтому проверьте актуальную документацию того инструмента, который использует ваша команда. Однако направление развития ясно.

Работа перемещается вверх по иерархии

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

Write code
   ↓
Understand code
   ↓
Design architecture
   ↓
Define requirements
   ↓
Make engineering decisions
   ↓
Validate behavior
   ↓
Own the product

Агенты становятся очень умелыми в решении простых задач. Это не делает набор и чтение кода бесполезными, но меняет степень их значимости. Стандартная реализация хранилища, которая вручную требует получаса, может быть создана за секунды. Написание десяти практически идентичных экранов на Compose — трудоемкий процесс вручную; агент может работать с соответствующими файлами и автоматически генерировать повторяющиеся части кода. Простая ошибка компиляции может занять несколько минут вашего времени, тогда как агент сразу читает сообщение об ошибке, находит проблемный участок кода, исправляет его, пересоздает проект и продолжает работу.

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

Хороший запрос — это на самом деле спецификация

Возьмём типичную просьбу от пользователя: добавить очередь загрузки в приложение. Опытный инженер по Android мысленно преобразует эту фразу в слоистую архитектуру:

Database
    ↓
Repository
    ↓
Use Cases
    ↓
ViewModel
    ↓
UI State
    ↓
UI
    ↓
Background execution
    ↓
Notifications

Теперь специалист может реализовать большую часть этой структуры, но качество результата во многом зависит от того, о чём вы просили. Сравните трёхсловную инструкцию (“добавить очередь загрузки”) с чем-то вроде этого:

Создайте очередь, способную выполнять несколько загрузок и сохранять состояние между запусками приложения, с использованием Room и WorkManager для выполнения операций. Отслеживайте прогресс в памяти, вместо того чтобы сохранять каждое обновление в базе данных. При прерывании процесса восстановите задержанные и активные загрузки. ViewModel должен генерировать только для чтения StateFlow. В слое домена не должно быть типов из Android-фреймворка. Проверьте изменения состояния очереди и восстановление после сбоев с помощью тестов на единицы. Не изменяйте объекты Room, которые не связаны с загрузками.

Называть вторую версию «лучшим запросом» — значит недооценивать её. Это техническое описание: в нём указываются технология сохранения данных, механизм фоновой обработки, решение по производительности (не записывать каждое обновление прогресса на диск), требования к устойчивости (выживание при прерывании процесса), контракт API (неизменный StateFlow), правило слоистой структуры, объём тестирования и чётко определённая зона влияния. Каждый из этих пунктов отражает знания Android, которые агент не может вывести из простого запроса «добавить очередь загрузки».

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

Запросы против инженерии

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

Предположим, агент передаёт вам этот ViewModel:

class DownloadViewModel(
    private val repository: DownloadRepository
) : ViewModel() {
    val downloads = repository.downloads
}

Он компилируется и работает без проблем. Однако у опытного разработчика Android всё равно остаётся ряд вопросов перед тем, как принять его:

• Является ли downloads обычным Flow или StateFlow, и что запускает каждый коллектор?
• Где находится единый источник информации о состоянии загрузки?
• Что сохраняется после завершения процесса?
• Запускается ли запись в Room при каждом обновлении прогресса?
• Что происходит, когда две загрузки завершаются одновременно?
• Как моделируется отмена операции?

Может ли WorkManager перезапустить эту задачу, и отражается ли это в состоянии?

Что происходит при потере сети?

Как поведет себя приложение, если пользователь принудительно остановит его?

Является ли хранилище данных безопасным с точки зрения жизненных циклов?

Сохраняются ли одноразовые события интерфейса отдельно от состояния?

Как это работает на устройствах с низкими характеристиками?

Создание класса — простая задача. Сложнее всего работать с системой, связанной с ним, и автоматизировать этот процесс ещё сложнее.

Цикл разработки с использованием агентов

В традиционном цикле разработчик участвует в каждом этапе напрямую:

Requirement
    ↓
Developer writes code
    ↓
Build
    ↓
Error
    ↓
Developer investigates
    ↓
Fix
    ↓
Test
    ↓
PR

При наличии агента посередине цикл меняется. Разработчик задаёт цель в начале и отвечает за проверку и верификацию в конце, тогда как агент занимается исследованием, редактированием и исправлением ошибок в промежуточных этапах:

Developer defines goal
        ↓
AI Agent explores codebase
        ↓
AI creates plan
        ↓
AI modifies files
        ↓
AI runs build/tests
        ↓
AI observes result
        ↓
AI fixes problems
        ↓
Developer reviews
        ↓
Developer validates behavior
        ↓
Ship

В документации производителя описывается аналогичный подход. Режим агента в Android Studio представлен как процесс планирования, вызова инструментов, изменения файлов и последующей обработки результатов. Cursor описывает свой агент как модель, способную к логическим рассуждениям, инструменты, позволяющие ему искать и редактировать файлы или выполнять команды терминала, а также цикл, в котором агент наблюдает за результатами и выбирает следующий шаг. Это уже не автодополнение; это скорее делегирование части инженерных задач.

Интегрированная среда разработки как слой оркестрации

Такое изменение меняет назначение Интегрированной среды разработки. Раньше она служила рабочим столом для одного разработчика. На момент написания текста инструменты ИИ в Android Studio предоставляют такие возможности, как:

• Режим агента
• несколько параллельных диалогов с агентами
• соединения с сервером MCP
• инструкции в формате AGENTS.md на уровне проекта
• доступ к знаниям, специфичным для Android

поиск в интернете

специализированные навыки

управление разрешениями

проверка на эмуляторе

Google представляет режим Agent Mode как инструмент для выполнения задач многоступенчатой разработки и предлагает серверы MCP и файл AGENTS.md в качестве способов его расширения и управления. IDE больше не является лишь местом для написания кода на Kotlin — он превращается в среду для запуска и контроля инженерной работы с помощью ИИ.

Основы становятся ещё важнее

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

Kotlin

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

Flow
StateFlow
SharedFlow
coroutines
structured concurrency
inline functions
sealed classes
value classes
delegation
generics
null safety

Цель не в том, чтобы самим писать каждую строку кода. Цель — замечать, когда генерируемый Kotlin имеет скрытые ошибки, например, использование режима «горячего потока», когда требуется режим «холодного потока», или запуск корутин вне структурированной конкурентности.

Платформа Android

Именно в поведении платформы генерируемый код чаще всего кажется корректным, но терпит неудачу в реальных условиях использования:

Lifecycle
Process death
Configuration changes
Services
WorkManager
Room
Navigation
Permissions
Storage
Background execution
Notifications
Compose
Views
Performance

Агент может создать класс Worker за несколько секунд. Однако это ничего не говорит о том, соблюдает ли этот рабочий процесс жизненный цикл приложения, требования к повторным попыткам и ограничениями.

Архитектура как ограничения агента

Знания в области архитектуры приобретают новое назначение. Такие паттерны, как MVI и MVVM, Clean Architecture, границы модулей, репозитории, DI, обработка состояния и разделение доменов, — это не просто способы организации кода; они становятся ограничениями, которые вы передаёте агенту. Вместо фразы «создать функцию» можно дать указания следующего типа:

Создайте эту функцию, следуя нашей существующей архитектуре MVI. Сохраняйте структуру паттернов из функции A и функции B. Не вводите новых зависимостей. Бизнес-правила должны находиться в слое домена.

Ссылки на существующие функции особенно эффективны, поскольку они указывают агенту на конкретные, проверенные примеры в кодбазе, вместо того чтобы полагаться на его общее представление о «MVI». Архитектура становится частью языка, который вы используете для управления агентами.

Инструкции на уровне репозиториев с AGENTS.md

Многие команды постоянно повторяют одни и те же напоминания на каждой сессии: проект использует Kotlin и Hilt, бизнес-логика не должна находиться в Composables, состояние выражается с помощью StateFlow, применяются правила нумерации, требуются тесты, а генерируемые файлы запрещены к использованию.

Эти требования могут храниться непосредственно в репозитории. На момент написания инструмент Gemini от Android Studio читает файлы AGENTS.md, в которых записаны подобные предпочтения, поэтому агент воспринимает их как контекст проекта. Другие агенты также читают подобные файлы; эту же идею подробно рассматривается в практическом руководстве по созданию эффективного файла CLAUDE.md.

Это небольшое изменение с большими последствиями. Традиционно репозиторий содержал:

source code
configuration
tests
documentation

Теперь он также может содержать:

AI engineering instructions

В кодовой базе описываются как само программное обеспечение, так и способ работы агента с ним. Рассматривайте эти инструкции как код: проверяйте внесенные в них изменения, делайте их краткими и конкретными, а также удаляйте правила, которые больше не применимы.

MCP соединяет агента с остальной частью инструментария

Протокол Model Context Protocol позволяет ИИ-системам подключаться к внешним инструментам и сервисам, что означает, что агент больше не ограничен чат-панелью. Через серверы MCP он может получить доступ к:

GitHub
Databases
Design tools
Documentation
Issue trackers
CI systems
Cloud services
Internal APIs

Инструменты искусственного интеллекта в Android Studio в настоящее время поддерживают подключение к серверам MCP, включая удаленные. Рассмотрим один запрос, в котором агенту предлагается создать новый экран профиля на основе файла Figma, повторно использовать существующие дизайн-токены, подключить этот экран к конечной точке профиля, обработать состояния загрузки и сбоев, добавить тесты и подготовить пул-реквест. Для выполнения этой задачи необходимо одновременно взаимодействовать с множеством систем:

Developer
    ↓
AI Agent
    ├── Figma
    ├── Codebase
    ├── Documentation
    ├── API
    ├── Tests
    ├── Git
    └── CI

Когда инструмент координирует дизайн-файлы, код, документацию, API, тесты, Git и процессы CI, называть его «генератором кода» некорректно. Это инженерный агент, и именно его возможности объясняют важность разрешений и проверок: каждая подключенная система может быть прочитана или изменена агентом.

Ловушка: зависимый, но неспособный

У этой новой схемы есть характерный способ сбоя. Разработчик может стать зависимым от ИИ, не приобретя при этом навыков его использования. Вполне возможно создать код, использующий все эти элементы:

Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel

при этом не понимая, что делает каждый из них. Всё компилируется, работа кажется быстрой, но спустя несколько месяцев в производственной среде возникает проблема конкурентного доступа, связанная с отменой жизненного цикла, которую никто в команде не может объяснить.

ИИ ускорил набор кода, но не сделал разработчика лучше. Именно поэтому анализ того, что создал ИИ, становится, пожалуй, более ценным, чем сама способность его генерировать. Практическое правило для команд: никто не должен включать в код те части, которые он не может построчно объяснить в процессе анализа.

Контекст — настоящий рычаг

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

Agent Quality
=
Model
× Context
× Tools
× Instructions
× Verification

Именно умножение является ключевым фактором. Сильная модель, работающая в условиях плохого контекста, приводит к созданию некачественного программного обеспечения, поскольку практически нулевой коэффициент снижает общий результат. Хорошая модель, работающая в хорошо структурированном репозитории с четкой архитектурой, надежными тестами, полезной документацией и точными инструкциями, может показать гораздо лучшие результаты. Навык, необходимый для этого, — это инжиниринг контекста, при котором формулировка запросов является лишь одной из составляющих.

Почему «инжиниринг запросов» слишком узок

Разницу легко увидеть, сравнив примеры. Простой запрос выглядит так:

"Create a login screen."

Запрос, созданный с учетом контекста, выглядит так:

Here is our architecture.
Here are our design rules.
Here is the API contract.
Here are existing authentication patterns.
Here are the tests.
Here are the project constraints.
Here is the expected behavior.
Now implement the feature and verify it.

Во второй версии агенту передаются архитектура, правила проектирования, контракт API, существующие шаблоны аутентификации, тесты, ограничения и ожидаемое поведение, после чего от него требуется как их реализовать, так и проверить. Это гораздо ближе к тому, как вы бы инструктировали нового коллегу, причем запрос является лишь одним из элементов этого процесса. Когда агент ведет себя неправильно, целесообразно выяснить, какой из этих элементов отсутствовал; наша инструкция по отладке ИИ-агентов по уровням подробно рассматривает этот процесс диагностики.

Инженер проектирует весь цикл

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

Developer → Code

В новой модели процесс проходит через несколько этапов, и инженер отвечает за все из них:

Developer
    ↓
Specification
    ↓
Agent
    ↓
Tools
    ↓
Code
    ↓
Tests
    ↓
Verification

Понимание логики цикла означает знание того, какая инструкция необходима в данной ситуации:

• «Сделайте это», когда задача четко определена и риск невелик.
• «Сначала спланируйте», когда изменения затрагивают несколько модулей.
• «Пока оставьте код в покое и сначала изучите архитектуру», когда перед внесением изменений необходимо глубокое понимание.
• «Воспроизведите баг», прежде чем принимать любое решение по его устранению.
• «Остановитесь; ваше предположение неверно», когда агент уверенно движется в неправильном направлении.

Этот последний шаг может оказаться одним из самых ценных навыков, и он полностью зависит от достаточного знания платформы, чтобы распознать ошибочное предположение.

Ни разработчик Android, ни инженер по промптам

Ни одна из этих категорий сама по себе не отражает всю суть роли. Разработчик Android, который пишет код на Kotlin только вручную, отстанет по уровню эффективности. Человек, способный запрашивать код на Kotlin у ИИ, но не разбирающийся в архитектуре Android, рано или поздно столкнётся с трудностями. Идеальное сочетание выглядит следующим образом:

Android Engineering
        +
AI Agent Skills
        +
System Design
        +
Context Engineering
        +
Verification
        =
AI-Augmented Android Engineer

На практике это означает поддержание знаний в области Android, углубление понимания архитектуры, обучение точному формулированию требований для машин, а также освоение работы с агентами, их инструментами, протоколом MCP, инструкциями по хранилищам данных и автоматизированными проверками. Прежде всего это означает умение распознавать ошибки ИИ. Агент может с уверенностью написать две тысячи строк кода; инженеру же предстоит решить, действительно ли эти строки необходимы.

Более реалистичным будущим является не замена разработчиков ИИ, а замена рабочих процессов, неэффективно работающих с агентами, разработчиками, умеющими хорошо сотрудничать с ними. Один инженер с прочными теоретическими знаниями и правильно настроенной системой агентов может достичь того, что раньше требовало гораздо больше ручного труда. Инженерия не исчезает; она переходит на более высокий уровень, где рассуждения, определение ограничений и проверка результатов имеют большее значение, чем просто набор клавиш, а архитектура служит картой, предотвращающей заблудение агентов.

Основные выводы

• Рассматривайте инструкции для агента как спецификации: указывайте технологии, решения по производительности, требования к устойчивости, контракты, объем тестирования и то, что не должно меняться.
• Проверяйте сгенерированный код, изучая систему в целом (владение состоянием, жизненный цикл, завершение процессов, конкурентность, отмена операций), а не просто проверяя его компиляцию.

Инвестируйте в фундаментальные аспекты; именно они позволяют выявлять быстрые, правдоподобные, но ошибочные реализации.

Закодируйте командные стандарты в файлах инструкций на уровне репозитория, таких как AGENTS.md, и обслуживайте их так же, как код.

Улучшайте результаты путем улучшения контекста (архитектура, тесты, документация, примеры), поскольку слабый фактор ограничивает общий результат.

Оставайтесь ответственными за весь процесс: решайте, когда агент должен действовать, планировать, исследовать, воспроизводить или останавливаться.