За последние полгода я перетряс свой рабочий стек полностью: 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.mdAGENTS.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 у меня скорее ломал больше, чем чинил — и я понимаю коллег, которые говорят, что «у них не взлетело». Возможно, дело в том, что стек пока не докрутили.