ИИ ускоряет код, но продуктивность не растёт: что объясняют метрики DevEx

Ожидание было простым: с ИИ-ассистентами разработчик выдаёт в три-четыре раза больше качественного кода. На практике кратного роста продуктивности в командах почти никто не видит. Одно из самых цитируемых исследований, рандомизированный эксперимент METR 2025 года, показало, что опытные разработчики open source с ИИ-инструментами решали задачи на 19% медленнее, хотя сами оценивали ускорение примерно в 20%. Хабр опубликовал перевод разбора, где автор предлагает добавить к DORA и SPACE метрики DevEx, чтобы увидеть то, что обычная статистика пропускает. Мы опираемся на анонс материала и общеизвестные описания этих фреймворков.

Почему код быстрее, а результат тот же

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

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

Три рамки измерения

Каждый фреймворк смотрит на свою часть системы:

• DORA: четыре показателя доставки: частота деплоев, время от коммита до продакшена, доля неудачных изменений и время восстановления после сбоя. Метрика показывает результат конвейера.
• SPACE: пять измерений: удовлетворённость, производительность, активность, коммуникация и сотрудничество, эффективность и поток. Рамка предупреждает, что одной цифрой продуктивность не описать.
• DevEx: три фактора опыта разработчика: скорость обратной связи, когнитивная нагрузка и возможность войти в состояние потока. Метрика показывает, что мешает работать.

Именно DevEx отвечает на вопрос, куда деваются сэкономленные минуты. Долгий CI, непонятная архитектура, разрозненная документация и очередь согласований съедают выигрыш от автодополнения, и DORA это зафиксирует только косвенно, через итоговое время поставки.

Как ИИ меняет сам замер

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

Что замерить на практике

Начинать стоит до массового внедрения ассистентов: без исходной точки эффект не отделить от сезонных колебаний и смены состава команды. Дальше разумно сопоставлять три слоя данных.

• Время ожидания: очередь на ревью, длительность CI, задержки согласований.
• Качество: доля неудачных изменений и время восстановления из DORA как контрвес скорости.
• Опыт разработчиков: регулярные короткие опросы о потоке, нагрузке и качестве обратной связи.

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