AI pro Android vývoj: zkušenost nerozvíječe

Ne-vývojář vytváří a udržuje Android aplikace pomocí AI: analýza průběžných výsledků

Obchodní analytik bez zkušeností s programováním publikoval dvě Android aplikace, používaje výhradně chat s AI (Claude) a Android Studio. Role člověka: zadávání úkolů, testování, integrace změn a nasazení. AI generuje kód, diagnostikuje chyby a navrhuje architektonická řešení. Cíl — ověřit, zda tento přístup může udržovat produkt s reálnými uživateli, včetně oprav chyb a nových funkcí.

Metoda se vyvíjela: od generování funkcí od nuly k minimálním změnám a opravám. Úkoly pro AI jsou formulovány s kontextem: příznaky, kroky reprodukce, omezení (bez nových knihoven, zachování dat), logy chyb.

Nástroje a pracovní postup

Klíčové komponenty:

• Claude: generace kódu, analýza chyb sestavení, návrhy pro persistent storage a životní cyklus aktivity.
• Android Studio: sestavení, emulace, manuální integrace změn.
• RuStore: publikace, sběr zpětné vazby, nasazení aktualizací.

Formát požadavků na AI pro chyby:

• Popis příznaku a očekávaného chování.
• Kroky reprodukce.
• Verze aplikace a omezení.
• Předchozí pokusy o opravu s logy.

AI odpovídá: pravděpodobná příčina, soubory ke kontrole, 2–3 varianty řešení s riziky, poté opravy.

Výsledky po publikaci

Publikovány aplikace:

• «168 Hodin» — plánovač založený na 168hodinovém týdenním rozpočtu.
• «F1 Tycoon» — simulátor.

Po prvním článku se stahování zvýšilo: «168 Hodin» z 1 na 71, «F1 Tycoon» z 13 na 45. Objevili se reální uživatelé, kteří odhalili chyby ve scénářích nepokrytých testováním.

Případ 1: reset časovače při restartu

Příznak: start časovače → ukončení → návrat → vynulování. Řešení přes AI: přechod od ukládání uplynulého času k timestamp startu s přepočtem. Oprava trvala 2 hodiny (diagnostika + sestavení + nasazení). Problém v životním cyklu aktivity a absenci persistent storage.

Případ 2: manuální vytváření aktivit

Přidána funkce: uživatel zadává vlastní entity. AI navrhlo integraci do datových modelů, obrazovek a storage, s validací okrajů (prázdná pole, aktualizace seznamů).

Vybudované porozumění struktuře projektu

Bez hluboké znalosti syntaxe vytvořena operační model:

• Třídy: oddělení obrazovek, modelů, storage.
• Datové modely: změny vyžadují úpravy na několika místech (UI, persistence).
• Stav: hlavní zdroj chyb — životní cyklus, restartování, toky.
• Logika vs. data: obrazovky řídí UI, storage — data.

To umožňuje zadávat přesné požadavky na AI, zaměřujíc se na uzly systému.

Omezení přístupu

Celistvost projektu: AI generuje lokální změny, ale vynechává závislosti. Člověk odpovídá za architekturu.

Debugging: efektivní pro reprodukovatelné chyby (časovače, stav). Plovoucí problémy (soutěživost, specifické pro zařízení) vyžadují logy a iterace.

UI/UX: funkčnost dosažena, ale ergonomie trpí bez metrik chování.

Podpora: zpětná vazba jako požadavky, aktualizace — samostatný proces s zpětnou kompatibilitou.

Hranice: metoda funguje pro vydání a opravy, ale vyžaduje budování základní gramotnosti (lifecycle, state management).

Co je důležité

• Reální uživatelé (71+45 instalací) odhalili chyby, přešli od prototypu k produktu.
• Opravy (časovač, funkce) se vejdou do 2 hodin s AI asistentem.
• Člověk — integrátor: testuje, nasazuje, rozumí struktuře.
• Omezení: architektura a komplexní debugging na člověku.
• Trajektorie: aplikace živé, aktualizované.

Plány rozvoje

• Stabilizace «168 Hodin»: kontrolní seznamy testů, předvídatelné stavy časovačů.
• Iterační funkce: pouze v rámci současné architektury.
• Základní gramotnost: lifecycle, diagnostika, struktura.
• Další zpráva o metrikách (chyby, aktualizace, dynamika).

— Editorial Team