AI в iOS-разработке: что у меня реально закрепилось в 2026, а что я выкинул

За последние полгода я перетряс свой рабочий стек полностью: Cursor, Claude Code, Codex, локальные Qwen-модели для ревью, несколько итераций своего AGENTS.md, Xcode MCP, mobile-mcp, Conductor для параллельных сессий. Что-то прижилось, что-то я удалил через неделю, а какие-то практики, которые ещё весной казались обязательными, сейчас выглядят странно.

Ниже — мои личные заметки по итогам этих полугода, а не обзор индустрии. Многое я подсмотрел у коллег и в чатах, не всё придумал сам.

1. Минимализм в AGENTS.md

Если у вас CLAUDE.md (или AGENTS.md — тут неважно) длиной под две сотни строк, с описанием архитектуры, код-стайла, бизнес-домена и словариком сокращений — попробуйте его сократить раз в десять. Скорее всего, станет лучше.

У меня самого был файл на 180+ строк. Я сносил его два вечера, в итоге осталось восемь. Ощущение от сессий поменялось заметно: меньше случаев «модель зачем-то пересказывает мне мой же конфиг в первом ответе», больше релевантных правок с первого раза.

Почему так — по моим ощущениям: у моделей есть context window, и есть его рабочая часть. Первый может быть миллионным, вторая начинает подплывать где-то в районе сотни тысяч токенов, плюс «lost in the middle» никто не отменял. Всё, что вы впихнули в начало «на всякий случай», пожирает именно рабочую часть.

Мой текущий файл выглядит примерно так:

# iOS App
## Quick links
- @.agents/code-review.md — PR review protocol
- @docs/architecture.md — модули и границы
- @SPECS/WORKFLOW.md — правила работы с фичами
## Core rules
1. Specs first — код без обновлённой спеки не принимается
2. `make verify` перед завершением задачи
3. Preview должен совпасть с Figma — запускай Vision-сравнение
4. На legacy-части проекта не auto-apply, только с ревью

Всё остальное — это скиллы и документы, которые агент подтягивает сам по ссылке, когда они действительно нужны.

2. AGENTS.md как единый источник

Если вы работаете сразу с Cursor, Claude Code и Codex, у каждого инструмента свой «канонический» конфиг: CLAUDE.md, .cursorrules, AGENTS.md. Попытка поддерживать их синхронно заканчивается дрейфом правил примерно всегда.

Мне помогло максимально тупое решение:

mv CLAUDE.md AGENTS.md && ln -s AGENTS.md CLAUDE.md

AGENTS.md поддерживают OpenAI, Cursor и куча опенсорса — де-факто это сейчас самый живой формат. Симлинк закрывает Claude Code. Один источник, ноль расхождений. Я видел пару команд, где вместо симлинка стоит генератор, собирающий три файла из одного шаблона — работает тоже, но сложнее.

Один неприятный момент, про который стоит помнить: системный промт Claude Code меняется часто, без анонсов, и он приоритетнее вашего AGENTS.md. Для критичных инвариантов на инструкции в AGENTS.md я лучше не опираюсь — если правило должно выполниться обязательно, для него есть pre-commit hook.

3. CLI почти всегда лучше MCP, когда речь про Xcode

В Xcode 26.3 Apple выкатила свой MCP-сервер — сборка, тесты, работа с файлами проекта. Я честно пробовал его месяц. В основе у него UI-автоматизация самого Xcode, и это отчётливо чувствуется: медленнее и менее предсказуемо, чем прямой вызов инструментов.

Тонкие скрипты поверх xcodebuild, xcrun simctl и xcbeautify почти всё покрывают:

# Скриншот симулятора
xcrun simctl io booted screenshot /tmp/screen.png
# Логи приложения — без Console.app
xcrun simctl spawn booted log show --predicate 'processImagePath contains "MyApp"' --last 1m
# Сборка с нормальным выводом
xcodebuild build -scheme MyApp | xcbeautify

Исключение, ради которого я Xcode MCP всё-таки держу — рендер SwiftUI Preview в картинку. Через CLI это тоже технически делается, но заметно муторнее. Этот рендер, кстати, открывает следующий сценарий.

4. Vision + SwiftUI Preview для сверки с Figma

Собираем Preview конкретной вьюхи через Xcode MCP, получаем PNG, берём её эталон из Figma через Figma MCP, и просим Vision-модель сравнить. На выходе — текстовый отчёт: отступ 16 вместо 12, цвет #2A2A2A вместо #1F1F1F, не тот шрифт.

Это не заменяет дизайн-ревью целиком. Композицию, насколько макет вообще имеет смысл, и попадание в tone of voice человек всё равно оценивает лучше. Но эта связка закрывает самую нудную часть — попиксельную сверку, в которой человек ошибается сильнее всего к концу дня.

Я держу это в make verify, чтобы отчёт автоматически генерировался на pre-commit. Экраны с большими расхождениями — красный флаг, с мелкими — сноска в MR.

5. Видео как основной артефакт ревью

Пожалуй, моя любимая iOS-специфика из того, что прижилось.

Выглядит это примерно так. На задачу поднимается чистая VM с симулятором. Агент билдит приложение, запускает mobile-mcp, тыкает по сценарию из спеки. Весь прогон пишется в видео через xcrun simctl io booted recordVideo. В MR кладём описание, несколько скриншотов ключевых экранов и сам ролик.

xcrun simctl erase all
xcodebuild build -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16 Pro'
xcrun simctl io booted recordVideo /tmp/run.mp4 &
REC_PID=$!
xcodebuild test -scheme MyAppUITests -destination 'platform=iOS Simulator,name=iPhone 16 Pro'
kill -TERM $REC_PID

На себе я заметил, что смотреть минутный ролик сильно дешевле, чем продираться через diff на несколько сотен строк — особенно если задача про UI. Агент, получая тот же ролик перед оформлением MR, довольно часто сам ловит у себя ошибки и переделывает.

Очевидный минус: для чисто логических/модульных изменений никакого видео не нужно, достаточно обычных тестов. Я не стал навязывать ролик всем типам задач, это не обязательный пункт в шаблоне MR.

6. Спека раньше кода

Есть неутихающий спор: смотреть каждый diff от агента или верифицировать только результат. Для себя я пришёл к такому компромиссу.

На greenfield-проекте или в прототипах auto-apply — нормально, агент может писать и коммитить сам. Код всё равно два-три раза перепишется до релиза, и ловить каждую строчку бессмысленно.

На проекте с сотнями тысяч строк легаси я verify каждый шаг. Это не потому, что «так правильнее», а потому что цена ошибки в таких проектах растёт нелинейно.

Оба режима, на мой взгляд, работают только при одном условии: у задачи есть markdown-спека в репе. Не JIRA-тикет, не тред в чате, а файл примерно такой формы:

## Context & Goals
## Technical drivers
## Current state
## Options considered (и почему выбрали эту)
## Implementation details
## Definition of Done
## QA notes

У меня такие спеки выходят на 3–8 страниц — в зависимости от задачи. Много? Когда я впервые сел это писать, казалось избыточным. Но агент, идущий по подробной спеке, ошибается ощутимо реже, а главное — спека переживает сессию. Можно вернуться через две недели, и контекст восстанавливается за минуту.

7. Definition of Done как контракт

На одном из своих проектов я поймал себя в идиотской петле: агент чинил несколько связанных багов, каждый фикс ломал следующий, за полдня я так и не сдвинулся с места. Когда разобрался, увидел, что корень всего — один неправильный lookup, который был виден в debug-трейсе буквально за минуту, если туда посмотреть.

С тех пор в DoD я кладу именно проверяемые команды, а не формулировки в стиле «всё должно работать»:

## Definition of Done
- [ ] `xcodebuild build -scheme MyApp` — zero warnings
- [ ] `xcodebuild test -scheme MyAppUnitTests` — all pass
- [ ] `make test-e2e` — all pass, видео приложено к MR
- [ ] Preview совпадает с Figma (отчёт Vision-сравнения приложен)
- [ ] Нет изменений в SPECS/ без обновления INDEX.md

Когда у агента в спеке лежит такой чек-лист, он сильно меньше импровизирует. Каждая строчка превращается в команду с булевым исходом — спорить не о чем.

8. Параллельные сессии и worktree

Про это я почти нигде не встречал внятного описания, но разница по ощущениям большая. Правило у меня простое: одна сессия агента — один git worktree.

git worktree add ../myapp-feature-a feature/a
git worktree add ../myapp-feature-b feature/b

Три параллельные задачи — три папки, три сессии. Никто ни у кого не затирает изменения и не заливает контекст. Для оркестрации я пробовал cmux (tmux для агентов) и Conductor — первый привычнее, второй красивее. Остановился на cmux: мне важнее быстро переключаться между сессиями, чем смотреть на них.

9. Где AI у меня стабильно проваливается

Чтобы не выглядело слишком благостно — вот что я до сих пор либо делаю руками, либо очень плотно контролирую:

• Swift Concurrency: @MainActor, sendable-конформанс, isolated. Модели пишут правдоподобный код, который либо не компилируется, либо компилируется с race condition, которая проявится через неделю.

• Миграция с @ObservedObject на @Observable. Старый и новый API смешиваются в одном файле почти всегда; нужна очень чёткая спека и ручные чекпоинты.

• Build settings, схемы, .xcconfig, всё что лежит в .xcodeproj как XML. Быстрее и безопаснее руками.

• App Store Connect, провижининг, сертификаты — здесь никакой AI не помогает, это скорее ритуал поверх Fastlane.

• Старый Objective-C с кривой мапой модулей. В Bridging Header и #import-ах модель путается почти сразу.

10. Мой текущий стек

Для прозрачности. Сейчас у меня активно используется Claude Code как основной агент, Codex через ChatGPT для перекрёстного ревью, GitHub Copilot в PR-ах, Serena MCP для навигации по символам (заметно экономит токены по сравнению с grep), Xcode MCP — только ради Preview, Figma MCP плюс Vision-модель для сверки с макетами. Cursor держу на случай задач, где важно переопределить системный промт.

По деньгам выходит где-то в районе сотни долларов в месяц, плюс-минус. Окупается очень по-разному: в одних спринтах AI даёт сэкономить пару дней, в других тормозит ровно в тех местах, про которые я писал в разделе 9. Среднее по году — положительное, но не «пишу в десять раз быстрее».

Вместо заключения

По моим ощущениям, работа iOS-разработчика постепенно сдвигается от «я пишу код» к «я пишу спеки и смотрю видео прогонов». Это не апгрейд профессии и не её деградация, скорее другой набор повседневных действий. Меньше рутины в SwiftUI и build-скриптах, больше работы головой над тем, что именно мы строим и как это проверять.

Но работает это при выстроенном workflow. У меня лично эффект появился только после того, как AGENTS.md усох до восьми строк, спеки стали обязательными, а видео начало заменять чтение диффа на ревью. До этого момента AI у меня скорее ломал больше, чем чинил — и я понимаю коллег, которые говорят, что «у них не взлетело». Возможно, дело в том, что стек пока не докрутили.