Классический цикл разработки строился вокруг человеческого темпа: разработчик часами или днями пишет код, оформляет pull request, CI прогоняет тесты, коллега делает ревью — и только потом изменения попадают в основную ветку. Долгое время работы пайплайна никого особо не беспокоило, потому что самая большая задержка всегда была на стороне команды.
С появлением кодинговых агентов пропорции меняются. Код генерируется быстро и дёшево, задач становится больше, коротких веток — тоже. PR как единица работы не успевает за темпом: пока один агент ждёт прохождения CI и человеческого ревью, другие уже сгенерировали новые изменения, и рабочая ветка успевает устареть. Проблема не только в скорости — сам процесс слияния изменений превращается в бутылочное горлышко.
Автор материала проводит точную аналогию с базами данных: git — это журнал изменений, и все правки должны попасть в него последовательно. Когда разработчиков мало и они работают медленно, окно для слияния широкое. Когда агенты параллельно генерируют пачки изменений, основная ветка обновляется постоянно — и шанс конфликта резко возрастает. Это та же задача, что serializable-транзакции в СУБД, только применительно к git-истории.
Слияние изменений в git при параллельной агентной работе напоминает проблему транзакций в базах данных.
CI/CD при этом не исчезнет. Скорее он перестанет быть внешним контуром вокруг работы с изменениями и превратится во внутренний слой агентного цикла: генерация кода → внутренняя валидация (сборка, тесты, линтеры) → внешняя валидация → исправления → merge queue → репозиторий. Человек в этой схеме уходит с уровня каждого diff-а на уровень итогового решения: была цель — вот результат, вот summary изменений, вот риски, вот демонстрация работы. Approve или reject.
Для внешней валидации появятся специализированные агенты: ревьюер по безопасности, ревьюер по производительности, агент-тестировщик, агент-архитектор, агент оценки функциональной корректности по требованиям. Это не фантастика — такие роли уже начинают реализовываться в экспериментальных агентных пайплайнах.
Merge queue тоже эволюционирует. Обычной очереди на слияние будет недостаточно: системе придётся группировать изменения, разрешать конфликты, проверять совместимость и выстраивать безопасный порядок применения — задача, которая сейчас решается вручную или полуавтоматически.
Среды для агентных проверок станут stateful: с заранее подготовленными зависимостями, прогретыми кэшами и сохранённым состоянием между итерациями. Холодный старт окружения на каждый агентный шаг сделает цикл неприемлемо медленным. В результате вместо привычного CI job после git push появится то, что можно назвать continuous compute — вычислительная среда, которая постоянно работает вокруг намерения, кода, валидации и кандидатов на слияние.
