Метрики продуктивности AI-разработки и узкое место ревью✦
Заметки основаны на выпуске подкаста «Организованное программирование» (Кирилл Макевнин) — раздел про оценку продуктивности и внедрение AI в крупных компаниях (тайм-код 33:22–44:10). Это первичный источник: обобщение того, что автор услышал в кулуарах конференций от Сбера, Т-банка и платформенных команд.
Почему деньги — плохая метрика✦
На C-Level-обсуждениях команды часто предлагают мерить эффект AI деньгами: «мы что-то разработали → это повлияло на выручку». По опыту контрибьютора это неверно. У разработки нет прямой корреляции с деньгами: компания может заработать на оптимизации от финдиректора, на крупном контракте фаундера или на движении рынка — любой из этих факторов перевесит вклад любой фичи. К тому же релизы и продажи часто не совпадают по времени. У продавцов и маркетологов денежный KPI работает, у разработчиков — нет; посадить их на такой KPI — верный способ получить отток.
Что мерить вместо этого✦
Более правдоподобная метрика — число доведённых до продакшна историй (stories) и общий time-to-market всего пайплайна, а не объём кода одного разработчика. За экономику отвечают продакты и менеджмент выше; от технических команд ждут релизов с нужной скоростью. Идея прозвучала от Сбера (Кирилл Миньшов, вице-президент).
(Внешние источники по метрикам продуктивности — в русле DORA, SPACE, DevEx — сходятся в том, что индивидуальные output-метрики вроде «диффов на инженера» или «закрытых тикетов» легко геймятся и мало говорят о реальной эффективности; они рекомендуют дополнять пропускную способность метриками потока, качества и здоровья команды. Но операционным ориентиром у нас остаётся связка «истории в проде + time-to-market».)
Узкое место сместилось на ревью✦
Рост объёма кода в 10 раз не даёт роста эффективности в 10 раз. Ревью и раньше было узким горлышком — куча пул-реквестов, конечная скорость проверки. При 10x-кода нагрузка на ревью растёт ещё сильнее, а люди, которые непрерывно проверяют, выпадают из собственной работы. Кодинг был не самой большой проблемой; теперь бутылочное горлышко просто переместилось. Полуавтоматическое ревью ловит типовые ошибки, но соответствие правилам и поведение в корнер-кейсах всё равно надо проверять руками — особенно платформенным командам, где ошибка после деплоя стоит дорого.
Внешние данные это подтверждают: у команд, активно использующих AI, объём пул-реквестов вырос на 98%, а время ревью — на 91%; старший инженер тратит ~4.3 мин на ревью AI-подсказки против 1.2 мин на код человека, и лишь 26% готовы мёржить AI-код без ревью.
Токены: сигнал, но не KPI✦
Высокое потребление токенов конкретным человеком, как правило, говорит о неэффективном использовании AI. Но делать из него KPI — ошибка: на этапе обучения потребление намеренно поощряют, чтобы люди быстрее вкатывались и не боялись экспериментировать. Ограничения вводят позже и точечно — работая с теми, кто тратит больше всех. Ранние лимиты только навредят.