Od pisania kodu w Kotlinie do kierowania agentami: nowa rola inżyniera mobilnego

Agenty kodujące nie kończą już tylko na uzupełnieniu Twoich linijek kodu. Badają repozytorium, planują zmiany, edytują kilka plików, uruchamiają proces budowania, analizują błędy i próbują ponownie. Dla inżyniera mobilnego to rodzi trudne pytanie: jeśli agent pisze większość kodu w Kotlinie, czy to nadal jest rozwój aplikacji dla Androida, czy też cicho przekształciło się to w pisanie zapytań do asystentów wewnątrz IDE? Ten artykuł twierdzi, że żaden z tych określeń nie jest odpowiedni, i przedstawia, czym w rzeczywistości staje się ta rola: pisaniem precyzyjnych specyfikacji, projektowaniem środowiska, w którym pracuje agent, kodowaniem architektury jako ograniczeń oraz weryfikowaniem wyników, których sam nie wpisałeś.

Przykłady dotyczą specyfiki Androida, ale logika ta odnosi się bezpośrednio do React Native oraz zespołów webowych i backendowych używających tych samych narzędzi.

Jak daleko zaszli asystenci kodujący

Klasyczny proces pracy w Androidzie jest dobrze znany: otwieramy Android Studio, tworzymy klasę, piszemy kod w języku Kotlin, radzimy sobie z Gradle, śledzimy błędy w Logcat, testujemy na urządzeniu i wysyłamy prośbę o integrację.

Pomoc sztucznej inteligencji stopniowo wkradała się do tego procesu. Najpierw kończyła pojedyncze linie kodu, potem całe funkcje, a następnie całe klasy. Obecne narzędzia działają jak agenci. W chwili pisania tego tekstu kilka produktów wyraźnie opisuje tę funkcjonalność:

• Gemini Agent Mode w Android Studio przyjmuje ogólny cel rozwoju, opracowuje plan, wykorzystuje dostępne narzędzia, edytuje kilka plików, buduje projekt i powtarza proces w razie niepowodzenia jakiegoś kroku.
• Cursor's Agent przegląda bazę kodu, modyfikuje kilka plików, uruchamia polecenia w terminalu i naprawia błędy podczas wykonywania zadania, zamiast proponować kolejną linię kodu.

OpenAI Codex działa z terminala jako agent programistyczny, który czyta, modyfikuje i wykonywa kod.

Zdolności produktów w tej dziedzinie zmieniają się szybko, dlatego sprawdź aktualną dokumentację narzędzia używanego przez twoją zespół. Kierunek rozwoju jest jednak jasny.

Praca przenosi się w górę łańcucha

Pomocnym modelem myślowym jest drabina działań inżynieryjnych, od najbardziej mechanicznych u dołu po te wymagające najwięcej osądu u góry:

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

Agenty stają się bardzo sprawne na niższych poziomach trudności. To nie oznacza, że pisanie i czytanie kodu traci na wartości, ale zmienia to znaczenie tych umiejętności. Standardową implementację repozytorium, która ręcznie zajmuje pół godziny, można stworzyć w kilka sekund. Napisanie dziesięciu niemal identycznych ekranów Compose ręcznie jest uciążliwe; agent może edytować odpowiednie pliki i wykonać powtarzalne czynności. Prosty błąd kompilacji może pochłonąć kilka minut twojego czasu, podczas gdy agent czyta komunikat, znajduje problematyczny kod, go naprawia, ponownie kompiluje i przechodzi dalej.

Ostatecznym efektem jest to, że inżynier spędza mniej czasu na tworzeniu kodu, a więcej na decydowaniu, który kod powinien w ogóle istnieć.

Dobry prompt to właściwie specyfikacja

Weźmy typową prośbę o produkt: dodanie kolejki do pobierania w aplikacji. Doświadczony inżynier Android mentalnie rozwija to zdanie na strukturę wielowarstwową projektu:

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

Agent może teraz zaimplementować większość elementów tej struktury, ale jakość wyniku w dużej mierze zależy od tego, o co poprosiłeś. Porównajmy trzywyrazową instrukcję ("dodaj kolejkę do pobierania") z czymś takim:

Zbuduj kolejkę, która może obsługiwać kilka pobierania i przechowywać dane między uruchomieniami, wspieraną przez Room przy użyciu WorkManager do wykonywania zadań. Śledź postęp w pamięci, zamiast zapisywać każdą aktualizację do bazy danych. Gdy proces zostanie zakończony, przywróć zamrożone i aktywne pobierania. ViewModel powinien publikować tylko do odczytu StateFlow. W warstwie domeny nie wolno używać typów z frameworka Android. Przetestuj zmiany stanu kolejki oraz odzyskanie po awariach za pomocą testów jednostkowych. Nie modyfikuj entytetów Room, które nie mają żadnego związku z pobieraniem.

Nazywanie drugiej wersji „lepszym promptem” to niedocenienie jej możliwości. Jest to specyfikacja inżynieryjna: określa technologię persistencji, mechanizm wykonywania w tle, decyzję dotyczącą wydajności (niezapisywanie każdej aktualizacji postępu na dysku), wymóg odporności (przetrwanie w przypadku zakończenia procesu), umowę API (niezmienne StateFlow), zasadę warstwowości, zakres testów oraz wyraźny zasięg wpływu. Każdy z tych elementów odzwierciedla wiedzę o Androidzie, której agent nie może wywnioskować na podstawie prośby o „dodanie kolejki pobierania”.

Główny wniosek jest taki, że inżynier nie znika. Staje się osobą, która potrafi przetłumaczyć niejasną prośbę z zakresu produktu na dokładny opis systemu technicznego.

Prompting versus inżynieria

Dwie te role stawiają różne pytania. Osoba skupiona na formułowaniu zapytań pyta, jak sprawić, by model wygenerował określony wynik. Inżynier chce wiedzieć, co należy zbudować, z jakiego powodu, pod jakimi ograniczeniami oraz skąd będzie wiadomo, że to działa.

Załóżmy, że agent przekazuje ci ten ViewModel:

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

Kompiluje się i jest łatwy do odczytania. Doświadczony programista Androida nadal ma listę pytań przed przyjęciem go:

• Czy downloads to zwykły Flow czy StateFlow, i co uruchamia każdy kolektor?
• Gdzie znajduje się jedyny źródło prawdy dotyczące stanu pobierania?
• Co przetrwa zakończenie procesu?
• Czy każda aktualizacja postępu uruchamia zapis w Room?
• Co się dzieje, gdy dwa pobierania zakończą się w tym samym momencie?
• Jak modeluje się anulowanie?

Czy WorkManager może ponownie uruchomić tę pracę i czy stan odzwierciedla to?

Co się dzieje, gdy łączność zostanie przerwana?

Jak zachowuje się aplikacja, gdy użytkownik siłą zatrzyma ją?

Czy repozytorium jest bezpieczne pod względem cykli życia?

Czy jednorazowe zdarzenia interfejsu użytkownika są traktowane oddzielnie od stanu?

Jak to działa na urządzeniach o niskich parametrach?

Tworzenie klasy jest proste. Trudniejsza jest analiza systemu wokół niej, a jej automatyzacja jest jeszcze trudniejsza.

Pętla rozwoju oparta na agentach

Tradycyjna pętla wymusza na programistze zaangażowanie we wszystkie etapy:

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

Dzięki obecności agenta pętla ulega zmianie. Programista ustala cel na początku i odpowiada za przegląd oraz weryfikację na końcu, podczas gdy agent zajmuje się eksploracją, edycją oraz cyklami naprawczymi pomiędzy nimi:

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

Dokumentacja producenta opisuje ten sam schemat. Tryb Agenta w Android Studio przedstawiany jest jako proces planowania, wywoływania narzędzi, modyfikacji plików oraz iterowania nad wynikami. Cursor opisuje swego agenta jako model, który rozumuje, narzędzia umożliwiające wyszukiwanie i edycję plików lub uruchamianie poleceń w terminalu, oraz pętlę, w której agent obserwuje wyniki i wybiera kolejny krok. To już nie jest autodopisywanie tekstu; jest to bardziej zbliżone do delegowania części pracy inżynieryjnej.

IDE jako warstwa orkiestracji

To zmiany wpływają na to, do czego służy IDE. Kiedyś była to praca stolica dla pojedynczego programisty. W chwili pisania narzędzia AI w Android Studio oferują takie funkcje jak:

• Tryb Agenta
• wielokrotne równoległe rozmowy z agentami
• połączenia z serwerem MCP
• instrukcje w pliku AGENTS.md na poziomie projektu
• dostęp do wiedzy specyficznej dla Androida

szukanie w internecie

specjalistyczne umiejętności

zarządzanie uprawnieniami

weryfikacja na emulatorze

Google przedstawia Agent Mode jako narzędzie zdolne do obsługi zadań rozwojowych o wielu etapach i oferuje serwery MCP oraz plik AGENTS.md jako sposoby na jego rozbudowę i kierowanie nim. IDE przestaje być jedynie miejscem, gdzie pisze się kod w Kotlinie, a staje się miejscem, gdzie uruchamia się i nadzoruje środowisko inżynieryjne wspomagane przez sztuczną inteligencję.

Zasady są ważniejsze, a nie mniej

Można by przypuszczać, że jeśli agenci piszą kod, inżynierowie mogą wiedzieć mniej. Jest jednak inaczej: agenci ułatwiają szybkie tworzenie błędnych implementacji, dlatego potrzeba silniejszej bazy wiedzy, aby je wykryć.

Kotlin

Nadal potrzebna jest solidna znajomość cech języka, które najczęściej ukrywają subtelne błędy:

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

Cel nie polega na tym, by samodzielnie pisać każdą linię kodu. Chodzi o to, by zauważyć, gdy wygenerowany kod w języku Kotlin ma subtelne błędy – na przykład użycie strumienia typu „hot”, gdy potrzebny był strumień typu „cold”, lub uruchomienie korutyny poza ramami uporządkowanej współbieżności.

Pliatforma Android

To właśnie w zachowaniu platformy wygenerowany kod najczęściej wygląda poprawnie, ale zawodzi w środowisku produkcyjnym:

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

Agent może stworzyć klasę Worker w ciągu zaledwie kilku sekund. To jednak nic nie mówi o tym, czy ten worker uwzględnia cykl życia aplikacji oraz wymagania dotyczące ponawiania prób i ograniczeń.

Architektura jako ograniczenia agenta

Wiedza o architekturze zyskuje nowy cel. Wzorce takie jak MVI i MVVM, Clean Architecture, granice modułów, repozytoria, DI, obsługa stanu oraz separacja domeny to nie tylko sposoby organizacji kodu; stają się one ograniczeniami, które przekazujesz agentowi. Zamiast „stwórz tę funkcjonalność”, możesz wydać polecenie:

Zbuduj tę funkcjonalność zgodnie z naszą obecną architekturą MVI. Odzwierciedl wzorce z Funkcjonalności A i Funkcjonalności B. Nie wprowadzaj żadnych nowych zależności. Zasady biznesowe powinny znajdować się w warstwie domeny.

Odnoszenie się do istniejących funkcjonalności jest szczególnie skuteczne, ponieważ wskazuje agentowi konkretne, sprawdzone przykłady w bazie kodu zamiast polegać na jego ogólnej koncepcji „MVI”. Architektura staje się częścią języka, którego używasz do kierowania agentami.

Polecenia na poziomie repozytoriów z AGENTS.md

Wiele zespołów musi w każdej sesji powtarzać te same przypomnienia: projekt wykorzystuje Kotlin i Hilt, logika biznesowa nie powinna znajdować się w Composable’ach, stan jest eksponowany za pomocą StateFlow, obowiązują konwencje nazewnicze, wymagane są testy, a pliki wygenerowane są niedozwolone.

Takie oczekiwania mogą znajdować się w samym repozytorium. W chwili pisania narzędzie Gemini w Android Studio czyta pliki AGENTS.md, w których zapisane są takie preferencje, dzięki czemu agent postrzega je jako kontekst projektu. Inne agenty czytają podobne pliki; ta sama koncepcja jest szczegółowo omówiona w praktycznym przewodniku dotyczącym tworzenia skutecznego pliku CLAUDE.md.

To niewielka zmiana o dużych konsekwencjach. Tradycyjnie repozytorium zawierało:

source code
configuration
tests
documentation

Teraz może również zawierać:

AI engineering instructions

Baza kodu zaczyna opisywać zarówno sam oprogramowanie, jak i to, w jaki sposób agent powinien na nim działać. Traktuj te instrukcje jak kod: sprawdzaj wprowadzane zmiany, utrzymuj je krótkie i konkretne, a także usuwaj reguły, które już nie mają zastosowania.

MCP łączy agenta z resztą łańcucha narzędzi

Protokół Model Context Protocol umożliwia systemom AI połączenie z zewnętrznymi narzędziami i usługami, co oznacza, że agent nie jest już ograniczony do panelu czatowego. Za pośrednictwem serwerów MCP może potencjalnie uzyskać dostęp do:

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

Narzędzia AI w Android Studio obecnie umożliwiają łączenie się z serwerami MCP, w tym tymi zdalnymi. Rozważmy pojedynczą prośbę skierowaną do agenta o stworzenie nowej strony Profile na podstawie pliku Figma, ponowne użycie istniejących tokenów projektowych, połączenie tej strony z punktem końcowym profilu, obsługę stanów ładowania i błędów, dodanie testów oraz przygotowanie prośby o pull request. Realizacja tego zadania dotyka jednocześnie wielu systemów:

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

Gdy narzędzie koordynuje pliki projektowe, kod, dokumentację, API, testy, Git i CI, określenie „generator kodu” jest błędne. Jest to agent inżynieryjny, a jego zasięg jest również powodem, dla którego ważne są uprawnienia i przeglądanie: każdy połączony system to coś, z czego agent może czytać lub co może zmienić.

Pułapka: zależny, ale niezdolny

To nowe rozwiązanie ma charakterystyczny sposób awarii. Programista może stać się zależny od AI, nie nabierając przy tym umiejętności jego korzystania. Całkowicie możliwe jest stworzenie kodu wykorzystującego wszystkie te elementy:

Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel

bez zrozumienia, co każdy z nich robi. Wszystko działa poprawnie, praca wydaje się szybka, a kilka miesięcy później w środowisku produkcyjnym pojawia się sytuacja konfliktu związana z anulowaniem cyklu życia, której nikt w zespole nie potrafi wyjaśnić.

AI przyspieszyło pisanie kodu; nie uczyniło to programistę lepszym. Dlatego analiza tego, co stworzyła AI, jest coraz bardziej cenna niż sama umiejętność jej tworzenia. Praktyczna zasada dla zespołów: nikt nie powinien łączyć kodu wygenerowanego przez AI, którego nie potrafi wyjaśnić linijka po linijce podczas przeglądu.

Kontekst to prawdziwy klucz

Agenty kodujące w dużej mierze zależą od kontekstu, który otrzymują. Dokumentacja Cursora na przykład opisuje system agentów w kategoriach kontekstu, narzędzi, instrukcji i modeli. Sugeruje to przybliżoną relację mnożeniową:

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

Mnożenie jest kluczowym elementem. Silny model pracujący przy słabym kontekście daje kiepski oprogramowanie, ponieważ niemal zerowy współczynnik obniża całkowity wynik. Przeciętny model działający w dobrze zorganizowanym repozytorium o jasnej architekturze, solidnych testach, przydatnej dokumentacji i dokładnych instrukcjach może osiągnąć znacznie lepsze rezultaty. Umiejętnością niezbędną do budowania takich rozwiązań jest inżynieria kontekstu, przy czym sformułowanie promptu stanowi jedynie jej część.

Dlaczego „inżynieria promptów” jest zbyt wąska

Różnicę można łatwo zobaczyć na przykładzie. Prosty prompt wygląda tak:

"Create a login screen."

Zapytanie opracowane z uwzględnieniem kontekstu wygląda tak:

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.

Druga wersja przekazuje agencie architekturę, zasady projektowe, umowę API, istniejące wzory autoryzacji, testy, ograniczenia oraz oczekiwane zachowanie, a następnie prosi ją o ich wdrożenie i weryfikację. Jest to znacznie bliższe sposobowi, w jaki poinformowałbyś nowego kolegę, a prompt jest tylko jednym z elementów tego procesu. Gdy agent zachowuje się niewłaściwie, warto zapytać, który z tych elementów był brakujący; nasz przewodnik debugowania agentów AI warstwowo opisuje ten proces diagnozy.

Inżynier projektuje cały cykl

Największa zmiana może dotyczyć rozkładu odpowiedzialności. W poprzedniej sytuacji relacja była bezpośrednia:

Developer → Code

Nowa struktura obejmuje kilka etapów, a inżynier jest odpowiedzialny za wszystkie z nich:

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

Kierowanie pętlą oznacza wiedzę o tym, jakie instrukcje wymaga dana sytuacja:

• "Zrób to", gdy zadanie jest dobrze określone i ma niski poziom ryzyka.
• "Najpierw to zaplanuj", gdy zmiana dotyczy kilku modułów.
• "Na razie nie ruszaj kodu i najpierw przeanalizuj architekturę", gdy przed edycjami potrzebna jest pełna informacja.
• "Odtwórz błąd", zanim przyjmiesz jakiekolwiek rozwiązanie.
• "Przestań; twoje założenie jest błędne", gdy agent z pewnością zmierza w niewłaściwym kierunku.

To ostatnie działanie może okazać się jedną z najcenniejszych umiejętności, a zależy ono wyłącznie od wystarczającej znajomości platformy, by dostrzec błędne założenie.

Ani programista Android, ani inżynier promptów

Żaden z tych określeń sam w sobie nie oddaje pełnego obrazu tej roli. Programista Androida, który pisze wyłącznie kod w języku Kotlin ręcznie, będzie odstawać pod względem efektywności. Osoba, która potrafi poprosić sztuczną inteligencję o kod w Kotlinie, ale nie rozumie architektury Androida, prędzej czy później napotka trudności. Optymalna kombinacja wygląda następująco:

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

W praktyce oznacza to rozwijanie wiedzy na temat Androida, pogłębianie zrozumienia architektury, naukę precyzyjnego formułowania wymagań skierowanych do maszyn oraz opanowanie umiejętności pracy z agentami, ich narzędziami, protokołem MCP, instrukcjami repozytorium oraz automatycznymi kontrolami. Przede wszystkim oznacza to umiejętność rozpoznania, gdy sztuczna inteligencja się myli. Agent może z confidencją napisać dwa tysiące linii kodu; inżynier musi ocenić, czy te linie w ogóle powinny istnieć.

Bardziej realistyczną przyszłością nie jest zastąpienie programistów przez sztuczną inteligencję, lecz programiści, którzy dobrze współpracują z agentami, zastępujący procesy robocze, które tak nie robią. Jeden inżynier posiadający solidne umiejętności podstawowe oraz dobrze skonfigurowane środowisko agentów może potencjalnie osiągnąć to, co wcześniej wymagało znacznie większego wysiłku ręcznego. Inżynieria nie znika; przechodzi na wyższy poziom, gdzie rozumowanie, określanie ograniczeń i weryfikacja wyników mają większe znaczenie niż sam fakt naciskania klawiszy, a architektura pełni rolę mapy, która zapobiega zbłąkaniu agentów.

Główne wnioski

• Traktuj instrukcje skierowane do agenta jako specyfikacje: podaj nazwy technologii, decyzje dotyczące wydajności, wymagania dotyczące odporności, umowy, zakres testów oraz to, co nie może ulec zmianie.
• Przeglądaj generowany kod, badając system wokół niego (własność stanu, cykl życia, zakończenie procesu, równoczesność, anulowanie), a nie sprawdzając jedynie, czy kompiluje się.

Inwestuj w podstawy; to one pozwalają wykryć szybkie, wiarygodne, błędne implementacje.

Zapisz konwencje zespołu w plikach instrukcji na poziomie repozytorium, takich jak AGENTS.md, i traktuj je jak kod.

Popraw wyniki poprzez udoskonalenie kontekstu (architektura, testy, dokumentacja, przykłady), ponieważ słaby element ogranicza cały rezultat.

Bądź właścicielem procesu: decyduj, kiedy agent powinien działać, planować, badać, odtwarzać lub przestać.