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

Купили Copilot, раздали команде, через квартал смотрите на цифры — и не понимаете, это AI помог или команда сама выросла. Знакомо?

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

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

Привет, Хабр! Мы внедрили 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-кривая лучше прямой линии

Недели 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%»  —  это число, которое бизнес воспринимает как маркетинг. Считали в часах:

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

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

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

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

Разрыв между 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 растет, реальный прогресс  —  не обязательно.

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

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

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

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

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

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

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