Средний
6 мин
3.4K
Кейс
Купили Copilot, раздали команде, через квартал смотрите на цифры — и не понимаете, это AI помог или команда сама выросла. Знакомо?
Мы внедрили AI в разработку 35 инженеров и измерили, что реально изменилось. Не acceptance rate — он врет без baseline. Не DORA в лоб — она не видит разницу между мелкими деплоями и сложными задачами. А метрики, которые честно показывают эффект: откуда брать данные, как избежать игры с цифрами, и почему субъективное ощущение +20% от AI оказалось −19% объективно.
Практический гайд с реальными цифрами, таблицей контрметрик и чеклистом для внедрения.
Code of Leadership S2E1 — Авенир Воронов (Veai) обсуждает методы оценки эффективности AITL;DR — что внутри:
Почему acceptance rate врет без baseline — и как правильно его снять
Какие метрики реально работают: PR cycle time, Code churn, Al-share — и что они показывают
Почему DORA в лоб не подходит для измерения AI-эффекта — и что использовать вместо
Таблица контрметрик: каждой цифре скорости — пара по качеству (готовый чеклист для внедрения)
Почему субъективное ощущение +20% от AI оказалось − 19% объективно — и как этого избежать
Статья для CTO, техлидов и инженерных менеджеров, которые отвечают за внедрение AI в команде. Если вы рядовой разработчик — скорее всего мерить нечего, этим занимается ваш менеджер.
Типичный сценарий: купили подписку, раздали команде, через квартал на встрече с бизнесом задают вопрос «ну и что изменилось?» - и никто не может ответить цифрами. Не потому что ничего не изменилось. А потому что никто не зафиксировал, как было до.
Когда мы заходим в команду, первое что делаем - фиксируем точку отсчета до старта и запускаем отслеживание метрик с первой недели внедрения:
Доля AI-кода в коммитах - из git мы берем одно: сколько строк, сгенерированных AI, вошло в итоговый коммит. Это показывает, насколько AI-предложения реально принимаются, а не просто нажимаются Tab и отклоняются. Полную картину дают логи копилота: по ним видно, что разработчик реально делал - не только код, но и размышления, гипотезы, изучение легаси, разница между сгенерированным и принятым по итогу
Время на задачу - измеряем через логи копилота. Берем диалог разработчика за сессию, загружаем в языковую модель и просим определить, какую задачу он выполнял, и оценить её в часах. Так получаем реальное время на задачу - без субъективных отчетов и без ручного трекинга
DORA-четверка - Deployment Frequency, Lead Time, Change Failure Rate, MTTR
Опрос команды - 3–5 вопросов, анонимно, eNPS разработчиков. Снимаем в процессе - каждую неделю пилота или внедрения
Без этого через три месяца вы смотрите на данные и не понимаете: это AI дал прирост, команда выросла, или продукт стал проще? Проверить невозможно.
Команда: 18 backend, 13 frontend, 4 QA automation. Корпоративный стек, задачи разного уровня сложности.
Недели 5–6 - минимум, почти ноль. Это пугает, если не понимать что происходит. Разработчики разобрались с базовым функционалом и перешли к более сложным сценариям, где первые попытки дают мало принятых изменений. Недели 7–8 - скачок до 20%: команда нашла свои рабочие паттерны взаимодействия.
☝️Важно: ровная линия acceptance rate на 40% хуже, чем U-образная кривая с ростом. Первая означает, что команда зафиксировалась на одном режиме и не развивается. Динамика важнее абсолюта. Ровная линия, как правило, значит: разработчики освоили AI только для типовых операций - генерации документации, типовых CRUD - и не пробуют более сложные: рефакторинг, анализ легаси, проектирование с нуля. Это не плохой результат - но сигнал к тому, что потенциал инструмента используется не полностью.
И главное - acceptance rate нельзя делать личным KPI разработчика. Как только люди видят, что их оценивают по этой цифре, они начинают нажимать Tab на все подряд. Метрика растет, качество падает.
Распределение AI-запросов по типам задач: рефакторинг - 28%, отладка - 26%, генерация нового кода - 19%, исправление ошибок - 8%, код-ревью - 5%, прочее - 14%.
На простых задачах - документация, типовые CRUD, покрытие тестами - ускорение заметное и стабильное. На сложных архитектурных задачах AI работает как второй пилот, а не как автопилот.
Смотреть только на суммарный acceptance rate без разбивки по типам задач - это считать среднюю температуру по больнице. Вся аналитическая ценность исчезает.
Не «рост производительности на X%» - это число, которое бизнес воспринимает как маркетинг. Считали в часах:
Метод: контрфактуальный - сравнивали время на аналогичные по сложности задачи до и после внедрения. Время берем из логов копилота, не из git: git дает только долю AI-строк в коммите, но не показывает, сколько реального времени заняла задача. Не строки кода, не acceptance rate - время на задачу.
Часы переводятся в деньги. Деньги понятны CFO.
На Veai 5.2 в активной работе - 50 инженеров, 27 700 саджестов за один месяц. Итоговый срез в зрелой фазе:
Разрыв между 87% и 65% - это gap между «нравится» и «стало привычкой». Он всегда есть, и это нормально. Важно, что он сокращается со временем. Чтобы ускорить переход от "нравится" к "привычке" - добавьте AI в рутинные таски (не только в единичных задачах) и зафиксируйте gap еженедельно.
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. Это аргумент против того, чтобы считать только скорость.
В версии 5.2 работали с Qwen и DeepSeek. Каждая новая модель - это другое качество саджестов: часть предложений, которые разработчик раньше отклонял, теперь принимает - или наоборот. Если не зафиксировать, какая модель работала в какой период - рост acceptance rate нельзя интерпретировать как улучшение процесса.
☝️Модель, версия инструмента, состав команды - все это контекстные переменные. Они всегда должны быть рядом с цифрами в отчете, иначе данных недостаточно для выводов.
Материал на основе выпуска подкаста Code of Leadership S2E1 на канале «Книжный куб». Флагманский контент‑проект Telegram‑канала «Книжный куб», где технический директор Т‑Банка Александр Поломодов собирает практики лидеров инженерных команд и AI‑native компаний.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。