Непрерывная интеграция (CI) стала новым узким местом по мере расширения использования программных агентов. Этот вывод основан не на объявлении одного инструмента, а на опыте, представленном инженерными командами Anthropic, Linear и Depot в течение сентября. Объём заданий CI в Anthropic вырос в 25 раз за шесть месяцев, а её инженеры стали поставлять за квартал примерно в восемь раз больше кода, чем они поставляли в период с 2021 по 2025 год. В Linear размер набора тестов приблизился к четырёхкратному уровню по сравнению с январём, а агенты теперь пишут большинство тестов.
Anthropic ответила использованием анализа влияния тестов, чтобы запускать только те тесты, на которые, вероятно, повлияло изменение, а Linear почти полностью переработала свой конвейер. Эти меры сокращают время ожидания, но устраняют лишь один уровень проблемы: скорость проверки репозитория.
Почему скорости CI больше недостаточно?
Исторически CI проектировалась под человеческий рабочий процесс: разработчик открывает ограниченное число запросов на слияние в неделю, а затем ждёт результата работы конвейера, переходя к другой задаче. Агент же может параллельно создавать код, тесты и запросы на слияние, что многократно увеличивает число операций CI. В статье указывается, что Blacksmith, компания, продающая исполнители CI, зафиксировала еженедельный рост числа запускаемых ею заданий на 5–10%.
Вторая проблема заключается в месте проведения проверки. Агент пишет изменение, а затем ждёт результата после создания запроса на слияние. Когда результат приходит через 20 минут, он мог уже потерять контекст задачи, а каждая проблема означает новый цикл ожидания.
Репозиторий — это не система
В автономных приложениях тестирование репозитория может давать картину, близкую к поведению системы. Однако в облачно-нативной среде репозиторий представляет собой один сервис в экосистеме, которая может включать десятки сервисов, тогда как остальная часть системы обычно представлена заглушками или тестовыми данными.
Поэтому изменение может успешно пройти модульные тесты, CI и работу в изолированной среде, а затем завершиться сбоем при первом реальном запросе, пересекающем границы сервисов. Примерами могут быть изменение имени поля, от которого зависит другой сервис; сокращение тайм-аута, приводящее к цепочке повторных попыток; изменение схемы, вызывающее блокировку таблицы в тестовой среде; или конечная точка, которая ведёт себя иначе при фактическом вызове потребляющим её сервисом.
В статье приводятся данные DevOps Research and Assessment (DORA), связывающие более широкое внедрение искусственного интеллекта одновременно с ростом частоты поставки программного обеспечения и нестабильностью поставки. Иными словами, более быстрое создание кода не гарантирует более качественную проверку.
Что меняется на практике?
Предлагаемое решение заключается не в отмене CI и не в замедлении агентов, а в переносе части проверки на более ранний этап рабочего цикла агента, чтобы изменение тестировалось against фактической системой, а не только копией репозитория. Такие инструменты, как Cursor, используют изолированные облачные среды; более 30% запросов на слияние, которые объединяет Cursor, поступают от агентов, работающих таким образом. Другие инструменты, включая GitHub Copilot cloud agent, Codex, Devin и Greptile, также предоставляют различные формы запуска кода во временных средах.
Однако эти среды обычно содержат ветку, её настройки и то, что может установить скрипт настройки, но не другие сервисы, реальный список сообщений и базу данных, похожую на производственную. Поэтому, по мнению статьи, цикл замыкается, но он может замыкаться вокруг неправильного объекта.
Общие среды и управляемая проверка
В статье предлагается запускать стабильную общую копию сервисов внутри кластера Kubernetes, создавая облегчённые тестовые среды, которые разворачивают только изменённый сервис. Запросы с соответствующей меткой направляются к этому сервису, а остальные маршруты подключаются к общим стабильным копиям. Благодаря этому большое число агентов может совместно использовать среду вместо полного копирования системы для каждого агента; в статье оценивается, что стоимость среды может приближаться к стоимости одного контейнера, а её запуск занимает секунды, однако источник не приводит независимых измерений, подтверждающих эти оценки во всех средах.
Одной среды недостаточно. Командам платформы нужны утверждённые процедуры, определяющие, какие запросы отправляются, какие журналы собираются и какие контракты необходимо подтвердить. Следует также регистрировать сервисы, которых коснулась проверка, и её результаты, чтобы журнал можно было читать инструментами ревью и шлюзами слияния. Автор подчёркивает, что управление необходимо для предотвращения выполнения агентами небезопасных действий внутри общего кластера.
С точки зрения certi.news, настоящее изменение заключается не просто в ускорении CI, а в переопределении того, что должно означать «успешное» прохождение проверки. Тестирование репозитория по-прежнему важно, но одного его недостаточно для распределённых систем, которые агенты создают с большей скоростью. Вопросы стоимости, изоляции, безопасности данных и измерения точности проверки остаются открытыми, а материал представляет аналитический тезис, а не подтверждённый стандарт или конкретный продукт.