Как измерить пользу ИИ-кодинга в команде: какие метрики работают, а какие врут
Компания раскатала ИИ-ассистент на всю разработку. Вопрос от руководства закономерный: он окупается? Ответить «команда довольна» недостаточно, а первая же попытка посчитать упирается в то, что очевидные метрики врут. Разберём, что мерить и как не оптимизировать не то.
Почему «строк кода в день» — вредная метрика
Соблазн велик: ИИ пишет код, посчитаем строки. Это худшее, что можно сделать, и вот почему.
ИИ-ассистент легко генерирует много кода. Но больше кода — это не польза, а чаще вред: его нужно читать, ревьюить, поддерживать и отлаживать. Метрика «строк в день» вознаграждает многословие и наказывает за краткое элегантное решение. Начнёте её оптимизировать — получите раздутую кодовую базу и довольный дашборд.
То же с «числом принятых автодополнений» и «числом запросов к ИИ». Это метрики активности, а не пользы. Активность легко накрутить, ничего не улучшив.
Что мерить на самом деле
Польза ИИ-кодинга видна не в объёме, а в результате поставки. Работают четыре группы метрик — те же, что для здоровья разработки вообще (их называют DORA-метриками):
| Метрика | Что показывает |
|---|---|
| Время от идеи до продакшена | Стало ли быстрее доводить задачу до релиза |
| Частота релизов | Чаще ли команда выкатывает изменения |
| Доля неудачных изменений | Не выросло ли число багов и откатов |
| Время восстановления после сбоя | Быстрее ли чинят, если что-то сломалось |
Ключевая идея: ИИ-кодинг полезен, если ускоряет поставку, не роняя качество. Если релизы участились, а доля багов не выросла — вот это польза. Если код пишется быстрее, но багов стало больше — это не ускорение, а перекладывание работы на потом.
Пара про скорость и качество
Мерить надо всегда парой. Скорость без качества — ловушка.
- Быстрее + качество не упало = настоящая польза. Расширяйте доступ.
- Быстрее + больше багов = мнимая польза. Вы просто перенесли работу с написания на отладку.
- Не быстрее + качество то же = ИИ не помогает на этих задачах. Нормально, бывает.
- Медленнее = что-то не так с внедрением. Разбирайтесь, где трение.
Одна метрика скорости без метрики качества всегда покажет улучшение — потому что писать быстро и плохо легко. Расход и активность полезно видеть отдельно, но они не говорят, стал ли продукт надёжнее или команда освободила время для важной работы.
Где ИИ-кодинг реально помогает, а где нет
Польза неравномерна, и это нужно измерять по типам задач, а не в среднем по команде.
Помогает сильно: шаблонный код, тесты, миграции, работа с незнакомым API, объяснение чужого кода, рутинный рефакторинг. Здесь ускорение реальное и заметное.
Помогает слабо или мешает: сложная бизнес-логика, архитектурные решения, задачи, где важен контекст всей системы. Здесь ИИ уверенно предлагает правдоподобное, но неверное, и проверка съедает выигрыш.
Если мерить в среднем, эти две картины смешаются в невнятное «вроде помогает». Разбивка по типам задач показывает, где расширять применение, а где не стоит.
Практические ловушки
Эффект новизны. Первые недели все воодушевлены и активны — метрики взлетают. Через месяц эйфория спадает. Мерьте на дистанции в несколько месяцев, а не по первым восторгам.
Смещение отбора. ИИ раньше начинают использовать сильные разработчики. Их высокая продуктивность — не заслуга ИИ, а их собственная. Сравнивайте команду с собой до и после, а не разработчиков между собой.
Забыли про расход. Ускорение может обойтись дороже, чем стоит. Считайте не только выигрыш во времени, но и стоимость инструментов, ревью, исправлений и обучения команды.
Оптимизация метрики вместо цели. Как только метрика становится целью, её начинают накручивать. Держите несколько метрик в связке, чтобы накрутить одну можно было только ценой других.
С чего начать
- Зафиксируйте базу до внедрения. Без «как было» не с чем сравнивать. Если уже внедрили — берите исторические данные о поставке.
- Мерьте поставку, а не активность. Время до продакшена и частота релизов важнее числа запросов к ИИ.
- Всегда парой скорость + качество. Одна скорость соврёт.
- Разбивайте по типам задач. Среднее по команде скрывает, где польза, а где нет.
- Считайте расход. Окупаемость — это выигрыш минус стоимость токенов.
- Смотрите на дистанции. Первый месяц искажён новизной.
Как принять решение после пилота
Заранее зафиксируйте срок эксперимента и условия решения. Расширять применение имеет смысл, если ключевые задачи доходят до релиза быстрее, а дефекты, откаты и нагрузка на ревью не растут. Если ускорение есть только на рутинных задачах, оставьте ИИ именно там — это нормальный, полезный результат. Если команда тратит больше времени на проверку и исправления, пилот нужно остановить или сузить: сначала разобрать типовые ошибки, улучшить тесты и правила работы, а не требовать от разработчиков «использовать больше».
Карточка измерения после пилота
Чтобы вывод не зависел от впечатлений, соберите одну короткую карточку на каждый тип задач. В первой строке укажите период и размер выборки: например, «12 рабочих дней, 38 задач, два разработчика». Ниже запишите медианное время от взятия задачи до первого готового ревью, долю изменений, которые пришлось откатить, и число замечаний, появившихся уже после слияния. Медиана здесь полезнее среднего: одна аварийная задача не должна перечеркнуть обычный рабочий день.
Отдельно отметьте, где именно участвовал ассистент: написал тест, объяснил незнакомый модуль, предложил черновик миграции или только подсказал синтаксис. Для каждой строки добавьте ручное поле «что пришлось исправить». Через две недели станет видно, какие подсказки экономят время, а какие лишь переносят его в ревью. Если карточка показывает ускорение только на генерации черновика, не приписывайте весь эффект модели: часть выигрыша может давать новая документация или более чёткая постановка задачи.
Финальное решение принимайте по повторяемому сценарию. Возьмите две-три задачи из следующего спринта, заранее определите допустимый уровень дефектов и сравните их с такой же выборкой без ассистента. Так команда проверит не рекламное обещание, а собственный процесс — с его языком, тестами, ограничениями доступа и стоимостью исправлений.
Что запомнить
- «Строк кода» и «число запросов» — метрики активности, они врут.
- Мерьте поставку: время до продакшена, частоту релизов, долю багов, время восстановления.
- Всегда парой скорость + качество — одна скорость всегда покажет улучшение.
- Разбивайте по типам задач: ИИ помогает на рутине и мешает на сложной логике.
- Учитывайте расход и дистанцию — окупаемость и без эффекта новизны.
Свежий пример готового инструмента для этого — Coding Agent Insights в CloudWatch. Какую модель выбрать под кодинг — подборщик моделей и сравнение моделей.