+240% коммитов, +30% релизов: агенты упёрлись в SDLC

В сентябре NBER опубликовал работу о влиянии AI-инструментов на разработку. Авторы сопоставили публичную активность более 500 тысяч разработчиков на GitHub с телеметрией этих инструментов. У пользователей автономных агентов оценённый накопительный эффект на число коммитов достиг 240%. На уровне проектов он составил 80%, на уровне релизов — 30%.

Разрыв важнее самой большой цифры. Агент может быстро написать код, но изменение ещё нужно проверить, встроить в систему и выпустить. По мере распространения агентов программирования, узким местом становится весь цикл разработки и поставки ПО (SDLC).

240% внизу цепочки, 30% наверху

Работа NBER охватывает несколько поколений AI-инструментов. По мере перехода от автодополнения к интерактивным и автономным агентам оценённый эффект на число коммитов рос. Выше по производственной цепочке прирост быстро сдувался.

Оценённое изменение активности после внедрения разных поколений AI-инструментов: эффект резко уменьшается по мере движения от написанных строк к релизам. Результаты показаны накопительно — от autocomplete к синхронным и затем автономным агентам. Для автономных агентов отдельной оценки числа релизов нет, поскольку релизы измерялись на уровне репозитория. Источник: Mert Demirer, Leon Musolff и Liyuan Yang, «Writing Code vs. Shipping Code», NBER Working Paper 35275, редакция сентября 2026 года.

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

Затухание авторы объясняют гипотезой слабого звена. Скорость всей цепочки ограничивает этап, который хуже остальных поддаётся ускорению. В их модели коэффициент замещения AI человеческим трудом равен 0,23. Низкое значение означает, что работа человека и инструмента сильно зависят друг от друга. Агент пишет код быстрее, а решения до и после реализации остаются у людей.

У исследования хватает ограничений. Для начала оно наблюдательное. Пользователей AI сопоставляли с разработчиками, похожими по прошлой активности, в той же календарной неделе годом ранее. Часть телеметрии закрыта, а публичный GitHub плохо представляет внутреннюю разработку компаний. Двое авторов раньше работали в Microsoft и сейчас консультируют компанию.

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

Очередь уже видна в ревью

LinkedIn столкнулся с похожим эффектом у себя. Вместе с объёмом кода от агентов росло время до первого человеческого ревью у самых медленных десяти процентов запросов. Компания построила собственную систему проверки кода. За обычную неделю она проводит больше 79 тысяч ревью примерно для 40 тысяч запросов на слияние кода в 7,5 тысячи репозиториев.

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

Production-инфраструктура AI Code Review в LinkedIn: события из GitHub проходят через устойчивую очередь и Kubernetes worker pool, где параллельно работают multi-agent reviews. За обычную неделю система проводит больше 79 тысяч ревью примерно для 40 тысяч запросов на слияние кода в 7,5 тысячи репозиториев. Источник: LinkedIn Engineering, Figure 3.

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

Работа переехала из написания в проверку

Лонгитюдное исследование разработчиков помогает понять, чем теперь занят человек. Авторы провели два опроса с интервалом в шесть месяцев. В первой волне осталось 158 подходящих участников, во второй — 101, а сопоставимую выборку составили 95 человек.

82% опрошенных пользователей AI сообщили, что тратят меньше времени на написание кода. Статистически значимым оказался общий сдвиг от создания к проверке. Рост каждого отдельного вида проверочной работы подтвердить не удалось. Авторы назвали новый набор занятий supervisory engineering. Человек направляет агента, оценивает результат и исправляет ошибки.

Опрос измеряет восприятие участников, а данные собирали в 2024 и 2025 годах. Инструменты с тех пор успели измениться. Но результат согласуется с главным ограничением из работы NBER. Генерация кода ускоряется сильнее, чем человеческая проверка.

Ту же картину показала DORA в исследовании 2025 года на ответах почти пяти тысяч специалистов. Рост использования AI на 25% был связан с ускорением ревью кода на 3,1%. При этом пропускная способность поставки снизилась на 1,5%, а стабильность — на 7,2%.

DORA тоже использовала опрос и статистическую модель, поэтому причинность здесь не доказана. Авторы предполагают, что AI увеличивает размер изменений. Код появляется быстрее, партии растут, крупные изменения дольше проверяются и чаще ломаются. Старый совет выпускать маленькими порциями от этого стал полезнее.

Есть и неудобный контрпример. В рандомизированном эксперименте METR 16 опытных разработчиков открытых проектов выполнили 246 реальных задач. С AI-инструментами начала 2025 года они работали на 19% медленнее, хотя сами считали, что ускорились. Более поздний эксперимент METR дал слабый сигнал ускорения, но исследователи признали оценку ненадёжной из-за отбора участников и параллельной работы с агентами.

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

Агент становится частью производственной системы

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

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

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

Atlassian описывает тот же сдвиг со стороны управления процессом. В опросе более 1100 инженеров и руководителей разработки 94% руководителей сообщили, что их организации используют AI. 74% увидели ускорение генерации кода, но 78% команд продолжают проверять выросший поток обычным ревью коллег.

По тому же опросу, 88% руководителей считают нужной управляемую инженерную систему для AI. Построили её 19%. Ещё 6% сообщили о формальном и широком внедрении AI как стандарта во многих частях SDLC. У второй цифры критерий строже, поэтому напрямую сравнивать их нельзя.

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

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

Что должно находиться вокруг агента

Техническую обвязку агента часто сводят к файлу с инструкциями. Для личного инструмента этого бывает достаточно. Потоку автономных изменений нужна система из нескольких частей.

Описанная задача

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

Общий контекст

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

Граница исполнения

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

Проверки

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

История решений

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

Обратная связь после релиза

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

Метрики для нового узкого места

Скорость агента мало говорит о скорости поставки. Полезнее измерять потери между стадиями.

1. Агент принял задачу.

2. Создан запрос на слияние кода.

3. Автоматические проверки прошли.

4. Изменение принято после ревью.

5. Изменение попало в релиз.

6. Релиз обошёлся без отката и последующего исправления.

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

По мере движения от задачи к стабильной работе часть изменений отсеивается, а на переходах накапливаются ожидание и человеческая доработка.

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

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

Новые исследования и практические примеры такой инфраструктуры я складываю в свой телеграм-канал «Никита Ульшин про IT». Там же буду разбирать, как меняется работа инженеров и руководителей по мере взросления агентной разработки.