Как пересобрать метрики команды после внедрения AI-агентов и не принять ложный рост velocity за успех
После появления AI-агентов инженерные команды часто сталкиваются с парадоксом: на дашбордах становится больше закрытых задач, пулл-реквестов и условных story points, однако сроки поставки увеличиваются, ревьюеры работают на пределе, а количество проблем после релиза растёт.
Руководство видит положительную динамику и закономерно спрашивает, окупаются ли расходы на токены. Команда же понимает, что привычные показатели больше не отражают реальную производительность. В такой ситуации недостаточно добавить на панель ещё несколько графиков. Необходимо заново определить, что именно считается результатом разработки.
Ниже - практический план пересборки системы измерений за четыре недели. Он рассчитан на команду из 25-40 инженеров, работающую с несколькими Java/Kotlin-сервисами, GitHub или GitLab, Jira и существующим CI. Дополнительный бюджет не требуется: используются данные из уже имеющихся систем.
Почему старые показатели начали вводить в заблуждение
До внедрения AI-агентов связь между количеством изменений и затраченными усилиями была относительно понятной. Разработчик создавал код, проходил ревью, исправлял замечания, а затем изменение отправлялось в продакшен. После автоматизации генерации кода узкое место часто перемещается.
Создание первой версии решения ускоряется, но возрастает нагрузка на проверку. Код необходимо внимательнее изучать, тестировать и сопоставлять с архитектурными ограничениями. На ревью приходят более крупные изменения, а иногда - множество мелких PR, разделяющих одну логическую задачу.
В исследованиях, посвящённых AI-assisted development, этот эффект называют verification tax - "налогом на верификацию". Сэкономленное на написании время частично возвращается в виде дополнительного аудита, тестирования и контроля рисков.
По данным телеметрии Faros, медианное время пребывания PR на ревью увеличивалось на 441%, средний размер PR - на 51,3%, а доля изменений, попадающих в основную ветку без ревью, - на 31%. Это хорошо показывает, почему простое увеличение числа смёрженных PR нельзя автоматически считать ростом эффективности.
Есть и другая проблема. Эксперименты на новых проектах дают более заметный результат: прирост производительности на простых задачах может составлять 35-40%. В сложном легаси, интеграциях и системах с большим количеством скрытых зависимостей эффект обычно значительно скромнее - порядка 10% или ниже. Поэтому нельзя переносить результаты greenfield-сценариев на всю инженерную организацию.
Как появляется ложный рост velocity
Самый распространённый источник искажения - дробление работы. Вместо одного содержательного изменения агент или разработчик создаёт несколько небольших PR: отдельно конфигурацию, отдельно DTO, отдельно тесты, отдельно рефакторинг. Количество PR увеличивается, а бизнес-результат остаётся прежним.
Та же проблема возникает с story points. Если оценка выставляется до начала работы, а затем задача дробится на несколько элементов, суммарный velocity может вырасти без соответствующего увеличения поставленной ценности.
Показатель "строки кода" становится ещё менее надёжным. Большой объём сгенерированного кода может означать не производительность, а дополнительную сложность, которую придётся сопровождать. Нельзя считать машинные строки без чёткого определения: учитывать ли автоматически созданные тесты, повторно сгенерированные файлы, форматирование и удалённый код?
Использование токенов также не является метрикой эффективности. Рост потребления может говорить о более сложных задачах, неудачных итерациях, длинном контексте или нерациональной настройке агента. Внутренние рейтинги по числу потраченных токенов создают стимул расходовать больше, а не решать задачи лучше.
Маршрут пересборки метрик на четыре недели
Неделя первая: зафиксировать участие AI и привести историю в порядок
Начинать следует не с оценки ROI, а с атрибуции. Нужно понять, в каких изменениях использовались AI-агенты и насколько интенсивно.
Наиболее практичный вариант - добавить в шаблон PR обязательный технический признак:
- AI не использовался;
- использовался для подсказок;
- применялся для генерации отдельных фрагментов;
- агент подготовил значительную часть изменения;
- агент участвовал в тестировании или рефакторинге.
Это не должно превращаться в контроль сотрудников. Задача - получить пригодную для анализа классификацию. Оценивать долю "машинных строк" не нужно: такой показатель трудно определить единообразно и легко превратить в формальность.
Одновременно требуется нормализовать историю за последние 12 месяцев. Для каждого PR желательно получить:
- дату создания, первого ревью и слияния;
- размер изменения;
- число итераций после замечаний;
- количество участников ревью;
- наличие обязательных проверок;
- связь с задачей Jira;
- дату первого деплоя;
- факт отката или инцидента.
На этом этапе важно исправить очевидные ошибки DORA-метрик. Например, deployment frequency нельзя считать по каждому техническому запуску pipeline, если часть из них не приводит к пользовательскому изменению. Lead time должен измеряться от согласованного момента начала работы до фактического выхода изменения, а не от случайной даты создания ветки.
Неделя вторая: разделить изменения по уровню риска
Сравнивать все PR в одной выборке неправильно. Небольшая правка текста и изменение платёжного контура имеют разную стоимость проверки и разные последствия ошибки.
Минимум стоит выделить четыре класса:
1. документация, конфигурация и низкорисковые исправления;
2. обычные изменения бизнес-логики;
3. интеграции, работа с данными и публичные API;
4. критичные участки: платежи, безопасность, авторизация, миграции и инфраструктура.
Для каждой группы нужно отдельно считать размер PR, время до первого ревью, время до слияния, количество возвратов, дефекты и откаты. Только такое сравнение позволит понять, где AI действительно помогает, а где просто увеличивает поток изменений.
Полезно добавить показатель сложности. Его можно оценивать по числу затронутых модулей, файлов, сервисов, внешних интеграций и уровню риска. Даже простая шкала из трёх уровней лучше, чем попытка судить о работе только по строкам или story points.
Неделя вторая: измерить нагрузку на ревью
После внедрения AI ревью становится самостоятельным производственным процессом. Поэтому его нужно измерять отдельно.
Ключевые показатели:
- время от открытия PR до первого содержательного комментария;
- время от первого ревью до готовности к слиянию;
- число раундов доработки;
- среднее количество PR на одного ревьюера;
- доля изменений, ожидающих ревью более установленного порога;
- доля PR, объединённых без обязательной проверки;
- количество замечаний на тысячу строк или на условную единицу изменения.
Важно учитывать не только среднее, но и медиану и верхние перцентили. Несколько очень долгих PR могут существенно исказить среднее значение, тогда как 90-й или 95-й перцентиль покажет реальную проблему очереди.
Нужно также проверить, не стало ли ревью формальным. Если количество комментариев падает, а число дефектов после релиза растёт, это не ускорение процесса, а потеря качества контроля.
Неделя третья: считать переделки после слияния
Главный вопрос к AI-инструментам - не сколько кода они создали, а сколько работы пришлось исправлять после интеграции.
К переделкам можно отнести:
- повторные изменения в течение 7-14 дней;
- откаты;
- hotfix после релиза;
- исправление дефектов в том же компоненте;
- дополнительные миграции;
- ручные корректировки результатов работы агента;
- инциденты, связанные с изменением.
Полезно ввести показатель rework rate - долю задач или изменений, потребовавших существенной переделки после слияния. Его следует считать отдельно для AI-assisted и обычных PR, но не делать поспешных выводов без учёта сложности.
Если AI-изменения в среднем крупнее, затрагивают больше сервисов и чаще проходят через новые участки системы, их нельзя напрямую сравнивать с простыми ручными исправлениями. Для корректности нужно сопоставлять одинаковые классы риска и похожие типы работ.
Как связать инженерные метрики с бизнес-результатом
Разговор с бизнесом стоит переводить от "числа токенов" к стоимости полного цикла изменения. В расчёт нужно включать:
- цену AI-инструментов;
- время разработчиков;
- время ревьюеров;
- работу QA и специалистов по эксплуатации;
- стоимость задержек релиза;
- последствия дефектов и откатов;
- дополнительное сопровождение созданного кода.
Например, агент может сократить время написания кода на четыре часа, но добавить шесть часов ревью и тестирования. В таком случае локальное ускорение генерации не означает экономии для всей системы.
Более зрелая формула выглядит так:
чистый эффект = сэкономленное время - дополнительная стоимость проверки - стоимость переделок - последствия дефектов.
Точную денежную оценку не всегда удаётся получить сразу. На первом этапе допустимо использовать относительные показатели: время команды, часы ревью, количество откатов и долю инцидентов.
Какие метрики стоит оставить на основном дашборде
Рабочая панель после внедрения AI может включать:
- lead time по классам риска;
- время ожидания и прохождения ревью;
- throughput, нормализованный по типу и сложности изменений;
- долю AI-assisted PR;
- размер и число итераций PR;
- процент переделок после слияния;
- дефекты, откаты и инциденты;
- долю изменений без обязательного ревью;
- стоимость AI на одну успешно доставленную бизнес-функцию;
- влияние на стабильность релизов.
Velocity при этом не обязательно удалять. Его следует перестать использовать как самостоятельный аргумент эффективности. Это вспомогательный показатель, который имеет смысл только вместе с качеством, временем поставки и объёмом переделок.
Где подход может не сработать
Система будет давать слабые результаты, если команда не договорилась о правилах фиксации AI-участия. Нельзя требовать точности, которой не обеспечивает сам процесс сбора данных.
Проблемы возникнут и при плохой связности Jira, Git и CI. Если задачи не связаны с PR, а деплои невозможно сопоставить с изменениями, расчёты придётся строить на предположениях.
Наконец, не стоит запускать внутренние рейтинги разработчиков по количеству PR, токенов или строк кода. Такие стимулы быстро меняют поведение: сотрудники начинают дробить задачи, усложнять историю изменений и использовать AI там, где он не нужен.
Что считать успехом
Успешное внедрение AI-агентов - это не максимальное число сгенерированных строк и не рекордный velocity. Признаки реального улучшения выглядят иначе:
- сокращается полный цикл от идеи до релиза;
- ревью не превращается в очередь;
- качество изменений не ухудшается;
- число переделок и откатов не растёт;
- команда быстрее берётся за сложные задачи;
- стоимость поставки одной функции снижается;
- инженерная организация сохраняет управляемость и предсказуемость.
Главный принцип прост: измерять нужно не скорость производства кода, а скорость безопасной доставки полезного результата. AI-агент может ускорить написание решения, но ценность появляется только тогда, когда это решение успешно прошло проверку, попало в продакшен и продолжило работать без дополнительного аварийного труда.
