AI dla rozwoju Androida: doświadczenie nieprogramisty

Nieprogramista tworzy i utrzymuje aplikacje Android za pomocą AI: analiza postępów

Biznesowy analityk bez doświadczenia w programowaniu opublikował dwie aplikacje Android, używając wyłącznie czatu z AI (Claude) i Android Studio. Rola człowieka: stawianie zadań, testowanie, integracja zmian i wdrożenie. AI generuje kod, diagnozuje błędy i proponuje rozwiązania architektoniczne. Cel — sprawdzić, czy takie podejście może utrzymywać produkt z rzeczywistymi użytkownikami, w tym naprawy błędów i nowe funkcje.

Metoda ewoluowała: od generacji funkcji od zera do minimalnych zmian i napraw. Zadania dla AI formułowane są z kontekstem: objawy, kroki reprodukcji, ograniczenia (bez nowych bibliotek, zachowanie danych), logi błędów.

Narzędzia i przepływ pracy

Kluczowe komponenty:

• Claude: generacja kodu, analiza błędów kompilacji, propozycje dotyczące persistent storage i lifecycle aktywności.
• Android Studio: kompilacja, emulacja, ręczna integracja zmian.
• RuStore: publikacja, zbieranie opinii, wdrażanie aktualizacji.

Format zapytań do AI dla błędów:

• Opis objawu i oczekiwanego zachowania.
• Kroki reprodukcji.
• Wersja aplikacji i ograniczenia.
• Poprzednie próby naprawy z logami.

AI odpowiada: prawdopodobna przyczyna, pliki do sprawdzenia, 2–3 warianty rozwiązań z ryzykami, następnie łatki.

Wyniki po publikacji

Opublikowane aplikacje:

• «168 Godzin» — planer oparty na 168-godzinnym tygodniowym budżecie.
• «F1 Tycoon» — symulator.

Po pierwszym artykule pobrania wzrosły: «168 Godzin» z 1 do 71, «F1 Tycoon» z 13 do 45. Pojawili się rzeczywiści użytkownicy, wykrywający błędy w scenariuszach nieobjętych testowaniem.

Przypadek 1: reset timera przy ponownym uruchomieniu

Objaw: start timera → wyjście → powrót → zerowanie. Rozwiązanie przez AI: przejście od przechowywania upłyniętego czasu do timestamp startu z przeliczeniem. Naprawa zajęła 2 godziny (diagnoza + kompilacja + wdrożenie). Problem w lifecycle aktywności i braku persistent storage.

Przypadek 2: ręczne tworzenie aktywności

Dodana funkcja: użytkownik wprowadza własne encje. AI zaproponowało integrację w modelach danych, ekranach i storage, z walidacją krawędzi (puste pola, aktualizacja list).

Wypracowane zrozumienie struktury projektu

Bez głębokiej wiedzy o składni uformowany model operacyjny:

• Klasy: podział ekranów, modeli, storage.
• Modele danych: zmiany wymagają poprawek w kilku miejscach (UI, persistence).
• Stan: główne źródło błędów — lifecycle, ponowne uruchomienia, przepływy.
• Logika vs. dane: ekrany zarządzają UI, storage — danymi.

To pozwala zadawać precyzyjne zapytania do AI, skupiając się na węzłach systemu.

Ograniczenia podejścia

Spójność projektu: AI generuje lokalne zmiany, ale pomija zależności. Człowiek odpowiada za architekturę.

Debugowanie: efektywny dla powtarzalnych błędów (timery, stan). Pływające problemy (współbieżność, device-specific) wymagają logów i iteracji.

UI/UX: funkcjonalność osiągnięta, ale ergonomia cierpi bez metryk zachowania.

Wsparcie: opinie jako wymagania, aktualizacje — oddzielny proces z backward compatibility.

Granica: metoda działa dla wydania i napraw, ale wymaga zwiększenia podstawowej umiejętności (lifecycle, zarządzanie stanem).

Co ważne

• Rzeczywisti użytkownicy (71+45 instalacji) wykryli błędy, przechodząc od prototypu do produktu.
• Naprawy (timer, funkcje) mieszczą się w 2 godzinach z asystentem AI.
• Człowiek — integrator: testuje, wdraża, rozumie strukturę.
• Ograniczenia: architektura i złożone debugowanie na człowieku.
• Trajektoria: aplikacje żywe, aktualizowane.

Plany rozwoju

• Stabilizacja «168 Godzin»: listy kontrolne testów, przewidywalny stan timerów.
• Iteracyjne funkcje: tylko w ramach obecnej architektury.
• Podstawowa umiejętność: lifecycle, diagnostyka, struktura.
• Następny raport o metrykach (błędy, aktualizacje, dynamika).

— Editorial Team