Всем привет, меня зовут Сергей Прощаев, я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

В этой статье расскажу о парадоксе, который осенью 2026 года подтверждают сразу несколько крупных исследований: AI‑инструменты и агенты ускоряют написание кода, а изменения доезжают до main не быстрее, а иногда и медленнее, чем год назад.

Представим типичный сценарий.

Разработчик с агентом за вечер собирает фичу, на которую раньше ушла бы неделя. Открывает MR на полторы тысячи строк. Дальше MR лежит три дня, потому что у ревьюера ещё четыре таких же. Потом приходит approve с одним комментарием про название переменной, задача уезжает в QA и застревает уже там. А через неделю в проде всплывает то, что в этих полутора тысячах строк никто толком не прочитал.

Главное, если коротко: AI ускоряет генерацию изменений быстрее, чем команда успевает их проверять, интегрировать и доставлять. Поэтому выигрыш на этапе написания кода не превращается сам по себе в выигрыш по времени поставки. Узкое место не исчезает, а переезжает дальше по конвейеру.

Парадокс в цифрах

Я не люблю тексты, где тренд подтверждается одной цитатой из чьего‑то поста, поэтому посмотрел на проблему с трёх сторон: телеметрия Faros AI, данные CI от CircleCI и опросное исследование DORA. Картина похожая, но детали и выводы различаются, и именно различия здесь интереснее всего.

1. Faros AI собирает данные из трекеров, IDE, систем контроля версий и CI/CD. В исследовании «The AI Productivity Paradox», опубликованном в июле 2025 года по данным больше 10 тысяч разработчиков из 1 255 команд, разработчики, активно использующие AI‑ассистенты, закрывали на 21% больше задач и вливали на 98% больше pull request. При этом время ревью выросло на 91%, средний размер PR — на 154%, число багов на разработчика — на 9%, а на уровне компании значимой связи с результатом исследователи не нашли.

2. Свежий материал Faros “The Speed Trap”, опубликованный 18 сентября 2026 года по телеметрии за 12 месяцев от 22 тысяч разработчиков из 4 тысяч команд, показывает, куда очередь двинулась дальше. Время в QA выросло на 300,6%, это самое сильное ухудшение среди метрик потока. Средний размер PR всё ещё на 71,8% выше базового уровня, число инцидентов в месяц выросло на 125,4%. И ещё один тревожный показатель: рост числа PR, влитых без ревью, полгода назад составлял 31,3%, а теперь 76,3%.

3. CircleCI в отчёте о поставке ПО за 2026 год разобрал 28,7 миллиона прогонов CI за сентябрь 2025 года. Среднее число ежедневных прогонов выросло на 59% год к году. Но у медианной команды активность в feature‑ветках выросла на 15%, а в main снизилась на 7%. Доля успешных сборок main опустилась до 70,8%, минимума за пять лет, а медианное время восстановления до зелёной сборки составило 72 минуты. Заметно нарастить одновременно и разработку, и прохождение изменений через main смогли меньше 5% команд.

4. DORA в отчёте 2024 года нашла статистическую связь: рост использования AI на 25% сопровождался оценочным снижением скорости поставки на 1,5% и стабильности на 7,2%. А вот в 2025 году картина изменилась: связь AI со скоростью поставки и результатами продукта стала положительной, а со стабильностью осталась отрицательной. Авторы называют AI “зеркалом и мультипликатором”: он ускоряет разработку, но без сильной автоматизации тестов и быстрой обратной связи рост объёма изменений превращается в нестабильность.

То есть источники не во всём сходятся. Faros в 2025 году не увидел эффекта на уровне компании, DORA в 2025 году уже видит рост скорости, но ценой стабильности.

Общее у них одно: генерировать код стало дешевле, проверять результат — нет.

Объект разбора: где стоит очередь

Чтобы понять, где именно застревает работа, я разложил путь одного изменения. Он показан на Рис. 2.

Главная мысль схемы: CI, AI‑ревью и ревью человеком идут параллельно, а за ними стоят QA, интеграция и выкладка. Цвет на схеме — метафора, а не статус пайплайна: агент ускоряет зелёный блок, а пропускная способность красных сама по себе не растёт вслед за скоростью генерации.

На конкретном проекте часть QA и интеграционных проверок может стоять до merge. Для статьи важно не их точное место, а то, что все они идут после генерации изменения.

Под этим лежит простая модель из теории очередей. Если изменения поступают быстрее, чем система успевает их обработать, растёт очередь, а вместе с ней незавершённая работа и время поставки. AI увеличивает скорость поступления изменений.

Если пропускная способность ревью, QA и интеграции не растёт вместе с ней, очередь появляется там, где ресурса меньше всего: у одной команды это ревью кода, у другой — QA, у третьей — интеграция и выкладка.

Дальше — четыре наблюдения о том, как это проявляется. Начну с ревью, потому что его видят все, но не на нём одном всё держится.

Наблюдение 1. MR растёт быстрее, чем пропускная способность ревью

Рост размера PR меня не удивил. Сам по себе агент не оптимизирует размер диффа и границы изменения как отдельную инженерную цель. Без явных ограничений попросили фичу — получили фичу целиком, с рефакторингом соседнего модуля «заодно».

Пропускная способность человеческого ревью кода (code review) масштабируется гораздо хуже, чем скорость генерации.

В старом исследовании SmartBear на командах Cisco приводится ориентир: не больше 200–400 строк за одно ревью, скорость до 500 строк в час, сессии около часа. В таких условиях ревью находило 70–90% дефектов. Это не закон природы, но порядок величин показательный.

На одном из проектов у меня была ровно такая ситуация. Задача звучала скромно: добавить поле в ответ сервиса. Агент добавил поле, а заодно переписал маппинг, обновил пару зависимостей и «причесал» тесты.

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

В таких условиях approve может превращаться из результата проверки в способ убрать зависшее изменение из очереди.

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

И размер — только один фактор стоимости ревью. MR на 600 строк из DTO, маппера и юнит‑тестов может быть проще и безопаснее, чем MR на 120 строк, который трогает авторизацию платежа, границы транзакций или миграцию базы. Число затронутых модулей, изменение публичных контрактов и радиус поражения при ошибке весят не меньше, чем количество строк. Поэтому число строк — индикатор стоимости ревью, а не мера риска.

Наблюдение 2. Долгое ожидание ревью создаёт очередь, а не «медленный ревьюер»

Когда MR висят по три дня, первая реакция руководителя — «ревьюеры работают слишком медленно». Но проблема часто оказывается системной: входящий поток изменений просто превышает доступную пропускную способность ревью.

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

Там же ограничение: первый ответ на запрос ревью — максимум за один рабочий день. Речь именно о первом ответе, а не о завершении всего ревью. И перечислены последствия медленного ревью: падает скорость всей команды, разработчики начинают протестовать против процесса, а под давлением сроков в код пропускают изменения хуже, чем могли бы быть.

С агентами добавился новый эффект. Пока MR ждёт ревью, автор не скучает: он открывает следующий, потом ещё один.

Это видно и в данных: у Faros в 2025 году разработчики с высоким использованием AI касались на 47% большего числа PR в день. Незавершённой работы становится больше, переключений тоже.

Помню, как однажды наблюдал доску, где у одного разработчика было открыто семь MR, и ни один не был влит больше недели. Каждый по отдельности был «почти готов».

Как‑то раз в команде мы попробовали ограничение: не больше двух своих открытых MR на человека. Первую неделю правило раздражало, потому что «я же уже всё написал». Потом люди начали сами приходить к ревьюерам с вопросом, чем помочь, и очередь стала таять быстрее, чем росла.

Лимит на человека — хорошая стартовая эвристика, но управлять в итоге нужно глубиной общей очереди ревью: шесть авторов по два MR могут дать очередь хуже, чем три автора по одному.

Наблюдение 3. Ревью становится штампом или допросом

Под давлением объёма ревью скатывается в одну из двух крайностей.

• Первая — штамп: approve без чтения, «агент же написал, тесты зелёные».

• Вторая — допрос: ревьюер не доверяет сгенерированному коду и требует объяснить каждую строку, MR ходит по кругу неделю.

Быстрый рост числа PR, влитых без ревью, в данных Faros показывает: при растущем потоке команды сознательно или нет начинают сокращать охват ревью.

Помню, как однажды на проекте переносили клиент внешнего API на другую HTTP‑библиотеку.

Классический рефакторинг «без изменения поведения»: тестов написали много, ревью прошло, всё зелёное.

Позже выяснилось, что поменялось как раз поведение — что уходит во внешнюю систему и что происходит при её отказе. Тесты проверяли только разбор ответа, потому что его проще всего замокать, а ревьюер доверился зелёной сборке.

Вывод я тогда сделал такой: для рефакторинга, где поведение должно сохраниться, сначала тестами фиксируются существенные внешние эффекты и поведение при отказах, которые действительно являются контрактом. И только потом меняется реализация.

Обе крайности пропускают ошибки.

1. Штамп — потому что человеческой проверки по сути не было.

2. Допрос — потому что внимание тратится на стиль и мелочи, а не на вопрос, решает ли изменение нужную задачу.

Мне ближе всего такое разделение: проверка формата, известных уязвимостей и типовых шаблонов — работа автоматики, а человек нужен для вопроса «то ли мы вообще делаем».

Наблюдение 4. AI добавляет пропускной способности проверке, но не заменяет ответственность

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

Доверие к результатам AI при этом пока невысокое: в отчёте DORA 2025 года высокое доверие выразили 24% опрошенных, а 30% доверяют мало или не доверяют вовсе. И это разумная осторожность.

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

Мой вариант — уровни проверки по риску изменения. Это пример политики, а не отраслевой стандарт:

Детерминированные проверки, тесты, статанализ и AI‑ревью идут первыми и в CI. Человек получает MR уже без мусора и тратит внимание пропорционально риску.

Как управлять потоком изменений

Если собрать открытые практики, на которые ссылаются DORA, Google и разборы этого парадокса, получатся четыре слоя управления потоком. Они показаны на Рис. 3.

Главная мысль схемы: слои работают только вместе. Маленькие MR без быстрого первого ответа превращаются в длинную очередь маленьких MR. Быстрый ответ без автопроверок превращает ревьюера в линтер. А без метрик потока команда не узнает, куда очередь переехала на этот раз.

Про метрики отдельно. Число PR и число задач в эпоху агентов растут сами по себе и ничего не говорят о поставке. Чтобы найти узкое место, нужны метрики, которые его локализуют:

• время до первого ответа на MR;

• длительность самого ревью и число его кругов;

• время от открытия MR до merge;

• время от merge до production, включая QA;

• глубина очереди ревью и доля MR, влитых без ревью;

• доля неудачных изменений (change failure rate): изменения, которые привели к откату, хотфиксу или сбою в production по принятому в команде определению. Не путать с упавшими сборками CI.

Самое простое правило можно реализовать одним небольшим заданием CI. Например, предупреждение о дорогом для ревью MR в GitLab CI:

# (YAML, GitLab CI) Неблокирующее предупреждение о крупном MR
mr-change-size-warning:
  stage: .pre
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: true          # предупреждение, а не запрет на merge
  variables:
    GIT_DEPTH: "0"             # базового коммита MR может не быть в неполном клоне
  script:
    - |
      stats="$(git diff --numstat "$CI_MERGE_REQUEST_DIFF_BASE_SHA...$CI_COMMIT_SHA" \
        -- . ':(exclude)*.lock' ':(exclude)**/generated/**' |
        awk '$1 ~ /^[0-9]+$/ && $2 ~ /^[0-9]+$/ { a += $1; d += $2 } END { print a+0, d+0 }')"
      added="${stats% *}"; deleted="${stats#* }"; changed=$((added + deleted))
      echo "Изменено строк: $changed (+$added / -$deleted)"
      if [ "$changed" -gt 400 ]; then
        echo "MR крупнее 400 строк: стоит разбить на части, которые можно проверить по отдельности"
        exit 1
      fi

Задание намеренно завершается с ошибкой при превышении порога, а allow_failure: true превращает это в неблокирующее предупреждение.

Считаются добавленные плюс удалённые строки, бинарные файлы пропускаются. Сгенерированный код и lock‑файлы исключены, и список исключений у каждого репозитория будет свой.

Сравнение идёт от базового коммита диффа MR (CI_MERGE_REQUEST_DIFF_BASE_SHA), а не от текущего состояния целевой ветки, которая могла уйти вперёд.

Одна ирония, о которой стоит помнить: GIT_DEPTH: "0" скачивает всю историю. В небольшом репозитории это незаметно, а в крупном монорепозитории полный клон ради проверки размера сам становится лишней нагрузкой на CI. Там лучше брать статистику диффа через API платформы.

Где этот вывод не универсален

Я бы предпочёл сразу назвать ограничения.

• Во‑первых, источники. Faros и CircleCI продают инструменты для аналитики и ускорения поставки, и им выгодно, чтобы проблема выглядела острой. DORA опирается на опросы. Направление у всех трёх одно, поэтому его я считаю надёжным, а точные проценты — ориентиром.

• Во‑вторых, это корреляции, а не причины. Возможно, AI активнее используют команды, у которых и так больше работы и длиннее очереди.

• В‑третьих, активность в main у CircleCI — это прогоны CI, а не выкладки в production. Хороший косвенный показатель, но не прямое измерение поставки.

• В‑четвёртых, порог в 400 строк — сигнал о стоимости ревью, а не закон. Миграция, переименование или обновление зависимостей могут быть огромными и при этом простыми для проверки.

• И последнее: в маленькой команде, где все сидят рядом и ревью идёт голосом, очереди может не быть вовсе. Парадокс сильнее всего бьёт по командам, где проверяющих меньше, чем пишущих.

Что можно проверить у себя

Если в команде уже работают AI‑агенты, вот пять вопросов, которые я бы задал на ближайшей ретроспективе:

• Какой средний размер MR сейчас и каким он был полгода назад?

• Сколько MR ждёт первого ответа и сколько кругов проходит ревью?

• Где дольше всего лежит задача после merge: в QA, на интеграции или на выкладке?

• Что в проверке делает автоматика, а что человек, и соответствует ли глубина ревью риску изменения?

• Какая доля MR вливается без ревью, и знает ли об этом команда?

Если ответа на второй и третий вопросы нет, начать я бы советовал с них: это измеряется за вечер по истории репозитория и трекера.

Агенты сделали генерацию изменений дешёвой и быстрой.

Дорогим остался другой процесс: доказать, что изменение корректно, безопасно и готово к поставке. Узкое место никуда не исчезло, оно переехало туда, где пропускная способность меньше входящего потока.

Поэтому следующий шаг после внедрения агентов — не обязательно купить ещё одного. Сначала стоит измерить, куда уже переехала очередь.

А где у вас сейчас стоит очередь: в ревью, CI, QA или на интеграции? И что на самом деле помогло её разгрузить? Буду рад обсудить в комментариях.

AI‑агенты помогают писать код быстрее, но что делать, если изменения застревают на ревью, в CI или QA? Чтобы ускорить поставку без потери качества, важно понимать, какие проверки можно автоматизировать и как управлять растущим потоком изменений.

Разобраться в этом помогут бесплатные открытые уроки:

• 19 октября, 20:00. «ИИ‑агенты в реальной разработке: что умеют делать вместо вас». Записаться

• 9 ноября, 20:00. «Качество без микроменеджмента: что должен контролировать CTO». Записаться

• 16 ноября, 20:00. «GitlabCI + ArgoCD — сборка и доставка приложений, не покидая кластер». Записаться

Больше тем — в октябрьском дайджесте вебинаров OTUS.