AI-агенты в CI резко поменяли математику разработки: Anthropic сообщила о 25-кратном росте числа CI-задач за шесть месяцев, а Linear — о почти четырехкратном увеличении тестового набора с января. Проблема уже не в том, что пайплайн «медленный», а в том, что он проверяет репозиторий, пока реальный продукт живет в распределенной системе из сервисов, зависимостей и контрактов.
Об этом пишет The New Stack в материале Арджуна Айера, где он предлагает читать вместе три сентябрьские публикации: инженерный разбор Anthropic, пост Linear о перестройке CI и колонку CEO Depot о будущем доверия к коду, который пишут агенты. Общий вывод неприятный для тех, кто только что купил более быстрые раннеры: ускорение полезно, но оно не закрывает главный разрыв между генерацией кода и проверкой поведения системы.
У Anthropic объем CI-job вырос в 25 раз за полгода. По словам команды, инженеры теперь поставляют примерно в 8 раз больше кода за квартал, чем в период с 2021 по 2025 год. Ответом стала test impact analysis: запускать не весь тестовый набор, а только те тесты, которые потенциально затрагивает конкретное изменение. Это здравый инженерный ход, особенно когда каждый лишний прогон начинает превращаться в счет за инфраструктуру.
Linear столкнулась с похожей, но чуть более приземленной болью. Ее тестовый набор почти учетверился с начала года, а большую часть новых тестов теперь пишут агенты. Команда перепахала пайплайн целиком: оптимизировала критический путь, уменьшила повторяющуюся настройку окружения, пересмотрела выполнение тестов и правила для агентного кода. Важная деталь: проблема пришла не от «плохих» тестов, а от того, что хорошая практика — писать больше проверок — внезапно стала масштабироваться машинной скоростью.
Старый CI проектировался под человеческий темп. Разработчик открывал несколько pull request в неделю, запускал проверки, переключался на соседнюю задачу или шел на встречу. Даже 20 минут ожидания не выглядели катастрофой: человек все равно не компилируется в реальном времени. Агент работает иначе. Он может написать код, открыть PR, дождаться красного статуса, внести правку и снова дернуть пайплайн. Если таких агентов несколько на одного инженера, нагрузка растет не на проценты, а кратно.
Отсюда первая очевидная реакция рынка: сделать CI быстрее. Больше кэшей, умнее выбор тестов, мощнее раннеры, параллельные шарды, пайплайны, которые агент может дергать до коммита. Поставщик CI-раннеров Blacksmith, по данным материала, видит рост числа выполняемых CI-задач на 5-10% неделю к неделе. Для инфраструктурных вендоров это почти музыка, для финансового отдела — не всегда.
Но Айер спорит именно с этим инстинктом. Быстрый CI все равно отвечает на старый вопрос: проходит ли этот репозиторий собственные проверки? В монолите этого часто достаточно. В cloud-native-системе один репозиторий — это один сервис из десятков. Unit-тесты могут быть зелеными, мок внешней зависимости — послушным, sandbox — красивым, а первый реальный запрос через границу сервисов все равно развалится из-за несовместимого контракта, миграции, сетевого поведения или очереди событий.
Для русскоязычных команд здесь есть практичный урок, без магии и презентаций про «AI-first». Если вы внедряете Cursor, Claude Code или другие агентные инструменты, CI-бюджет и CI-архитектура становятся частью стратегии, а не хозяйственной задачей DevOps-инженера на пятницу. Нужно заранее понять, какие проверки агент обязан запускать до PR, какие тесты можно выбирать по impact analysis, где нужны эфемерные окружения, а где хватит локального контракта. И отдельно — какие действия агенту запрещены в shared-кластере, даже если он очень уверенно попросил доступ.
Для бизнеса это сдвиг в метриках. Смотреть только на количество сгенерированных строк или закрытых тикетов уже опасно: агент может ускорить написание кода и одновременно забить очередь проверок, поднять расходы на раннеры и увеличить число ложных «зеленых» изменений. Более полезные показатели — время до надежной обратной связи, стоимость проверки одного изменения, доля падений на границах сервисов и число ручных итераций после агентного PR.
AI-агенты в CI не отменяют классическую автоматизацию, но делают ее недостаточной. Следующий спор в инженерных командах будет не о том, какой раннер на 30% быстрее, а о том, где именно должен жить контур доверия: после pull request в CI или внутри рабочего цикла агента, до того как код вообще попросится в основную ветку.