Практика измерения эффективности AI-инструментов в инженерных командах

AI-CMO4 часа назад

Практика измерения эффективности AI-инструментов в инженерных командах

Уровень сложностиСреднийВремя на прочтение6 минОхват и читатели3.2KТестирование IT-систем*Анализ и проектирование систем*КейсИз песочницыКупили Copilot, раздали команде, через квартал смотрите на цифры — и не понимаете, это AI помог или команда сама выросла. Знакомо?

Мы внедрили AI в разработку 35 инженеров и измерили, что реально изменилось. Не acceptance rate — он врет без baseline. Не DORA в лоб — она не видит разницу между мелкими деплоями и сложными задачами. А метрики, которые честно показывают эффект: откуда брать данные, как избежать игры с цифрами, и почему субъективное ощущение +20% от AI оказалось −19% объективно.

Практический гайд с реальными цифрами, таблицей контрметрик и чеклистом для внедрения.

Code of Leadership S2E1 — Авенир Воронов (Veai) обсуждает методы оценки эффективности AI

Привет, Хабр! Мы внедрили AI в разработку 35 инженеров и посмотрели, что реально изменилось.

TL;DR — что внутри:

• Почему acceptance rate врет без baseline — и как правильно его снять
• Какие метрики реально работают: PR cycle time, Code churn, Al-share — и что они показывают
• Почему DORA в лоб не подходит для измерения AI-эффекта — и что использовать вместо
• Таблица контрметрик: каждой цифре скорости — пара по качеству (готовый чеклист для внедрения)
• Почему субъективное ощущение +20% от AI оказалось − 19% объективно — и как этого избежатьСтатья для CTO, техлидов и инженерных менеджеров, которые отвечают за внедрение AI в команде. Если вы рядовой разработчик — скорее всего мерить нечего, этим занимается ваш менеджер.

Почему большинство AI-пилотов нельзя оценить  -  и причем тут baseline

Типичный сценарий: купили подписку, раздали команде, через квартал на встрече с бизнесом задают вопрос «ну и что изменилось?» - и никто не может ответить цифрами. Не потому что ничего не изменилось. А потому что никто не зафиксировал, как было до.

Когда мы заходим в команду, первое что делаем - фиксируем точку отсчета до старта и запускаем отслеживание метрик с первой недели внедрения:

• Доля AI-кода в коммитах  -  из git мы берем одно:сколько строк, сгенерированных AI, вошло в итоговый коммит. Это показывает, насколько AI-предложения реально принимаются, а не просто нажимаются Tab и отклоняются. Полную картину дают логи копилота: по ним видно, что разработчик реально делал  -  не только код, но и размышления, гипотезы, изучение легаси, разница между сгенерированным и принятым по итогу 
• Время на задачу  - измеряем через логи копилота. Берем диалог разработчика за сессию, загружаем в языковую модель и просим определить, какую задачу он выполнял, и оценить её в часах. Так получаем реальное время на задачу - без субъективных отчетов и без ручного трекинга
• DORA-четверка  -  Deployment Frequency, Lead Time, Change Failure Rate, MTTR
• Опрос команды- 3–5 вопросов, анонимно, eNPS разработчиков. Снимаем в процессе  -  каждую неделю пилота или внедренияБез этого через три месяца вы смотрите на данные и не понимаете: это AI дал прирост, команда выросла, или продукт стал проще? Проверить невозможно.

Кейс: 35 разработчиков, 4 команды, что получилось на практике

Команда: 18 backend, 13 frontend, 4 QA automation. Корпоративный стек, задачи разного уровня сложности.

Acceptance rate по неделям  -  и почему U-кривая лучше прямой линии

НеделяAcceptance rate, %1625364451617208209121091111Недели 5–6  -  минимум, почти ноль. Это пугает, если не понимать что происходит. Разработчики разобрались с базовым функционалом и перешли к более сложным сценариям, где первые попытки дают мало принятых изменений. Недели 7–8  -  скачок до 20%: команда нашла свои рабочие паттерны взаимодействия.

☝️Важно: ровная линия acceptance rate на 40% хуже, чем U-образная кривая с ростом. Первая означает, что команда зафиксировалась на одном режиме и не развивается. Динамика важнее абсолюта. Ровная линия, как правило, значит: разработчики освоили AI только для типовых операций  -  генерации документации, типовых CRUD  -  и не пробуют более сложные: рефакторинг, анализ легаси, проектирование с нуля. Это не плохой результат  -  но сигнал к тому, что потенциал инструмента используется не полностью.

И главное  -  acceptance rate нельзя делать личным KPI разработчика. Как только люди видят, что их оценивают по этой цифре, они начинают нажимать Tab на все подряд. Метрика растет, качество падает.

Распределение MR по сложности: где AI реально помогает

Распределение AI-запросов по типам задач: рефакторинг  -  28%, отладка  -  26%, генерация нового кода  -  19%, исправление ошибок  -  8%, код-ревью  -  5%, прочее  -  14%.

На простых задачах  -  документация, типовые CRUD, покрытие тестами  -  ускорение заметное и стабильное. На сложных архитектурных задачах AI работает как второй пилот, а не как автопилот.

Смотреть только на суммарный acceptance rate без разбивки по типам задач  -  это считать среднюю температуру по больнице. Вся аналитическая ценность исчезает.

Главный вопрос: сколько часов это реально сэкономило?

Не «рост производительности на X%»  -  это число, которое бизнес воспринимает как маркетинг. Считали в часах:

ФазаЭкономия на разработчика/месНа команду/месНачало внедрения13.5 часов86.5 часовЗрелая фаза27.7 часов177.3 часаМетод: контрфактуальный  -  сравнивали время на аналогичные по сложности задачи до и после внедрения. Время берем из логов копилота, не из git: git дает только долю AI-строк в коммите, но не показывает, сколько реального времени заняла задача. Не строки кода, не acceptance rate  -  время на задачу.

Часы переводятся в деньги. Деньги понятны CFO.

Масштаб: 35 инженеров, 27 700 саджестов  -  что видно на большой выборке

На Veai 5.2 в активной работе  -  50 инженеров, 27 700 саджестов за один месяц. Итоговый срез в зрелой фазе:

МетрикаЗначениеMR за 4 недели пилота (активные участники)35Баги после деплоя4Acceptance rate87% (средний показатель по индустрии - 25-35%; 87% - сильный результат)Довольны инструментом87% разработчиковИспользуют постоянно65% разработчиковРазрыв между 87% и 65%  -  это gap между «нравится» и «стало привычкой». Он всегда есть, и это нормально. Важно, что он сокращается со временем. Чтобы ускорить переход от "нравится" к "привычке" - добавьте AI в рутинные таски (не только в единичных задачах) и зафиксируйте gap еженедельно.

Почему DORA не дает полной картины - и что добавить

DORA живет. Deployment Frequency, Lead Time, Change Failure Rate, MTTR - по-прежнему рабочие метрики. Но в связке с AI у них появились слепые пятна.

Проблема 1: DORA не видит AI. Команда деплоит чаще, потому что AI генерирует больше кода - Deployment Frequency растет. Одновременно Change Failure Rate ухудшается, потому что AI-код тяжелее ревьюить. DORA видит оба числа, но не объясняет связь.

Проблема 2: DORA уязвима к оптимизации. Когда команда знает свои DORA-показатели, она начинает оптимизировать под них: делать чаще маленькие деплои, быстрее закрывать тикеты. Deployment Frequency растет, реальный прогресс  -  не обязательно.

МетрикаЗачемAI-share

доля AI-строк в коммитеДоля AI-строк в коммите (из логов копилота). Без нее неясно, чем объясняется рост DORA-показателей.Code churn rate

доля AI-кода, переписанного за 30 дней после мержаДоля AI-кода, переписанного в первые 30 дней после мержа. Высокий acceptance + высокий churn  -  приняли, но потом быстро переделали.Complexity-adjusted throughput

пропускная способность с учетом сложности задачИз четырех DORA-метрик (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) только первая связана с количеством деплоев. AI хорошо решает простые задачи и раздувает Deployment Frequency без реального прогресса. Предлагается считать суммарную сложность задач, залитых в прод, а не просто их количество.

Чтобы AI не раздувал Deployment Frequency за счет мелких типовых задач, а прогресс в сложных задачах был виден.

Пример: 3 задачи story points 1+1+1 = 3 vs 1 задача story points 5. Deployment Frequency одинаковая (3 деплоя), но Complexity-adjusted throughput разный: 3 vs 5. AI, который решает только мелкие задачи, не улучшает реальный throughput.

Контрметрики: каждой цифре скорости - пара по качеству

Исследование METR: 16 опытных разработчиков субъективно оценили ускорение от AI в +20%. Объективные измерения показали −19%. Накладные расходы на промпты, верификацию и ревью AI-кода съели весь эффект и еще немного сверху.

Это не аргумент против AI. Это аргумент против того, чтобы считать только скорость.

Метрика скоростиКонтрпараAcceptance rate% AI-кода, переписанного при ревьюСкорость написания кодаДефекты после мержаКоличество сгенерированных тестовMutation score, не просто coverage

Мера качества тестов: в код искусственно вносятся небольшие изменения-«мутации» (например, заменяют + на - или > на >=). Если тест не замечает мутацию - тест бесполезен. Mutation score = доля мутаций, которую тесты обнаружили. Coverage показывает, какой код выполнялся; Mutation score показывает, действительно ли тесты его проверяют. Deployment FrequencyChange Failure RatePR cycle timeКоличество ревью-раундов

Про модели: DeepSeek, Qwen - и почему это обязательная переменная в отчете

В версии 5.2 работали с Qwen и DeepSeek. Каждая новая модель  -  это другое качество саджестов: часть предложений, которые разработчик раньше отклонял, теперь принимает  -  или наоборот. Если не зафиксировать, какая модель работала в какой период  -  рост acceptance rate нельзя интерпретировать как улучшение процесса.

☝️Модель, версия инструмента, состав команды  -  все это контекстные переменные. Они всегда должны быть рядом с цифрами в отчете, иначе данных недостаточно для выводов.

Материал на основе выпуска подкастаCode of Leadership S2E1на канале«Книжный куб».Флагманский контент‑проект Telegram‑канала «Книжный куб», где технический директор Т‑Банка Александр Поломодовсобирает практики лидеров инженерных команд и AI‑native компаний.Теги:• llm-агент
• llm-модели
• ai
• c++Хабы:• Тестирование IT-систем
• Анализ и проектирование систем