Розробка Android-додатку для колекціонерів карток One Piece за допомогою AI: досвід запуску за 2 місяці

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Мене звати Андрій Веремієнко. Я маю близько семи років досвіду в Android-розробці. У цій статті хочу поділитися своїми думками щодо розробки мобільних додатків за допомогою AI-агентів та проблемами, з якими ви можете зіткнутися на цьому шляху. Вона може бути цікавою як людям із досвідом мобільної розробки, так і без нього.

Насамперед хочу поговорити про швидку перевірку концепцій та про те, як не страждати під час подальшої підтримки проєкту.

Ідея

Почнімо з ідеї. Logia — це додаток для колекціонерів карток One Piece (схоже на колекціонування карток Pokеmon, і ви здивуєтеся кількості фанатів цієї ніші). iOS-версія додатка була розроблена значно раніше та перебувала в релізі близько шести місяців. Підписна модель монетизації також приносила певний дохід.

Загальна кількість колекціонерів на Android перевищує аудиторію iOS, що підтверджують додатки конкурентів. Тому Android-версія була запланована від самого початку. Відповідно, завдання сформувалося досить швидко: розробити додаток із максимальною кількістю функціоналу в найкоротші терміни та перевірити цю ж концепцію для Android-користувачів.

Планування

Коли з’явилася ідея створити Android-версію Logia, у мене виникло бажання спробувати AI та перевірити його на реальному продукті, який розробляється з нуля. На момент початку роботи над додатком основний хайп був довкола Claude, тому саме його я обрав як основного агента для розробки.

Початковий естімейт складав два місяці на розробку основних функцій і ще два тижні на закрите та відкрите тестування. Маркетингова стратегія була максимально простою: пост на Reddit та сарафанне радіо.

Дизайн мав відповідати iOS-версії настільки, наскільки це було можливо без виходу за межі естімейтів. UI-компоненти, які було складно відтворити на Android, замінювалися найближчими Android-аналогами. В усьому іншому я залишив собі повну свободу щодо архітектури та вибору технологій.

Таким чином переді мною стояли три основні завдання:

• протестувати розробку проєкту за допомогою AI в максимально стислі терміни;
• створити додаток з нуля — від концепції до реальних користувачів;
• зрозуміти, наскільки швидко можна створювати подібні продукти в майбутньому та перевіряти нові ідеї в окремих нішах.

Результат

Через чотири місяці після запуску додаток має понад 5 тисяч завантажень та близько 2 тисяч активних користувачів. Показник Crash-Free становить 99,7%, кількість Premium-користувачів перевищила 100, а рейтинг у Google Play складає 4,3.

Додаток займає високі позиції в Google Play за запитами, пов’язаними з колекціонуванням карток One Piece. На момент написання статті він знаходиться серед перших результатів пошуку в цій ніші. Із моєї точки зору, результат позитивний, а концепція показала свою життєздатність.

AI

80% роботи було виконано за допомогою Claude (Sonnet 4.5, 4.6, Opus 4.6), 15% — Codex (GPT 5.4, 5.5) і ще 5% — Gemini (Gemini Pro 3.5).

Хоча розробка починалася з Claude, з часом я повністю перейшов на Codex. На момент написання статті використовую лише його. Основною причиною стала краща токеноміка при приблизно однаковій якості результату.

Для прикладу, візьмемо відносно велику задачу: окремий екран із діалогами та певною бізнес-логікою, інтегрованою з бекендом. Claude зазвичай встигав реалізувати одну-дві такі задачі в межах чотиригодинного ліміту підписки за $20. Codex дозволяв виконати три-п’ять аналогічних задач за ті самі гроші, паралельно закриваючи додаткові дрібні фікси.

Gemini я використовував лише декілька разів, переважно через його низьку вартість. Попри велику кількість доступних токенів, якість результату та коду мене не влаштовувала. Крім того, працювати в застосунках Claude і Codex було значно зручніше, ніж через консоль.

Gemini також мав непогану інтеграцію з Android Studio, однак на той момент там були доступні лише молодші моделі. Це додатково впливало на якість результатів, які й без того поступалися конкурентам.

Дизайн, екрани та технології

Дизайн додатка був орієнтований на iOS. Основний акцент робився на Bottom Sheet-навігацію, Liquid Glass та декілька кастомних анімацій і компонентів (реалізація яких в Android завжди негативно дивувала).

Поки ми не торкалися специфічних для Android аспектів і я міг чітко слідувати iOS-дизайну, найкраще працювали скріншоти та описи функціоналу, який за ними стояв.

Серед основних екранів були:

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

Із технологічного стеку я обрав Jetpack Compose для побудови UI, оскільки він надає більше можливостей для створення кастомних анімацій та компонентів.

Як базу даних використовував Supabase — вона проста в інтеграції та має непогану документацію. Для роботи з підписками був обраний RevenueCat, який приховує значну частину складності білінгу та надає зручний інтерфейс налаштування.

Архітектурним підходом став MVVM — фактичний стандарт для сучасної Android-розробки. Для реалізації сканера використовувалися ML Kit та CameraX, для dependency injection — Hilt, а для багатопотоковості — Kotlin Coroutines.

Із чим AI справився дуже гарно

UI. З моєї точки зору, велика проблема Android — це дизайн компонентів та відсутність фенсі-анімацій з коробки. Хоч ми й маємо Material 3, але це радше про кастомізацію та адаптацію, ніж про відчуття преміальності та «fancy». Тобто вам потрібно багато досвіду, щоб досягти бажаного результату, особливо якщо він виходить за межі стандартних реалізацій.

Першим кроком для вирішення цієї проблеми стало використання Compose, другим — AI. Оскільки для певних анімацій та компонентів потрібно знати математику й велику кількість внутрішніх деталей, Claude дуже легко справлявся з кожною задачею, стикаючись лише з обмеженнями самої Compose-системи.

Побудувати графік зі статистикою, кастомізувати таби та навігацію, спробувати імітувати Liquid Glass — усе це стало дуже легкою задачею. Чудовою комбінацією для UI-фіксів були скріншоти з девайса та пояснення того, що саме не подобається.

Дуже хороша взаємодія зі скріншотами. У моєму випадку складність полягала саме в дублюванні iOS-дизайну. Спочатку я намагався максимально детально описати, як саме має виглядати дизайн, але потім перейшов на скріншоти з уточненнями. Це працює досить непогано: потрібно лише перевіряти, чи все достатньо зручно й плавно працює, та підлаштовувати анімації з iOS під Android-аналоги.

Сканер-фіча. Ми мали певний набір проблем із цією функцією. Хоча спочатку AI й виконав задачу, система пережила декілька ітерацій, перш ніж стала майже ідеальною та почала розпізнавати картки практично миттєво з мінімальною кількістю помилок. У першій ітерації AI створив досить примітивну систему розпізнавання, яка обробляла лише один фрейм і порівнювала все через регулярні вирази. Пізніше аналіз перейшов до набору з кількох десятків фреймів та формування певного порогу впевненості. Найкращу міграцію виконав саме Codex, довівши сканер майже до ідеального стану.

Швидкість. Основна перевага AI — за умови, що у вас достатньо токенів і часу. За один вечір можна реалізувати декілька кор-фіч, і чим кращий промпт, тим менше полірування знадобиться після. Про якість цих рішень поговоримо пізніше. Але, звісно, усе залежить від промпту.

Проблеми

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

Дебаг — це біль. Якщо ви не маєте достатнього розуміння того, як написані ті чи інші 2000 рядків коду, вас чекатимуть проблеми в майбутньому. Якщо щось не працює, а за логами все виглядає чудово, знайти проблему стає значно складніше. Ви не знаєте, за що саме відповідає той чи інший шматок коду, тому доводиться занурюватися дуже глибоко, щоб зрозуміти, що насправді відбувається.

Inconsistency між схожими елементами. Бек-навігація, алерти та Bottom Sheet’и, відображення помилок (Toast чи Snackbar) — усе це легко починає відрізнятися між собою.

Низький ownership. Розуміння того, як працюють різні компоненти, я отримував переважно під час дебаг-сесій, а не під час самої імплементації. Хоча саме так і було задумано, після виходу в реліз це почало негативно впливати на підтримку проєкту.

Дуже легко щось зламати. Якщо ви не маєте повного уявлення про систему, зламати якийсь компонент стає напрочуд легко. Оскільки зв’язки між екранами та компонентами не завжди очевидні, будь-яка зміна, складніша за просте перефарбування кнопки, вже несе в собі певний ризик.

Вирішуємо проблеми

Можна просто сказати: ліпші промпти, більше скілів і кращий опис задачі — й усе буде добре. Але давайте перейдемо до трохи практичніших порад.

Дублікація коду. Варто мати опис того, як саме ви бачите архітектуру та як між собою пов’язані компоненти. Щось на кшталт architecture.md чи lessons.md має бути достатнім, щоб AI хоча б справлявся з базою та поступово навчався працювати краще.

Дебаг. Спочатку варто описати проблему та покрити все логами. Після цього ці логи можна згодувати боту — ймовірність того, що він впорається, досить висока. Також корисно додавати дебаг-віконця для UI-компонентів, щоб мати можливість проклацати всі можливі стани того чи іншого елемента.

Inconsistency. У вас повинно бути бачення та розуміння того, як саме ви хочете задизайнити той чи інший компонент. Бажано робити такі речі максимально централізовано. Наприклад, для error handling краще мати один компонент, а не декілька різних реалізацій. Зробити це варто ще до початку імплементації. Грубо кажучи, core_ui — це мастхев.

Також додатковим плюсом буде одразу додати локалізацію через strings.xml. Claude може з’їсти величезну кількість токенів, якщо змусити його перекладати весь текст, тому будьте обережні. З позитивного — Google Play Console дозволяє частково вирішити цю проблему з коробки.

Обов’язково опишіть світлу та темну теми й додайте це в memory. AI дуже часто створює компоненти, які не враховують тему застосунку. Також варто окремо прописати перевикористання компонентів.

Ownership. Контроверсійно, але код-рев’ю потрібно робити. Хоча б базове. Навіть якщо ваша головна задача — видати продукт якомога швидше. Мінімальне розуміння проєкту збереже десятки годин під час дебаг-сесій, коли в користувачів почнуть виникати критичні проблеми.

На початку також варто описати архітектуру, компоненти та модуляризацію. Оскільки реалізовувати все це буде переважно AI, надмірно перейматися деталями не потрібно. Але така підготовка підніме читабельність проєкту на декілька рівнів.

Скріншоти — мастхев. AI дуже добре розуміє, що саме зображено на екрані та що саме ви від нього хочете. Але опис усе одно обов’язковий.

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

Наскільки важливо мати знання в Андроїд

За весь час мені досить часто доводилося занурюватися в код й розбирати ту чи іншу проблему. Наприклад синхронізація, авторизація, видалення аккаунту, проблема з LazyColumn анімаціями й багато іншого. Знання також значно пришвидшують розробку. Без них буде складніше, а кількість спожитих токенів буде значно більшою.

Кожен написаний промпт був з вказівкою, як краще робити та на що звернуту увагу, зважаючи на мої скіли (але це було дещо пізніше, на першому місяці я давав АІ повну свободу, але коли почали зявлятися перші баги та нерозуміння того, що відбувається, я почав більш прискіпливо до цього відноситися).

Із розумінням легше. Взагалі поки складно уявити як виглядає апка побудувана повністю на вайб-коді через промпти. Я можу уявити фікси й так далі, але я б побоявся поглянути в код й щось реально там зробити. Моделька справиться, але ціна може бути невідомою, як в токенах, так й в майбунтіх проблемах. Якщо її вчасно не стримувати, повна свобода приведе до, як мінімум, «неочікуваних» результатів.

Пара додаткових слів про дебаг

Спочатку розділимо дебаг на дві категорії — UI та архітектура/бізнес-логіка.

UI. Дебажити його буде складно, особливо без знань Android-розробки. Часто AI-агент після того, як обирає певний компонент, починає його полірувати. Але якщо цей компонент в принципі не здатний підтримати те, що ви хочете отримати, довести його до потрібного результату буде неможливо. Проте AI вперто продовжуватиме його оптимізувати.

Лише знаючи альтернативи (або хоча б запитавши про них у самого AI), можна змінити напрямок. У цьому я побачив одну зі слабкостей AI. Вам потрібні знання для полірування результату, інакше прості компоненти можуть бути реалізовані надто складно, або ж ви ніколи не досягнете того, що задумали.

Архітектура та бізнес-логіка. Тут дещо легше, адже правильно описана проблема дійсно часто приводить до її вирішення, і баг зникає.

Наприклад, я мав проблеми з конвертацією валют. На одних екранах вона працювала, а на інших — ні. Коли я звернувся до агента по допомогу, він справді все виправив. Але коли я переглянув код, мої очі наповнилися жахом. Для кожного компонента конвертація виконувалася окремо прямо в UI.

Пізніше я витратив одну сесію Claude на те, щоб централізувати це рішення та створити єдиний Data Source. Такі речі потрібно помічати на рівні архітектури. Так, AI їх виправить, але уявіть, скільки проблем може створити подібний підхід у майбутньому.

Схожа ситуація була із синхронізацією. Хоча сама синхронізація працювала коректно, вона була написана шарами, і кожен із них жив за власними правилами.

Маємо те, шо маємо

Мануальна розробка

• 4–6 місяців на розробку;
• Значно вища якість коду;
• Повний овнершіп над кожною фічею;
• Дебаг займає менше часу;
• Краще розуміння архітектури та зв’язків між компонентами;
• Анімації та складні UI-компоненти часто спрощуються через обмеження часу.

AI-розробка

• 2 місяці на розробку;
• Нижча якість коду, хоча при правильному використанні правил, пам’яті та якісних промптів її можна суттєво підвищити;
• Низький рівень овнершіпу та розуміння проєкту;
• Дебаг значно складніший, і за швидкість розробки доводиться платити годинами пізніше;
• Значно швидша перевірка нових ідей та концепцій;
• Можливість дуже швидко додавати анімації та UI-компоненти практично будь-якої складності.

Моя роль

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

Із моєї точки зору, AI не замінює розробника. Він лише змінює його роль: менше часу йде на написання коду, але значно більше — на архітектуру, рев’ю, контроль якості та прийняття рішень.

Висновок

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

Чи напишу я ще один додаток з використанням AI? Звичайно.

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

На мою думку, результат з’являється тоді, коли поєднуються бачення та розуміння. Якщо є лише щось одне — попереду, найімовірніше, чекають проблеми. Але пробувати точно варто. Навряд чи в історії розробки був кращий момент для перевірки власних ідей, ніж зараз.

Тож експериментуйте зі своїми ідеями!