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

Агенти для кодування більше не обмежуються лише завершенням одного рядка коду. Вони досліджують репозиторій, планують зміни, редагують кілька файлів, запускають процес компіляції, аналізують помилки та пробують знову. Це ставить складне питання для інженера мобільних додатків: якщо агент пише більшу частину коду на Kotlin, чи залишається це розробкою для Android, чи це поступово перетворюється на написання запитів у межах IDE? У цій статті стверджується, що жодна з цих категорій не підходить, і описується, у що насправді перетворюється ця роль: написання точних специфікацій, створення умов, за яких працює агент, кодування архітектури у вигляді обмежень та перевірка результатів, які ви самі не вводили.

Приклади стосуються Android, але логіка може бути безпосередньо застосована до React Native, команд веб-розробки та бекенду, які використовують подібні інструменти.

Як далеко просунулися асистенти для кодування

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

Допомога ШІ поступово увійшла до цього процесу. Спочатку вона заповнювала окремі рядки коду, потім цілі функції, а згодом — всі класи. Сучасні інструменти діють як агенти. На момент написання кілька продуктів прямо описують цю можливість:

• Rежим агента 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, існуючі шаблони автентифікації, тести, обмеження та очікувану поведінку, а потім просить його як їх реалізувати, так і перевірити. Це набагато ближче до того, як би ви інструктували нового колегу, причому запит є лише одним із елементів цього процесу. Коли агент поводиться неправильно, варто з’ясувати, який із цих елементів бракувало; наш посібник з діагностики AI-агентів за шарами детально розглядає цей процес.

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

Найбільша зміна може стосуватися розподілу відповідальностей. Раніше взаємозв’язок був прямим:

Developer → Code

Нова модель передбачає кілька етапів, і інженер несе відповідальність за всі з них:

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

Контроль над циклом означає знання того, яка інструкція потрібна в даній ситуації:

• „Зробіть це“, коли завдання чітко визначене та має низький рівень ризику.
• „Спочатку сплануйте“, коли зміни стосуються кількох модулів.
• „Поки що не чіпайте код, а спочатку вивчіть архітектуру“, коли перед редагуванням потрібно краще зрозуміти ситуацію.
• „Відтворіть баг“, перш ніж приймати будь-яке виправлення.
• „Зупиніться; ваша припущення хибне“, коли агент впевнено рухається неправильним напрямком.

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

Ні розробник Android, ні інженер з prompt-ів

Жодна з цих категорій сама по собі не описує всю роль. Розробник Android, який пише код на Kotlin виключно вручну, відстане у плані ефективності. Той, хто може запитати ШІ про код на Kotlin, але не розуміє архітектуру Android, рано чи пізно зіткнеться з труднощами. Ефективне поєднання виглядає так:

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

На практиці це означає підтримувати свої знання Android, поглиблювати розуміння архітектури, навчатися точно формулювати вимоги для машин та орієнтуватися в агентах, їхніх інструментах, MCP, інструкціях до репозиторіїв та автоматизованих перевірках. Найголовніше — це вміння розпізнавати, коли ШІ помиляється. Агент може з упевненістю створити дві тисячі рядків коду; проте інженер має вирішити, чи справді ці рядки потрібні.

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

Ключові висновки

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

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

Запишіть командні конвенції у файлах інструкцій на рівні репозиторію, таких як AGENTS.md, та підтримуйте їх як код.

Покращуйте результати шляхом покращення контексту (архітектура, тести, документація, приклади), адже слабкий фактор обмежує загальний результат.

Залишайтеся власником процесу: вирішуйте, коли агент має діяти, планувати, досліджувати, відтворювати чи зупинятися.