AI-translated from English; not yet reviewed by a fluent editor.

# При ИИ-разработке надёжная поставка становится следующей инженерной задачей

> Когда ИИ увеличивает объём кода, инженерным руководителям важно понимать, где задерживаются изменения, сколько стоит проверка и ведёт ли выпущенное ПО себя так, как задумано.

By BIG CHANGE Editorial

Published: 2026-09-22T05:31:05.772Z
Updated: 2026-09-22T05:31:05.772Z
Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery

![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery.

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

Linear — полезный пример. В отчёте по инженерной работе от 21 сентября Муфиз Амджад сообщает, что с начала 2026 года число тестовых наборов в компании выросло почти вчетверо, а время ожидания непрерывной интеграции в запросах на изменение сократилось с более чем шести минут до чуть более пяти. Время выполнения каждого теста на вычислительных ресурсах примерно уменьшилось вдвое. Это разные улучшения; последняя цифра не означает, что общий счёт за CI сократился вдвое. Linear связывает растущую нагрузку на проверку с разработкой при помощи агентов, но её рассказ — не контролируемый эксперимент, измеряющий влияние ИИ на производительность. [Инженерный отчёт Linear](https://linear.app/now/ci-bottleneck-reworked).

Непрерывная интеграция (CI) запускает автоматические проверки предлагаемых изменений в программном обеспечении. Она находится между правдоподобным исправлением и изменением, которое команда готова принять. Когда ИИ увеличивает поток исправлений, пропускная способность проверок становится деловым вопросом: сколько полезной работы организация способна безопасно принять?

На наш взгляд, руководителям стоит одновременно показывать три результата: время до надёжной обратной связи, общий объём вычислений и надёжность выпущенных изменений. Быстрый ответ ценен лишь в том случае, если команда понимает, что он подтверждает.

## Меньшее ожидание может означать больше работы

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

Теперь добавим каждой машине по минуте на подготовку. Вариант с четырьмя машинами завершится за четыре минуты и израсходует 16 машин-минут. На одной машине он займёт 13 минут и израсходует 13 машин-минут. Время ожидания резко сокращается, а суммарное потребление ресурсов растёт. Фактическая стоимость также зависит от типов машин, цен и правил тарификации.

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

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

Но и каждая минута ожидания не равна затратам труда. Разработчик, приступивший к другой полезной задаче во время проверок, не обязательно теряет весь этот интервал. При этом частые прерывания и возвращение к незавершённой работе могут мешать. Чтобы измерить такие последствия, нужно наблюдать за рабочим процессом команды, а не умножать прошедшие минуты на зарплату.

## Исследования показывают неоднозначную картину

Анализ DORA от марта 2026 года обобщает два разных массива данных. В исследовании 2025 года широкое внедрение ИИ связывалось и с ростом пропускной способности поставки ПО, и с большей нестабильностью. Отдельно исследователи проанализировали 1110 развёрнутых ответов инженеров Google, собранных в третьем квартале 2025 года. Инженеры отмечали помощь в написании черновиков и других задачах, а также дополнительные затраты на проверку. Внутреннее качественное исследование не представляет участников более широкого анализа DORA, а ни один из этих источников не доказывает, что ИИ вызвал проблемы с релизами конкретной команды. [Анализ DORA и методология](https://dora.dev/insights/balancing-ai-tensions/).

Есть также более убедительные экспериментальные данные, но с более узкой областью применимости. В рандомизированном исследовании METR от июля 2025 года 246 задач распределили между 16 опытными разработчиками открытого ПО, работавшими со знакомыми репозиториями. При разрешённом использовании ИИ-инструментов начала 2025 года выполнение задач заняло на 19% больше времени. При этом участники считали, что ИИ ускорил их работу. Этот вывод касается этих разработчиков, задач и инструментов и не определяет ценность всех современных ИИ-агентов для программирования. [Первоначальный эксперимент METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

В феврале 2026 года METR сообщила, что повторное исследование дало ненадёжную оценку текущего влияния ИИ на производительность. Разработчики всё чаще отказывались от задач без ИИ или сами выбирали, какие задачи передать; одновременная работа нескольких агентов также затруднила измерение времени. Исследователи считали более сильное ускорение правдоподобным, но отметили, что данные лишь слабо подтверждают его размер. Повторять старую цифру о замедлении без этого уточнения было бы вводящим в заблуждение. [Повторное исследование METR](https://metr.org/blog/2026-02-24-uplift-update/).

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

## Для каждого узкого места — своё решение

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

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

Кэширование зависимостей показывает, почему даже привычную оптимизацию нужно измерять. GitHub описывает кэширование как повторное использование файлов, повторное создание которых на чистых исполнителях требует больших ресурсов. Также компания указывает, что задания должны уметь пересоздавать или скачивать файлы при отсутствии кэша. Поэтому его поведение нужно оценивать и при попаданиях, и при промахах. [Документация GitHub по кэшированию зависимостей](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

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

Быстрая и надёжная обратная связь раньше даёт и людям, и агентам возможность исправлять ошибки. Улучшение общей инфраструктуры может принести пользу разным видам разработки, в том числе без ИИ. Поэтому руководителю есть основания финансировать её независимо от смены инструментов для программирования.

![One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.](/api/media/file/elapsed-aggregate-work-inline-v1.png)

## Быстрые тесты всё равно должны выявлять ошибки

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

Vitest, инструмент тестирования JavaScript и TypeScript, по умолчанию изолирует тестовые файлы, чтобы состояние одного файла не влияло на другое. В документации описана возможность выборочно отключить изоляцию для подходящих тестов; вместе с тем изменяемое состояние модулей, изменённые глобальные объекты и другие зависимости названы причинами сохранить её. Поэтому настройка, сокращающая время подготовки, может изменить границы проверки корректности. [Руководство Vitest по изоляции](https://vitest.dev/guide/recipes/disable-isolation).

Linear выбрала подход с совместным состоянием, которое нужно включать явно, добавила очистку и сохранила изоляцию для файлов, которые нельзя было безопасно перенести. Выигрыш в производительности зависел от решения, какие тесты могут безопасно разделять среду. [Реализация Linear](https://linear.app/now/ci-bottleneck-reworked).

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

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

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

## Измеряйте изменения, которые доходят до клиентов

Метрики поставки DORA полезны для проверки результата на следующем этапе. Среди них — время от фиксации кода до рабочей среды, частота развёртываний, восстановление после неудачного развёртывания, доля развёртываний с необходимым немедленным вмешательством и доля незапланированных переделок из-за инцидентов. Они описывают результаты поставки за пределами успешного запуска тестов. [Определения метрик DORA](https://dora.dev/guides/dora-metrics/).

Команде, изучающей рабочий процесс с ИИ-разработкой, мы предложили бы дополнить эти показатели небольшим диагностическим журналом:

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

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

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

## Sources

- [Linear: ИИ-разработка и узкое место в CI](https://linear.app/now/ci-bottleneck-reworked) — 21 сентября 2026 года. В отчёте об использовании инструментов, написанном Муфизом Амджадом, приведены начальные цифры и пример выборочного отключения изоляции. Данные относятся к системе Linear, а не к контролируемой оценке производительности при ИИ или общих расходов.
- [DORA: балансирование последствий ИИ](https://dora.dev/insights/balancing-ai-tensions/) — 10 марта 2026 года. Разделяет выявленную в 2025 году связь и качественный анализ ответов инженеров Google. Во внутреннем исследовании приводятся описания опыта, а не измерения причинно-следственных эффектов; формулировка ранних вопросов могла повлиять на ответы.
- [METR: ИИ начала 2025 года и производительность опытных разработчиков](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 10 июля 2025 года. Рандомизированный эксперимент со знакомыми репозиториями открытого ПО и инструментами начала 2025 года. Подтверждает ограниченный результат о замедлении и расхождение с оценками участников. Это не оценка всех разработчиков или моделей сентября 2026 года.
- [METR: изменение эксперимента по производительности разработчиков](https://metr.org/blog/2026-02-24-uplift-update/) — Обновление от 24 февраля 2026 года. Объясняет выбор участников и задач, изменение оплаты и трудности измерения параллельной работы. Исследователи считают новую оценку ненадёжной; мы не представляем её исходные цифры как актуальный показатель ускорения.
- [GitHub: кэширование зависимостей](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — Актуальная документация, изучена 22 сентября 2026 года. Описывает повторное использование файлов на чистых исполнителях и необходимость работы заданий без кэша. Она не определяет производительность или стоимость конкретного репозитория.
- [Vitest: настройки изоляции файлов](https://vitest.dev/guide/recipes/disable-isolation) — Актуальная документация, изучена 22 сентября 2026 года. Объясняет изоляцию по умолчанию, выборочную настройку и зависимости от общего состояния, требующие защиты. Это техническое руководство показывает компромисс; BIG CHANGE не проводило замеров и не меняло набор тестов.
- [DORA: метрики производительности поставки ПО](https://dora.dev/guides/dora-metrics/) — Обновлено 5 января 2026 года. Определяет пять метрик поставки и их применение на уровне сервиса. Они позволяют оценивать результаты за пределами длительности CI; примеры диагностики в статье — анализ, а не результаты нового эксперимента.