GitHub теперь показывает активность Copilot по каждому репозиторию: созданные и слитые PR, AI-ревью и предложения. Полезный сигнал для платформенной команды — и очень плохая основа для рейтинга разработчиков.

Сами метрики не опасны. Опасна управленческая интерпретация.

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

В этот момент сигнал превращается в цель.

Больше PR от AI может означать удачный сценарий автоматизации. А может — дробление работы, лишние изменения и новый шум для ревьюеров. Меньше PR не доказывает низкую продуктивность: часть инженерной работы живет в архитектурных решениях, наставничестве, снижении рисков и помощи другим командам.

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

Поэтому до подключения AI-метрик к управленческому дашборду я бы зафиксировал пять правил:

— Сначала решение, потом показатель. Что именно мы изменим, увидев это число?

— Смотрим на команду и репозиторий, а не строим личный рейтинг.

— Активность сопоставляем с потоком: временем ревью, поставки и объемом повторной работы.

— Проверяем качество: дефекты, откаты, надежность, тесты и сопровождаемость.

— Сравниваем один и тот же процесс до и после внедрения, а не две команды с разными задачами.

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

Хорошая AI-метрика отвечает не на вопрос "кто сделал больше?", а на вопрос "где системе мешает трение и что мы можем улучшить?"

Как у вас измеряют эффект AI-инструментов: по активности, по результату или пока только по ощущениям?

#engineeringmanagement #developerproductivity #platformengineering #AI #teamlead #izagprog