CI/CD в эпоху агентов

С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический CI/CD, построенный вокруг pull request-ов и человеческого темпа разработки, плохо подходит для мира, где код всё чаще пишут агенты.

До работы с агентами цикл разработки выглядел так: человек медленно пишет код → оформляет PR → CI прогоняет линтеры, тесты и сборку → другой человек ревьюит изменения → изменения попадают в основную ветку.

В такой парадигме долгое время работы CI-пайплайна часто было ожидаемым и терпимым, потому что самая большая задержка всё равно была на стороне команды: разработчик писал код часами или днями, ревью тоже ждали часами или днями, PR жил долго.

С агентами всё меняется: код генерируется быстро и относительно дёшево → задач становится больше → ветки с изменениями плодятся быстрее → PR становится слишком медленной и неудобной единицей работы → валидацию изменений нужно двигать внутрь агентного цикла.

Но CI/CD вряд ли не исчезает. Скорее он перестанет быть контуром вокруг которого происходит работа с изменениями и превратится в низкоуровневый слой для быстрой проверки изменений внутри агентного цикла. Почему так?

CI/CD в текущем виде был спроектирован для мира, где человек — главный агент.

Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge. На каждом этапе может быть откат назад:

• PR не по принятому формату → назад к коду

• тесты упали → назад к коду

• ревьюер попросил изменить API → назад к коду

• merge queue показывает, что ветка отстаёт от main → назад к коду

Это уже агентный цикл, просто раньше агентом был человек. И в этом цикле роль harness-а (упряжки для агента) тоже выполнял человек: разработчик сам фокусировался на цели, писал код, запускал проверки, обрабатывал обратную связь от коллег и инструментов и доводил изменение до слияния.

Когда код пишет не человек, а агент, меняются масштабы:

• много агентов могут параллельно выполнять работу

• появляется много короткоживущих веток

• растёт количество PR

• частые исправления становятся нормальной частью агентного цикла

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

Если сравнить git с журналом изменений, то все сгенерированные агентами изменения должны попасть в него последовательно. Это начинает напоминать проблему из мира баз данных: транзакции, блокировки, порядок применения изменений (пресловутый serializable). Когда людей мало и они работают медленно, окно для слияния изменений может быть долгим по времени. Когда агенты генерируют пачки изменений параллельно, основная ветка постоянно обновляется, и шанс, что рабочая ветка быстро устареет, резко возрастает.

Сейчас, когда кодинговые агенты всё больше становятся привычным инструментом для команд, цикл разработки трансформируется примерно в такую схему:

Цель + план      ↓Агентный цикл:  генерация кода  внутренняя валидация: сборка, тесты, линтеры  внешняя валидация: человек или специализированные агенты  исправления по обратной связи      ↓Merge Queue      ↓Репозиторий

Кажется, следующим шагом будет сокращение участия человека внутри быстрого агентного цикла. То есть разработчику уже не придётся смотреть каждую итерацию изменений и каждый PR. Для этого появятся специализированные агенты. Можно легко представить такую агентную команду:

• основной кодинговый агент

• агент-ревьюер по безопасности

• агент-ревьюер по производительности

• агент-тестировщик

• агент-архитектор

• агент, оценивающий функциональную корректность реализации по требованиям

Человеку уже не нужно будет читать каждый diff, как это было раньше. Он будет смотреть на более высокий уровень:

• была такая цель

• вот что получилось

• вот summary изменений

• вот результат security-проверок

• вот риски

• вот демонстрация работы

И только после этого принимать решение: approve, reject или «нужны правки».

Также ставлю на то, что изменится сама концепция merge queue. Обычной очереди на слияние изменений будет недостаточно. Если много агентов параллельно меняют один и тот же код, системе придётся не просто запускать тесты перед merge, а группировать изменения, разрешать конфликты, проверять совместимость и выстраивать безопасный порядок применения.

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

В итоге мы получим не просто CI job после git push, а что-то ближе к continuous compute: вычислительную среду, которая постоянно работает вокруг intent-а, кода, валидации и изменений-кандидатов на слияние с основной веткой.

P.S. Пишу про прикладную ИИ разработку у себя в канале и блоге.