📼 Agentic Engineering и архитектура: CI/CD

На прошлом этапе мы научили агента самостоятельно собирать проект. Но успешный BUILD SUCCEEDED еще не означает, что агент сделал все правильно.

Следующий шаг это научить его самостоятельно проверять результат своей работы.

Вообще, чем полезны CI/CD проверки, что их не могут хакнуть ни агенты, ни человеки. У вас есть закрытый от посторонних флоу, который нельзя разломать и +- детерминированный.

Раньше пайплайн выглядел как агент пишет код, а человек проверяет

Теперь можно замкнуть dev loop и сделать: Agent пишет код -> собирает -> тестирует -> исправляет -> повторяет.

Для этого агенту нужны несколько quality гейтов:

1️⃣ Unit-тесты

После изменений агент сам запускает нужные XCTest через xcodebuild test.

Причем лучше не гонять весь проект каждый раз, а сначала тесты затронутого модуля.

2️⃣ Lint / Format

SwiftLint и SwiftFormat становятся не просто инструментами команды, а уже частью обратной связи агента.

Написал код, получил нарушения исправил, и проверил снова. Но в идеале конечно при генерации кода заранее ему сказать смотреть в линтер...

3️⃣ UI / Snapshot tests

Особенно полезно для задач, где код компилируется, тесты зеленые, но интерфейс агент все-таки разломал.

Агент может запустить приложение на симуляторе, сделать скриншоты или снапшоты и проверить результат.

4️⃣ Свой верифай

Самый удобный вариант — вообще спрятать все это за одной командой: ./scripts/verify.sh

А внутри уже делать: build lint, E2E tests, snapshots

Тогда агенту не нужно каждый раз объяснять, как проверить свою работу. У него появляется простой контракт: изменение считается законченным только тогда, когда verify прошел. И вот здесь агент из генератора кода постепенно превращается в полноценного участника инженерного цикла.