Gautam Korlam: CI для агентного потока изменений (Рубрика #AI4SDLC)

Агент за минуту исправил код, потом десять минут ждал CI. Проверка упала, пошёл следующий круг. После третьей попытки кто-нибудь открыл ревью и попросил ещё одну правку. Знакомая инженерная карусель, которую быстрый кодинг только раскручивает :) Про неё — 19-минутный доклад "Rebuilding CI for AI-Scale Commit Volume" от Gautam Korlam, сооснователя Gitar, который теперь часть Sonar, а Gautam теперь principal engineer в Sonar. Его тезис: поток агентных изменений упирается в пропускную способность сборок, проверок и согласований. Здесь интересна именно механика этих задержек.

🔸 Зелёные PR могут сломать общую ветку
Корлам рассказывает про Uber SubmitQueue: очередь заранее проверяет вероятные сочетания изменений. Успех отдельных PR ещё не подтверждает их совместимость. В моём понимании, зелёная галочка всегда требует уточнения: какой состав кода она проверила?

🔸 Каждая попытка исправления снова оплачивает CI
Спикер приводит две показательные цифры:
- как минимум у 13% PR на его платформе случался отказ обязательной проверки;
- в команде Gitar примерно десятиминутный CI сократили до менее минуты для прогретых инкрементальных шагов: кеши, меньше лишней инвалидации, шардирование. Холодная сборка в это обещание не входит.

Это данные самого докладчика. А я бы рядом со временем запуска мерил число проходов до принятого изменения. Три быстрые правки могут означать три полные сборки и три ожидания. Тут появляется вполне осязаемая цена каждой следующей попытки агента.

🔸 Ревью тоже надо уметь разгружать
Корлам предлагает автоматизировать первый проход и допуск подходящих рутинных изменений, а чувствительные отправлять человеку. Автор изменения не должен сам его одобрять. Есть и конкретный кейс: тесты распараллелили через nextest, но оставили общую БД без необходимых защит от взаимного влияния. По словам Корлама, Gitar поймал и исправил проблему до merge. Ускоряли CI — чуть не получили нестабильные тесты.

Мне здесь интереснее всего определение риска. Обновление зависимости может поменять поведение сервиса, а правка внутреннего инструмента — затронуть выпуск всей компании. Хочется увидеть ошибочный автоматический допуск и то, как после него поменяли политику. И ещё считать работу, которую создал AI-ревьюер: каждое замечание кто-то должен разобрать, даже если замечание оказалось ерундой.

🔸 Основания для merge должны пережить логи CI
В финале Корлам разбирает сохранение проверенного коммита, отчёта, независимого approval и причин исключений. Вот это особенно полезная часть. Через полгода хочется восстановить, почему конкретный сбой разрешили пропустить и кто принял решение. Название ветки уже может указывать на другой код. И я бы сохранял такой контекст сразу вместе с изменением: потом собирать историю по исчезнувшим логам будет поздно.

Этот доклад продолжает тему моих разборов CI/CD и скорости доставки и Scion: рост потока изменений заставляет пересматривать устройство всего конвейера. Здесь фокус — на пути от предложенной правки до принятого кода.

В выступлении есть и демонстрация Gitar, так что универсальную эффективность продукта из этих примеров выводить рано. Я бы забрал из него вопрос для своей команды: сколько времени и повторной работы стоит одно принятое изменение — вместе с исправлениями, замечаниями и исключениями?

#AI4SDLC #DevOps #DevTools #Engineering #Metrics