Як ми написали Android-застосунок за місяць з готового iOS-проєкту за допомогою Claude Code

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

Всім привіт! Мене звати Сергій, я працюю iOS Tech Lead у Futurra Group. Пів року тому я публікував на DOU статтю «Як ми прискорили розробку на iOS за допомогою Cursor AI». Чесно скажу одразу: майже все, що там написано, для нас уже не актуально. За ці пів року ми повністю перейшли з Cursor на Claude Code, перебудували процеси навколо агентної розробки — і головним доказом того, що це працює, стала історія, з якої почнеться ця стаття: ми написали повноцінний Android-застосунок за один місяць, маючи на руках лише готовий iOS-проєкт.

Стаття складається з двох частин. У першій я розповім, як саме ми портували застосунок на Android: який стек обрали, чому не стали переписувати бізнес-логіку на Kotlin Multiplatform і як технічно працює Swift SDK for Android. У другій — детально розберу, що ми зараз використовуємо для прискореної розробки на iOS та Android: skills, MCP-сервери, агенти, база знань проєкту, оркестрація задач і правила для AI, без яких усе це перетворюється на хаос.

Частина 1. Android-застосунок за місяць з готового iOS-проєкту

Вихідні дані

У нас був зрілий iOS-проєкт Muses Academy: інтерфейс на UIKit, чимала бізнес-логіка на Swift (робота з контентом, підписки, аналітика, синхронізація, доменні моделі), налагоджені процеси та CI. Бізнес хотів Android-версію, і хотів її швидко. Класичний шлях — найняти Android-команду і за півроку-рік написати все з нуля на Kotlin — нас не влаштовував ані за термінами, ані за бюджетом. Тож ми сіли й порахували варіанти.

Вибір технології: KMP чи Swift SDK for Android

Реальних кандидатів було два:

Kotlin Multiplatform (KMP) — де-факто стандарт для шаринга логіки між платформами. Але для нас у KMP був фундаментальний мінус: уся наша бізнес-логіка вже написана й відтестована на Swift. Перехід на KMP означав би переписати її на Kotlin, покрити тестами заново, а потім ще й інтегрувати shared-модуль назад в iOS-застосунок. Тобто ми б витратили місяці на те, щоб отримати те, що вже маємо, — просто іншою мовою. Плюс подвійна експертиза: команді, яка живе у Swift, довелося б глибоко занурюватись у Kotlin, Gradle і специфіку KMP-тулінгу.

Swift SDK for Android — офіційний шлях від Swift.org, який дозволяє крос-компілювати Swift-код під Android. Логіка залишається на Swift, переписувати нічого не треба, тести продовжують працювати. Мінус — технологія молодша за KMP, і нативний UI для Android усе одно доведеться писати окремо.

Ключовим аргументом стало саме те, що в нас уже був написаний і відтестований Swift-код. Немає сенсу переписувати робочу бізнес-логіку на іншу мову лише заради того, щоб її можна було шарити, — якщо існує спосіб шарити її як є. Тому ми обрали Swift SDK for Android.

Архітектура: бізнес-логіка в окремій Swift-бібліотеці

Перше, що ми зробили, — винесли всю бізнес-логіку з iOS-застосунку в окрему Swift-бібліотеку (Swift Package). Це доменні моделі, use cases, робота з мережею, кешування, валідація — усе, що не стосується UI і платформних API. До речі, значну частину цього рефакторингу теж зробив Claude Code: він проаналізував залежності між модулями, запропонував межі пакета і переніс код, проганяючи білд і тести після кожного кроку.

Далі схема така:

• Для iOS бібліотека підключається як звичайна залежність через SPM. Для iOS-застосунку взагалі нічого не змінилося, окрім того, що логіка тепер живе в окремому пакеті.
• Для Android та сама бібліотека крос-компілюється Swift SDK for Android у нативні бінарники під Android, а поверх генерується Kotlin/Java-обгортка, через яку Android-код викликає Swift.

Як технічно працює Swift SDK for Android

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

1. Крос-компіляція. Swift SDK for Android — це не окремий рантайм і не транспайлер у Kotlin-сирці. Це бандл Swift-бібліотек, хедерів і конфігурацій, який розширює стандартний open source Swift-тулчейн можливістю збирати код під Android-таргети. Для роботи потрібні три компоненти: сам Swift-тулчейн (компілятор, стандартна бібліотека, LLVM-бекенд), Swift SDK for Android і Android NDK (від r27 LTS), який дає платформні хедери, системні бібліотеки та лінкер під Android-архітектури. Компілятор Swift через LLVM генерує звичайний нативний машинний код — ELF-бінарники під aarch64-unknown-linux-android та x86_64-unknown-linux-android (arm64 для реальних девайсів, x86_64 для емулятора):

Тобто Swift-код на Android виконується так само нативно, як і на iOS, — без віртуальної машини й без інтерпретації. На виході отримуємо .so shared-бібліотеки під кожну підтримувану архітектуру, які пакуються в APK/AAB у стандартну директорію jniLibs.

2. Міст між Swift і Kotlin. Android-застосунок живе у світі JVM/ART, тож напряму викликати Swift-функції з Kotlin не можна — потрібен JNI (Java Native Interface). Писати JNI-обв’язку руками — окреме пекло, і саме тут працює бібліотека swift-java від Swift-спільноти. Вона сканує публічний API нашої Swift-бібліотеки і генерує Kotlin/Java-файли-обгортки плюс відповідний JNI-глю-код зі Swift-боку. У результаті Android-розробник (або Claude Code, який пише Android-код) бачить звичайні Kotlin-класи й методи: викликає CourseRepository.loadCourses(), а під капотом виклик через JNI летить у нативну .so-бібліотеку, виконується Swift-кодом і повертає результат назад у Kotlin. Генератор бере на себе конвертацію типів, керування пам’яттю між ART garbage collector і Swift ARC та маршалінг даних через JNI-межу.

3. UI — нативний для кожної платформи. Інтерфейс ми свідомо не шарили: на iOS це UIKit, на Android — Jetpack Compose. Тут переклад нетривіальний: UIKit — імперативний (view controllers, Auto Layout, делегати), а Compose — декларативний, тож механічного мапінгу «один в один» немає. Але саме тут агентний підхід і розкривається: Claude Code читає UIKit-екран разом з в’ю-моделлю, витягує з нього суть — ієрархію в’юх, констрейнти, стани, обробники подій — і генерує ідіоматичний Compose-екран, а не «Compose, написаний як UIKit». Auto Layout-констрейнти перетворюються на Column/Row/Box з модифікаторами, делегати й таргет-екшени — на лямбди-колбеки, а KVO/NotificationCenter-логіка оновлення UI — на State і рекомпозицію. Фінальну відповідність дизайну звіряємо з макетом у Figma. Користувачі при цьому отримують повністю нативний look & feel кожної платформи.

4. Білд-пайплайн. Ми інтегрували крос-компіляцію в Gradle: окремий task збирає Swift-пакет під обидві Android-архітектури, розкладає .so у jniLibs, запускає генерацію Kotlin-обгорток через swift-java і тільки потім збирається сам Android-модуль. Для розробника (і для Claude) це виглядає як звичайний ./gradlew assembleDebug.

Роль Claude Code: чому саме місяць, а не пів року

Тепер найцікавіше — як у це рівняння вписався Claude Code. Якщо коротко: приблизно 90% Android-коду написав Claude, а ми виступали в ролі архітекторів і рев’юерів. Ось що дало найбільший буст:

Перенесення екранів пачками. Ми давали Claude Code задачу виду: «ось UIKit-екран X із таким-то в’ю-моделем, ось наші конвенції з CLAUDE.md — зроби еквівалентний Compose-екран, підключи його до Kotlin-обгортки бізнес-логіки, збери проєкт і перевір на емуляторі». Оскільки бізнес-логіка вже була доступна з Kotlin через згенеровані обгортки, Claude не вигадував логіку заново — він лише писав UI-шар і клей.

Самоперевірка на девайсі. У наших правилах жорстко прописано: після виконання будь-якої задачі Claude сам збирає проєкт і запускає його на симуляторі/емуляторі або реальному девайсі, перевіряє, що фіча працює, і лише потім вважає задачу виконаною. Для Android це gradle build + запуск на емуляторі через adb + перевірка UI, для iOS — xcodebuild + симулятор. Це та сама ідея верифікаційного циклу, про яку Boris Cherny (творець Claude Code) каже, що вона «збільшує якість фінального результату у 2–3 рази». І це справді так: різниця між «Claude написав код» і «Claude написав код, зібрав, запустив, потикав і виправив те, що зламалось» — колосальна.

Паралельність. Екрани й фічі переносились паралельно в кількох сесіях Claude Code одночасно, кожна у своєму git worktree. Про оркестрацію цього процесу — детально у другій частині.

Знання обох кодових баз. Завдяки нашій базі знань (про неї нижче) кожна сесія Claude одразу «знала» архітектуру і iOS-проєкту, і Android-проєкту, і shared-бібліотеки — без ручного пояснення контексту в кожному чаті.

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

Частина 2. Наш поточний стек для прискореної розробки на iOS та Android

Чому ми пішли з Cursor

У попередній статті я детально описував наш сетап на Cursor: SweetPad, Xcode Build Server, xcbeautify, MCP через Docker. Це все чудово працювало для сценарію «розумний автокомпліт + чат в редакторі». Але за пів року парадигма змінилася: ми більше не «пишемо код з підказками AI» — ми делегуємо задачі агенту, який сам читає код, планує, редагує, збирає, тестує і перевіряє результат. І для агентного workflow Claude Code виявився просто сильнішим інструментом: краща робота з довгим контекстом, нативні subagents, hooks, skills, воркфлоу, глибока інтеграція з терміналом — і, головне, моделі Anthropic, які на наших реальних мобільних задачах стабільно «доводять справу до кінця».

Показова зміна ментальної моделі, яку добре сформулювали в команді Claude Code: раніше була ера prompt engineering, потім — context engineering, а зараз — контекстний мінімалізм. Ти даєш агенту стислий бриф (мета, обмеження, критерії приймання) і спосіб самостійно дотягнутися до контексту — через файли, пошук по коду, MCP. І не мікроменеджиш кожен крок.

Правила для AI: наш CLAUDE.md

Фундамент усього — файли правил. У кожному з трьох репозиторіїв (iOS, Android, shared-бібліотека) лежить свій CLAUDE.md, закомічений у git, плюс глобальний ~/.claude/CLAUDE.md з особистими преференсами. Кілька принципів, які ми винесли з практики:

Правило верифікації — найважливіше. Перший і головний пункт наших правил: задача не вважається виконаною, поки Claude сам не зібрав білд і не перевірив зміни на симуляторі/емуляторі або реальному девайсі. Для iOS це запуск через xcodebuild + симулятор, для Android — Gradle + емулятор/девайс через adb. Якщо білд падає або фіча не працює — Claude виправляє і перевіряє знову, без участі людини. Це прибрало цілий клас проблем «код виглядає правильно, але не компілюється».

Кожна помилка стає правилом. Коли Claude робить щось не так, ми не просто виправляємо його в чаті — ми кажемо: «додай це у CLAUDE.md, щоб більше не повторювалось». Виправлення в чаті лагодить один конкретний запуск; записане правило лагодить усі майбутні. Claude, до речі, напрочуд добре формулює правила сам для себе. Через кілька місяців такої дисципліни rate помилок відчутно падає.

Конкретика замість загальних фраз. «Пиши чистий код» — марне правило. Працюють конкретні: якими командами збирати й тестувати проєкт, які патерни навігації використовуємо, як називаємо файли, що заборонено чіпати (наприклад, згенеровані swift-java обгортки редагуються тільки через регенерацію), вимоги до PR. По суті CLAUDE.md — це онбординг-документ для «нового інженера», який приходить у проєкт кожну сесію.

Правила мають бути короткими. Роздутий CLAUDE.md на тисячі рядків працює гірше за стислий: модель губить фокус. Ми регулярно його чистимо — застарілі правила виносимо або видаляємо. Деталі, потрібні лише інколи, живуть у skills, які підвантажуються за потреби.

Skills, subagents і slash-команди, які ми використовуємо

Skills — це папки з інструкціями й best practices під конкретний тип задач, які Claude підвантажує, коли вони релевантні. Головна перевага формату: правила, які потрібні лише інколи, не роздувають CLAUDE.md і не з’їдають контекст постійно — Claude сам дістає skill тоді, коли задача цього вимагає. За пів року в нас накопичилось 77 скілів — по суті, це наша закодована інженерна експертиза: кожен повторюваний воркфлоу, кожен болючий урок і кожен «а як ми це робимо» з часом перетворюється на skill. Частина з них приходить з плагінів (наприклад, набори figma:* та superpowers:*), а більшість — власні, написані під наші проєкти. Ось кілька, якими користуємось найчастіше:

• superpowers:verification-before-completion — той самий верифікаційний skill, який замикає feedback loop: задача не завершена, поки зміни не зібрані й не перевірені. У парі з ним працюють ios-simulator-skill та android-testing-setup — механіка запуску й перевірки на симуляторі/емуляторі для кожної платформи.
• android-jetpack-compose-m3 разом з android-migrate-xml-views-to-jetpack-compose — наші правила роботи з Compose і Material 3: ідіоматичні патерни, стейт-менеджмент, типові пастки з lifecycle. Саме ці скіли витягли на собі перенесення UI з iOS на Android.
• figma:figma-design-to-code — доведення верстки до pixel-perfect по макету через Figma MCP: порядок дій, звірка зі скриншотом, робота з дизайн-токенами.
• codebase-memory — як правильно користуватись нашим knowledge graph (codebase-memory-mcp): які запити робити замість grep, коли переіндексовувати, як трактувати результати trace_path і detect_changes.
• orchestrate-batch-refactor, bug-hunt-swarm і review-swarm — сімейство «роєвих» скілів для паралельної роботи: як розбити великий рефакторинг на батчі для агентів у worktree, як запустити рій агентів на полювання за багами чи на рев’ю великого PR.

Окремо відзначу вузькоспеціалізовані скіли-експерти на кшталт swift-concurrency-expert, swift-security-expert, swiftui-performance-audit чи android-perfetto-trace-analysis — вони підключаються рідко, але саме в тих ситуаціях, де загальних знань моделі не вистачає і потрібна сконцентрована експертиза з конкретної теми.

Повний список наших скілів — на скриншотах нижче:

Правило просте, і воно збігається з порадою команди Claude Code: якщо ти робиш щось частіше ніж раз на день — зроби з цього skill або slash-команду.

Slash-команди (.claude/commands/, теж у git): /commit-push-pr для стандартного флоу з комітом і PR, /techdebt — прогін наприкінці сесії, який шукає дублікати й спрощує код, /sync-vault — оновлення бази знань після великих змін.

Subagents (.claude/agents/) — окремі агенти зі своїм контекстним вікном, промптом і набором тулів:

• code-simplifier — проходиться по щойно написаному коду і спрощує його (Claude, як і всі моделі, любить переускладнювати);
• build-validator — ізольовано збирає обидві платформи і репортить помилки;
• ui-reviewer — порівнює скриншот реалізованого екрана з макетом у Figma і перелічує розбіжності;
• docs-updater — після мерджа оновлює документацію і базу знань.

Головна цінність subagents — не лише автоматизація, а чистота контексту: важка підзадача виконується в окремому вікні й не засмічує основну сесію.

MCP-сервери

Наш поточний набір MCP значно компактніший, ніж був у Cursor-часи, — і це свідомо. Кожен зайвий MCP додає тули в контекст і розмиває фокус моделі, тож ми лишили тільки те, що реально працює щодня:

• codebase-memory-mcp — база знань по коду, про неї окремо нижче.
• Figma MCP — Claude тягне з макетів структуру, стилі, кольори і spacing та верстає UIKit/Compose максимально близько до дизайну. Це єдина річ, яка пережила міграцію з Cursor без змін.
• XcodeBuildMCP — керування Xcode-проєктами: білди, схеми, запуск на симуляторах, читання build-логів у структурованому вигляді.
• mobile-mcp — керування емуляторами/симуляторами і реальними девайсами: запуск застосунку, тапи, свайпи, скриншоти. Саме через нього Claude «тикає» застосунок під час самоперевірки на Android.
• Context7 — актуальна документація бібліотек, щоб Claude не галюцинував застарілі API (особливо актуально для Compose, який змінюється швидко).

База знань проєкту: Muses Vault і codebase-memory-mcp

Окрема тема, яка дала нам, мабуть, найбільший приріст якості відповідей Claude, — база знань проєкту, яку ми всередині називаємо Muses Vault.

Проблема, яку вона вирішує: агент кожну сесію починає «з нуля» і витрачає купу токенів та часу на дослідження кодової бази греп-ами й читанням файлів. На трьох взаємопов’язаних репозиторіях (iOS, Android, shared) це особливо боляче — щоб відповісти «хто викликає цю функцію і що зламається, якщо я зміню сигнатуру», треба фактично обійти всі три проєкти.

Спочатку ми вели базу знань як набір QMD/Markdown-документів: описи архітектури, модулів, ключових флоу, ADR. Це працювало, але мало два системні мінуси: документація неминуче відстає від коду, і вона описує те, що ми здогадалися описати, а не те, що агенту реально треба.

Потім ми перейшли на codebase-memory-mcp — і це виявилось якісним стрибком. Це MCP-сервер, який індексує кодову базу в персистентний knowledge graph: функції, класи, call chains, роути, зв’язки між модулями. Працює на tree-sitter AST-парсингу (158 мов, включно зі Swift і Kotlin) з додатковим шаром семантичної типізації (Hybrid LSP) для Kotlin. Один статичний бінарник, без Docker і залежностей, індексація середнього репозиторію — мілісекунди, структурні запити — під 1 мс.

Що це дає на практиці:

• Замість десятків grep/read-циклів Claude робить один запит до графа: trace_path («хто викликає ProcessPurchase і що вона викликає»), get_architecture (огляд модулів, entry points, hotspots), detect_changes (мапінг git diff на зачеплені символи з оцінкою blast radius). За даними авторів, це дає до 99% економії токенів порівняно з file-by-file дослідженням — і по наших відчуттях порядок цифр правдивий.
• Cross-repo intelligence: ми проіндексували всі три проєкти в одному сторі, і граф будує зв’язки між ними. Claude бачить, що Kotlin-обгортка в Android-репозиторії — це міст до Swift-функції у shared-бібліотеці, яку також використовує iOS-застосунок.
• Вбудована 3D-візуалізація графа на localhost — на скриншоті нижче видно, як виглядають наші три проєкти як «галактики» вузлів зі зв’язками між ними.

• Team-shared артефакт: стиснений снепшот графа (.codebase-memory/graph.db.zst) комітиться в репозиторій, тож нові члени команди (і CI-агенти) не переіндексовують усе з нуля.
• Фоновий watcher сам переіндексовує зміни по git — граф не застаріває, на відміну від рукописної документації.

QMD-документи ми при цьому не викинули повністю: ADR (Architecture Decision Records) і продуктовий контекст досі живуть у Markdown (частину ADR, до речі, тепер веде сам codebase-memory-mcp через тулу manage_adr). Але «що де лежить у коді і як пов’язано» — це тепер повністю територія графа.

Оркестрація задач: Orca і паралельні агенти

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

Рівень 1 — git worktrees. Кожна паралельна задача виконується в окремому git worktree, тож агенти не заважають один одному. У Claude Code це вбудовано: claude —worktree feature-name — і сесія працює в ізольованій копії репозиторію. Subagents також можуть отримувати worktree-ізоляцію (isolation: worktree у frontmatter агента), що ми активно використовували для масового перенесення екранів: «розбий екрани на батчі, запусти паралельних агентів у worktree, кожен тестує свої зміни end-to-end і ставить PR».

Рівень 2 — Orca — це ADE (Agent Development Environment), десктоп-застосунок для керування флотом паралельних агентів. Ключові фічі, за які ми його любимо:

• Parallel worktrees з єдиною панеллю керування: всі запущені агенти видно в одному місці — хто працює, хто чекає на інпут, хто закінчив. Можна навіть розігнати один і той самий промпт на кілька агентів у різних worktree і змерджити найкращий результат.
• Мобільний компаньйон: пуш, коли агент закінчив або чекає відповіді, і можливість відповісти йому прямо з телефона. Реально змінює відчуття від роботи — агенти «варяться» у фоні, поки ти на мітингу.
• Design Mode: клікаєш на будь-який елемент у вбудованому браузері — і його HTML/CSS зі скриншотом летить у промпт агента. Для веб-частин продукту (лендинги, вебв’ю) — топ.
• Annotate AI Diffs: коментарі прямо на рядках диффа, які відправляються агенту як фідбек, — рев’ю без перемикання контексту.
• Працює з будь-яким CLI-агентом, тож Claude Code підключається без танців.

Окремо про dynamic workflows у самому Claude Code — фічу, яку ми почали використовувати для найбільших задач. Якщо додати в промпт «use a workflow», Claude будує план оркестрації і виконує його через сотні паралельних субагентів за схемою: оркестратор → імплементатор → два незалежні верифікатори → фіксер, і цикл кожної підзадачі крутиться, поки верифікатори не дадуть зелене світло. Це вирішує три класичні проблеми довгих агентних сесій: «агентну лінь» (кидає задачу на половині), self-preferential bias (модель поблажливо оцінює власну роботу — тут верифікатор ніколи не є автором) і дрейф цілі після компакшенів контексту. Ми ганяли так, наприклад, масовий рефакторинг доступності (accessibility) по всіх екранах обох платформ — те, що зайняло б спринт, закрилось за день.

І ще один інструмент оркестрації в часі — /loop і /schedule: рекурентні задачі, які Claude виконує сам за розкладом. У нас крутиться loop, який доглядає відкриті PR (автофікс упалого CI, реакція на коментарі рев’ю), і ранковий scheduled job, що збирає підсумок нічних крашів із трекера.

Як правильно писати промпти: витяг з офіційної документації Anthropic

Anthropic веде офіційний гайд з prompt engineering, і я рекомендую прочитати його повністю, але ось головне, що ми звідти взяли й перевірили на практиці:

Будь чітким і прямим. Золоте правило з документації: покажи свій промпт колезі, який не має контексту задачі, — якщо він заплутається, заплутається і Claude. Модель варто сприймати як блискучого, але нового співробітника, який не знає ваших норм. Що конкретніше описані бажаний результат, формат і обмеження — то кращий вихід. Хочеш «зробити на совість, з запасом» — попроси про це явно, а не сподівайся, що модель здогадається.

Додавай мотивацію. Пояснення, чому правило важливе («не чіпай згенеровані обгортки, бо вони перезаписуються при регенерації»), працює краще за голу заборону — модель узагальнює з пояснення на суміжні випадки.

Приклади — найнадійніший важіль. 3–5 релевантних і різноманітних прикладів (few-shot) у тегах <example> стабільніше задають формат і стиль виводу, ніж будь-який опис словами.

Структуруй промпт XML-тегами. Коли в промпті змішані інструкції, контекст і вхідні дані — розділяй їх тегами (<instructions>, <context>, <input>). Це прибирає двозначність у тому, що є командою, а що — даними.

Довгий контекст — дані згори, питання знизу. Для промптів з великими документами (20k+ токенів) розміщення запиту в кінці, після даних, покращує якість відповіді до 30% за тестами Anthropic. Також допомагає попросити модель спершу процитувати релевантні фрагменти документа, а вже потім виконувати задачу.

Кажи, що робити, а не чого не робити. «Відповідай суцільними абзацами прози» працює краще за «не використовуй markdown».

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

Проси самоперевірку. «Перед завершенням перевір результат проти [критеріїв]» — надійно ловить помилки, особливо в коді. У нас це зашито в правила верифікації, але працює і як разова інструкція.

Окремо зазначу: сучасні моделі Claude дуже чутливі до інструкцій, тож старі промпти з «CRITICAL: You MUST...» тепер радше шкодять — модель починає переспрацьовувати. Достатньо нормальної людської мови: «Use this tool when...».

Що ще прискорює розробку: розсип порад

Наостанок — добірка речей, які реально працюють у мобільній розробці з Claude Code.

• Дай агенту спосіб перевірити свою роботу. Для мобільної розробки це симулятор/емулятор + MCP для керування ним; для веб — розширення Claude in Chrome; для бекенда — можливість підняти сервер і прогнати інтеграційний тест.
• Auto mode замість ручного підтвердження кожної дії. Класифікатор сам схвалює безпечні операції (читання файлів, запуск тестів) і питає лише про ризиковані. Це те, що робить можливою роботу з кількома агентами паралельно: поки один «вариться», ти займаєшся іншим.
• Голосовий ввід. Звучить як дрібниця, але говориш ти втричі швидше, ніж друкуєш, і промпти виходять детальнішими.
• Челенджи модель. «Доведи мені, що це працює», «знаючи все, що ти тепер знаєш, — викинь це рішення і зроби елегантне». Перше рішення моделі рідко найкраще, але вона майже завжди може краще, якщо попросити.
• /rewind замість виправлення в чаті. Коли агент пішов не туди — не сперечайся з ним у тому ж контексті (невдала спроба залишається у вікні й отруює його), а відкоти діалог і перепромпти з урахуванням вивченого.
• /compact з підказкою або /clear з рукописним брифом для довгих сесій — контекст деградує задовго до формального ліміту.
• Blindspot pass перед великою задачею. Промпт виду «я збираюся робити X, але погано знаю модуль Y — зроби blindspot pass і допоможи мені знайти мої unknown unknowns та краще тебе запромптити». Дешевше знайти підводні камені до написання коду.
• Квіз після великої сесії. Попроси Claude згенерувати звіт про зміни і квіз по них — і мерджи тільки коли пройшов його. Інакше через місяць ти не знатимеш власний код.
• PostToolUse-hook на автоформатування — SwiftFormat/ktlint запускаються після кожної правки файлів, і CI ніколи не падає на форматингу.
• З інструментів поза Claude Code: xcbeautify для читабельних логів xcodebuild досі з нами ще з Cursor-часів, Proxyman для дебага мережі (його логи чудово згодовуються Claude), і Fastlane, яким Claude сам користується для збирання релізних білдів.

Висновок

Пів року тому я писав, що Cursor «економить години рутини». Сьогодні формулювання інше: агентний підхід змінює саму економіку мобільної розробки. Android-застосунок, який за класичними оцінками коштував би нам пів року роботи окремої команди, ми зробили за місяць силами iOS-команди — завдяки трьом рішенням: залишити бізнес-логіку на Swift і крос-компілювати її через Swift SDK for Android замість переписування на KMP; побудувати навколо Claude Code систему з правил, skills, верифікації на реальних девайсах і бази знань на knowledge graph; і навчитися оркеструвати паралельних агентів замість роботи з одним чатом.

Головний практичний висновок, якщо винести один: інвестуйте у feedback loop і в записані правила. Агент, який може сам зібрати, запустити й перевірити свій код на девайсі, — це якісно інший інструмент, ніж агент, який просто пише текст. А кожна помилка, перетворена на рядок у CLAUDE.md, — це помилка, яку ви більше не побачите.

Happy Coding!

Запрошую до мого Telegram-каналу про iOS-розробку. Зв’язатися зі мною можна через LinkedIn.