18 103 рядки коду та $20 на Cursor: Android-застосунок Spirio за місяць

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

Привіт усім! Мене звати Олексій Морозов, я працюю Android-інженером у Spirio by SKELAR. Ми будуємо гейміфіковану EdTech-платформу, яка поєднує східні філософії з сучасними технологіями та пропонує практики для духовного зростання.

Коли я приєднався до команди, початковою метою було створити повноцінний Android-застосунок Spirio за 3 місяці. То був кінець жовтня, коли команда готувалася до Q5 (маркетинговий період наприкінці року, коли інтернет-реклама дешевшає і бізнес може круто заскейлитись). Після обговорення, що зайти в Q5 було б круто вже з застосунком, вирішили взятись за цей виклик — так внутрішній дедлайн скоротився з 3 місяців до 1;)

Застосунок вдалося написати за 34 дні з таким функціоналом:

Гортайте вбік, щоб подивитися всі зображення

У кейсах, коли потрібно написати все з нуля, допомагає AI-агент, який класно вміє створювати «кістяк». Для цього кейсу я вибрав Cursor, який раніше тестував на pet-проєктах. Перш за все, через відсутність часу на експерименти та доступність всіх основних ШІ-моделей. Також він підтримує необхідні MCP-сервери (наприклад, Figma MCP), має класні розширення та є найзручнішим IDE з погляду UI.

Типові екрани

Раніше я виділив би такі процеси та розподіл часу на розробку типового екрана застосунку:

• 3 години — на UI;
• 3 години — на API-запит;
• 2 години — на тестування, дебагінг та решту процесів.

Натомість зараз такі екрани можна реалізувати за лічені хвилини — і за кілька простих кроків:

• Підготувати дизайн-макети в Figma та почистити, щоб AI-агент краще їх компонував. Неправильні контейнери для елементів, зайві нашарування, блоки, відступи тощо — цього не бачимо ми, але бачить Figma MCP і це призводить до великої кількості беззмістовного (slop) коду.
  
  
• Коли наш дизайнер проєктував UX застосунку для iOS, то відповідно копіював макети екранів і під Android. Перш ніж перейти до реалізації UI, я попросив дизайнера зарефакторити макети з Figma під Andorid: всюди застосували auto-layout, прибрали зайві елементи, інтегрували Figma-компоненти там, де їх не вистачало.
• Створити дизайн-систему. Я радив би виносити в систему всі ключові сутності, з яких складаються екрани та які зустрічаються більше, ніж 3 рази: кнопки, слайдери, кольори, шрифти, навігація тощо. Без дизайн-системи AI-агент також буде генерувати багато низькоякісного коду, який важко підтримувати. Ми виносили все в окремий UI-модуль, тому в агента завжди було звідки взяти елементи екранів.
• Вибрати дизайн-патерн, який буде склеювати UI та бізнес-логіку — MVI. Тут нічого унікального, у 2026 році ми використовуємо декларативний підхід написання UI — це Jetpack Compose для Android та SwiftUI для IOS.
  
• І фінальний етап — ревʼю, доповнення нових правил за потреби та оптимізація промптів, аби кожен наступний екран потребував ще менше правок.

За таким сценарієм вдалося реалізувати всі типові екрани в застосунку.

Більше, ніж UI

Spirio — це перш за все клієнт-серверний застосунок, який не може існувати без класного бекенду. Реалізувати всю доменну логіку та шар даних власноруч — це справа не одного спринта.

Тож тут також без сюрпризів: розділяємо підготовку на 3 кроки, а після будемо «вайбкодити»:

1. Architecture. Використовуємо Clean Architecture — у класичному вигляді вона містить досить багато сутностей (репозиторій, юзкейси, різні джерела даних тощо). Ми в цьому плані дуже гнучкі, тому типовий екран не буде містити складних юзкейсів чи окремих джерел даних. А якщо екран складний, наприклад, із окремою системою рекомендацій, кешуванням даних та паралельним підвантаженням контенту — без юзкейсів із репозиторієм уже не обійтися.
2. Swagger. Впевнений, що всі розробники, які часто реалізовують взаємодію із RESTful API у застосунках, його обожнюють. А класно написаний та відредагований swagger люблять не тільки інженери, а й ШІ-агенти. Особливо, якщо він у JSON-форматі, адже це ідеальне джерело контексту для агента.
3. Mermaid. Це новий спосіб побудови діаграм. У такому вигляді наш бекенд-інженер створив документацію до флоу авторизації, реєстрації та оновлення токену користувача. Перевага цих діаграм у тому, що їх створюють за допомогою псевдокоду, який класно та з маленькою втратою токенів розуміє будь-який AI-агент та який легко візуалізувати у зрозумілий людині вигляд. Таким чином отримуємо ще одне джерело даних для агента, яке неодмінно допоможе йому отримати контекст.

   

Загалом, близько 70% роботи було готово за перший спринт, але в деякі деталі довелося інвестувати більше часу.

Особливість розробки — 3D-анімації

У застосунку Spirio дуже багато крутих 3D-анімацій. Але ні на iOS, ні на Android немає готового фреймворку чи бібліотеки, щоб їх програвати. Тому ми ухвалили рішення трансформувати анімації у відео. Тут я наштовхнувся на проблему, з якою раніше не працював: Android не вміє програвати відео з альфа-каналом, а стандартна бібліотека media3 не має інструментів для програвання відео у зворотному порядку.

Який вихід ми обрали? Я знайшов матеріал на Medium, де автор описав іншу статтю розробника про OpenGL Shaders. Тож ми використали шейдери та TextureView для відображення альфа-каналу. Вирішили дублювати відео в звичайному та зворотному форматі на етапі рендеру та використали файли, де перша частина програється з початку вперед, а друга навпаки — з кінця в початок.

Продублювали кожне відео наших 3D-анімацій — тепер вони складаються із 2 відео: у чорно-білому форматі (який відображає, що білий — це прозорий, а чорний навпаки) та самої анімації. OpenGL Shader об’єднує ці відео та визначає, де видалити фон.

Зараз одна анімація довжиною 1-2 секунди важить 100-300 КБ і для такого рівня ілюстрацій це дуже круто. Приклади 3D-анімацій у застосунку

Як працювати з AI у розробці та подібних викликах

Є ті, хто думає, що з AI можна підготувати тільки «сире» MVP. Насправді ж чимало залежить від того, хто з цим AI працює.

Так, штучний інтелект може опрацювати обмежений контекст. Його памʼять не вимірюється в годинах чи в хвилинах — кожна модель має певну кількість токенів. Щойно вони закінчуються, ШІ починає видавати нову інформацію, що не ґрунтується на попередніх даних. Незалежно від того, 5 чи 35 хвилин тому ви задали перший промпт. Оскільки великий проєкт потребує більше коду (а значить більше контексту), ви можете зіштовхнутися з обмеженими можливостями AI. Але якщо спеціаліст сам охоплює весь контекст, а ШІ делегує частини роботи в конкретних кейсах та добре формує промпт — тоді можливо представити якісну та повноцінну розробку.

Поради (чи навіть правила) для ефективної взаємодії з AI-агентом:

1. Декомпозувати всі задачі

Промпт «Зроби застосунок», звісно ж, не спрацює ;) Важливо максимально «подрібнювати» запити — і якщо промпт не спрацював, відходити на крок назад та писати новий.

Я рідко даю агенту писати більше 300-400 рядків за раз, тому що за більшого навантаження контекст швидко забувається і код виходить неякісний.

2. Нове завдання — новий контекст

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

Краще відкрити нове вікно, вказавши місця, де лежать необхідні ідентифікатори користувача, токени тощо. Так ви зможете класно підсилити агента даними та якісніше реалізувати процес оплати. Я от дотримувався цієї поради та за весь час розробки відкрив 409 вікон взаємодії ;)

3. Використовувати 2 вікна взаємодії паралельно

В одному ви консультуєтеся з агентом як із досвідченим спеціалістом, вирішуючи архітектурні завдання: «Уяви, що ти senior-розробник — як ти спроєктував би це рішення?». А в іншому вікні вибираєте одне з рішень, яке він запропонував, та віддаєте його на реалізацію.

4. Завжди перевіряти результат

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

За інших обставин, аби з нуля написати Android-застосунок, справді знадобилося б 3 місяці. Але команда, яка оперативно вирішувала всі блокери, використання AI та культура SKELAR швидко втілювати задуми без бюрократії в процесах допомогли нам досягти цілі та отримати такі відгуки від користувачів:

Якщо ви працюєте над подібним кейсом, я дуже раджу в процесі користуватися принципом 80/20 (насправді, не тільки в розробці). Під час спринтів я міг би розпорошувати зусилля на «дрібні задачі», які забирають по 4+ години. Та коли на розробку всього є 2 спринти, це зовсім не мало. Тому потрібно йти на компроміси — і спочатку приділяти увагу тому, що принесе 80% результату.