Як я написав iOS-додаток за 80 годин з AI, не знаючи Swift. Майже

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

Привіт! Мене звати Діма Міхєєв, наразі я техлід у SAP Fioneer та паралельно кофаундер в Spilki.

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

Піксі — справжній продакт-менеджер цього проєкту

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

Не хвилюйтеся, Піксі того вечора нагодував. Але замовлення не доробив. Закрив браузер, відкрив термінал і почав брейнстормити ідею з Claude.

Через шість тижнів ця ідея пішла на review в App Store. Вона називається Brimm — це комфортний маленький додаток, який стежить за вашою коморою, вчиться вашому ритму і ненавʼязливо нагадує за кілька днів до того, як щось закінчиться. Без таблиць та камер у холодильнику, просто дбайливий сусід, який помічає, що кава ось-ось скінчиться.

Я backend-розробник. Десять років Java, Scala, Kotlin, Spring, AWS — нудний enterprise, переважно у великих міжнародних компаніях. Xcode у житті не відкривав жодного разу. Brimm робив вечорами після основної роботи і на вихідних — десь 80 годин чистого часу, з агентом.

Сетап

Кілька деталей які важливі для контексту, щоб решта мала сенс. Swift я не знав. SwiftUI не знав. SwiftData не знав. Але я знав як побудовані застосунки, що робить ORM і чим відрізняється автентифікація від авторизації.

Стек: Swift, SwiftUI, SwiftData. Kotlin та Spring Boot для бекенду. Деплоймент на Railway. ШІ: OpenCode як agent runner і Claude Opus як модель. (Почав з пресету «Oh My OpenAgent», потім перейшов на «Oh My OpenCode slim», так як оригінальний OMO зжирав мій тижневий ліміт токенів за один-два вечори.)

Скіли які я використовував: SwiftUI Agent Skill; Emil Kowalski’s design skills та Design Good Taste для сучасних best practice в UI; і Linus Torvalds AI Skills — щоб агент мав право час від часу називати мої ідеї brain-damaged.

Дизайн робив через Claude design. Місячний ліміт токенів спалив повністю — добре, що якраз настав новий місяць. Для соло-розробника інструмент того вартий, тільки готуйтеся до десятка ітерацій на кожен екран.

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

Тепер — власне історія.

Що працювало, швидко

HTML/CSS прототипи агент перетворює в SwiftUI добре. Я давав йому референс — він переносив структуру і layout у код. Кольори, відступи, шрифти підправляв руками, але кістяк екрана будувався сам.

Деплоймент і сетап — через MCP. Railway, Cloudflare, Firebase підключені до OpenCode. Замість того щоб самому читати логи і дашборди — віддавав це агенту. Після AWS з його налаштуваннями ці AI-friendly сервіси виявились приємною несподіванкою. Для POC — must-have.

За кілька вечорів був готовий прототип, хоча і з величезним беклогом.

На що варто звернути увагу

В якийсь момент я помітив, що мій todo-лист росте швидше, ніж я його закриваю.

Те, що я зрозумів пізніше: агент, як і кожен досвідчений розробник, лінивий. За замовчуванням. Якщо є шанс відкласти складну частину і закрити задачу швидше — він відкладе. Якщо edge case можна пропустити з коментарем — пропустить. Якщо в спеці не написано прямо «це обов’язково» — буде вважати що необов’язково. Це не баг агента, а за дизайном. Він оптимізований, щоб закрити задачу. Але ваше визначення «закрити» і його — різні.

Тому ваша робота як розробника тепер: слідкувати за відкладеннями. Не писати код. Не дебажити. Слідкувати. Читати кожен diff. Бачити кожен TODO, який не ваш. Знаходити «for now», «MVP shortcut», «we’ll handle this later» — і повертати назад: «ні, не later. Зараз.» Якщо ви цього не робите, агент просто продовжує. І через два тижні ваш проєкт — це 67 TODO, які ви не помітили.

Якось я залишив у коді кілька коментарів — нотатки собі-майбутньому, типу // be careful: this assumes the user already has a default pantry. Хотів повернутися пізніше, розібрати, які з них реальні баги, виправити те, що важить.

Попросив агента: «deal with the comments in this file». Я мав на увазі: прочитай їх, подумай над ними, можливо щось виправ, а про решту запитай мене. Агент видалив їх. Усі. Чисто. Одним добре відформатованим комітом з назвою «Clean up TODO comments». Навіть commit message написав охайно. Технічно він зробив, що я попросив — «розібрався» з коментарями. Просто в нас були різні визначення слова «розібрався». Моє включало розуміння. Його — git rm -- file lines.

Я зробив rollback. Перефразував prompt. Додав в AGENTS.md правило простою мовою: «Ніколи не видаляй коментарі без явного дозволу. Якщо вважаєш коментар застарілим або неправильним — спитай».

Що реально мене врятувало

Нижче — невеликий набір речей, які я почав робити, бо мусив. Кожна коштувала мені швидкості в моменті і врятувала від цілого reroll-у проєкту в перспективі.

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

План перед кодом. В Claude Code і OpenCode є plan mode — агент спочатку розписує план і ставить питання з варіантами відповідей: «робимо через X чи через Y?», «цей edge case обробляємо зараз чи відкладаємо?». Користуйтесь цим якомога частіше. Кожне питання, на яке ви відповіли до коду — це відкладення, яке не потрапило в код. Я переглядаю план, вирізаю усе лишнє, і тільки тоді агент торкається файлів.

Правила в AGENTS.md. У мене там не три рядки. Там розписано як іменувати таблиці, як обробляти час, як логувати, як писати міграції, які anti-patterns заборонені. Кожне правило з’явилося після того, як агент зробив щось не так — і я зрозумів, що це повториться, якщо не записати.

Code review. Кожен PR перед merge. Читаю кожен рядок. Особливо нудні — там і ховаються коміти типу «delete all comments». Якщо diff занадто великий для перегляду — задача була занадто велика.

Тести на кожну фічу і кожен багфікс. Прогон перед комітом. Це правило в AGENTS.md, але я виношу окремо, бо без нього все решта розвалюється. Нова поведінка — юніт або інтеграційний тест, залежно від того, чи логіка mockable. Багфікс — спочатку regression-тест, який падає, потім фікс який його піднімає. Тест лишається у сюїті назавжди як охоронець проти того ж бага. Без цього agent-generated код накопичується швидше, ніж ти його перевіряєш руками, а тести — це єдиний автоматичний фільтр, який встигає за швидкістю агента.

Що я перестав давати агенту вирішувати

Є три категорії рішень, де я навчився зупиняти агента і брати кермо в свої руки.

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

Дизайн. Агент видасть десять варіантів екрана, і всі десять будуть виглядати як ще один SaaS-дашборд. До «менш корпоративного» допромптитися можна, але це займе забагато часу. Тому що саме лишити, а що викинути, вирішував я на кожному екрані.

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

AI також всередині продукту, не лише навколо

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

Головне місце — прогноз. Brimm має навчитися, як швидко закінчується кава, вівсяне молоко, корм для собаки чи щоденні таблетки. А «швидко» залежить від персонального контексту, який я не можу захардкодити. Статичний опитник («скільки чашок на день?») звучить розумно, поки ви не зрозумієте, що «чашок на день» не стосується миючого засобу, а «порцій на тиждень» не стосується кави, і писати кастомну форму під кожен товар — це спосіб побудувати софт, який стане заручником власної підтримки.

Тому Brimm генерує питання динамічно. Додаєте товар — OpenAI API дивиться на назву і складає кілька питань саме під нього. Для кави це «скільки чашок на день» і «наскільки міцну п’єте». Для корму — «скільки порцій» і «який розмір собаки». Для зубної пасти — «скільки людей у домі». У кожної відповіді своя вага, і з них складається прогноз — коли саме ця річ закінчиться у вас.

AI в Brimm є ще в кількох місцях. Вставили URL з магазину — він сам витягне назву і деталі товару, щоб не друкувати «Vanilla Oat Milk 64oz» по літерах. Сфотографували чек — OCR розбере його на товари, бо додавати п’ятнадцять позицій вручну після супермаркету ніхто не буде. Новий товар сам потрапляє у правильну категорію комори.

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

Де я зараз

Brimm уже в App Store. Але ці слова даються легше, ніж далось саме ревью.

App Store review — це окремий вид мистецтва. На кожну твою відповідь реагують приблизно через добу. І щоразу це інша людина — тобто ти вже все виправив і пояснив попередньому рев’юверу, а наступний реджектить по тій самій причині, бо твоє пояснення він не читав. Найбільше крові випили Subscriptions: через якісь внутрішні баги TestFlight покупки не працювали виключно на девайсах рев’юверів. У мене працює, у тестерів працює, у рев’ювера — ні. Доводь. Відправляв на ревью кілька разів поспіль з одним і тим самим білдом — поки в когось із них не запрацювало.

Піксі більше не голодна

Жоден агент тут не допоможе. Це та частина розробки під Apple, яку не можна делегувати, прискорити чи запромптити — тільки перетерпіти.

Я зробив iOS-додаток у стеку, якого ніколи не торкався, за вісімдесят годин вечорами, з агентом, який часом видаляв мої власні нотатки. Шість місяців тому такий таймлайн звучав би як вигадка. Сьогодні — звучить нормально. Через рік звучатиме повільно.

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

Якщо ви senior, який думає про pet project у незнайомому стеку — робіть. Економіка абсурдно на вашу користь. Просто заходьте в це, знаючи, що «хай AI це зробить» — це prompt, який народжує найохайніше оформлений технічний борг у вашому житті.

Читайте кожен PR.

So let’s go brimming.

P.S. — Якщо це читає хтось з Rozetka, Monobazar, або, прости господи, Amazon: зараз гарний час поговорити про інтеграцію. Уявіть: ваші клієнти купують те що завжди купують, в один тап, у момент коли воно ось-ось закінчиться. Ми вже знаємо що вони купують. Ви вже вмієте це доставляти. Хтось має поєднати ці два факти. Reply-all welcome.