Разработка с ИИ-агентами перестала быть экспериментом и превратилась в рабочий инструмент. Но когда код пишется автоматически, встает вопрос качества и того, как выкатывать такие изменения в прод. Если агент может создать пул-реквест, почему бы не настроить пайплайн, который сам соберет билд, протестирует его и отправит в TestFlight? Разбираем по шагам, как выстроить такую систему.
Настройка правил для агента:
Все начинается с файла
agents.md в корне проекта. Это документ, где вы описываете, как агент должен писать код. Не абстрактно, а конкретно: отступы, предпочтения между SwiftUI и UIKit, работа с сетью, архитектурные паттерны.Чем детальнее правила, тем меньше шансов, что агент создаст что-то неожиданное. Видите, что он постоянно лепит новые сетевые слои вместо использования существующего APIClient? Добавляете правило и следующий код будет использовать правильные абстракции.
Это живой документ. В идеале он пополняется с каждой итерацией, когда вы замечаете, что агент делает что-то не так.
Планирование перед кодом:
Вместо того чтобы сразу отправлять агента в бой, полезно использовать режим планирования. Сначала агент описывает, что собирается делать: какие файлы менять, какой подход использовать, какие компромиссы допустимы. Вы читаете, корректируете и только потом даете зеленый свет.
Разница колоссальная. Вместо того чтобы разбирать потом гору неподходящего кода, вы сразу направляете агента в нужную сторону. Особенно это спасает, когда задача сформулирована не идеально и агент может интерпретировать ее совсем не так, как вы задумывали.
Автоматическое ревью:
Когда код написан, агент создает пул-реквест. И здесь в игру вступает второй агент - ревьюер. В Cursor, например, есть встроенный BugBot, который проверяет пул-реквесты на логические ошибки, краевые случаи и случайные изменения.
Он замечает то, что вы можете пропустить при беглом просмотре. Например, если в коде остались дебажные проперти, которые нигде не используются - BugBot их удалит. Если возможна гонка состояний при старте тренировки - предложит защиту. Это как второй взгляд, только автоматический и всегда доступный.
CI как второй уровень защиты:
Даже если агент прогнал тесты локально, полезно иметь еще один слой проверки. Bitrise (или Xcode Cloud, или GitHub Actions) запускает тесты на каждый пул-реквест. Если что-то сломалось - статус красный, мержить нельзя.
Отдельный пайплайн собирает релиз при мерже в основную ветку. Тесты прогоняются снова (на всякий случай), потом архив, подпись и отправка в App Store Connect. Все автоматически, без участия человека.
Почему тесты становятся критичными:
С агентами тесты превращаются в контракт. Они описывают ожидаемое поведение, и если агент его нарушает - тесты падают. Это единственный способ гарантировать, что автоматически сгенерированный код делает именно то, что нужно.
TestFlight как финальная точка:
Когда все собрано и залито, вы просто получаете уведомление о новом билде в TestFlight. Никаких ручных действий, никакого ожидания.
Это замыкает цикл: идея -> промпт -> код -> ревью -> тесты -> сборка -> установка на устройстве. И все это без необходимости открывать Xcode.
🔗 Ссылка на подробную статью
💡 Вывод:
Настроить такую систему можно один раз, и потом она работает сама. Это не про отказ от контроля, а про его автоматизацию. Агенты пишут код, агенты его проверяют, CI тестирует и собирает, а вы только направляете процесс и принимаете решения. В мире, где скорость выхода новых версий становится конкурентным преимуществом, такой подход дает серьезный запас прочности.
➡️ Подписаться на канал
Мобильный трудоголик