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