Почему AI-агенты ускоряют написание кода, но тормозят релизы в продакшн

В разработке стало больше коммитов и pull request’ов, а выпусков — существенно меньше. Для команд это плохой сигнал: bottleneck не исчез, а переехал на этап проверки.

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

Коммиты растут. Релизы — не очень

В материале Spiceworks приводятся данные исследования NBER, которое анализировало использование AI более чем 100 тысячами разработчиков GitHub. По мере развития инструментов росла и coding activity:

• автодополнение связывали с ростом числа коммитов на 40%;
• интерактивные coding agents — со 140%;
• автономные агенты — со 180%.

На этом месте обычно открывают дашборд, видят вертикальную линию commit rate и объявляют победу над legacy. Но дальше начинается прод, где графики перестают быть такими красивыми.

Рост coding activity на 180% дал только 50% роста числа проектов и 30% роста фактических релизов. То есть машина научилась быстрее производить изменения, но система доставки не научилась быстрее решать, какие из них безопасны, полезны и вообще нужны.

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

Бутылочное горлышко теперь сидит на review

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

Важная деталь — потеря контекста. Когда разработчик пишет код сам, часть решений остаётся у него в голове: почему выбран именно этот подход, какие edge cases учитывались, какие варианты сознательно отброшены. Агент выдаёт результат быстрее, но не обязан сохранять историю инженерного мышления в форме, пригодной для следующего ревьюера.

Анудж Дагар, основатель и CEO Luminary Software, описывает это просто: написание кода ускорилось, а узким местом стало его понимание. Формулировка неприятная, но точная. Мы получили конвейер, где upstream уже автоматизирован, а downstream всё ещё работает в режиме «дайте почитать diff после обеда».

Для backend-команд это означает рост скрытой нагрузки:

• больше изменений приходится разбирать;
• тестирование не успевает за генерацией;
• интеграция превращается в ручной арбитраж;
• pull request становится не признаком прогресса, а ещё одним элементом очереди.

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

Что проверять в своём пайплайне

После такой новости не нужно срочно выкидывать AI-агентов и возвращаться к ручному набору скобок. Нужно перестать считать скорость генерации скоростью доставки.

Минимальный набор проверок для команды:

1. Сравнить рост коммитов и pull request’ов с ростом фактических релизов.

2. Найти, где копится очередь: review, тесты, validation или интеграция.

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

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

5. Не считать syntactically correct code готовым результатом. Готовый результат — это изменение, которое прошло проверку и встроилось в продукт.

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

AI-агент ускоряет участок pipeline, который умеет генерировать текст. Прод требует другого: понимания, проверки и ответственности за интеграцию. Если этого слоя нет, вы не ускорили доставку. Вы просто быстрее наполняете очередь. Костыль с высоким throughput всё равно остаётся костылём.