Метрики AI-разработки: перестаньте считать PR

Почему подсчет pull request'ов перестает помогать

AI-ассистент для программирования может превратить одну функцию в шесть аккуратных патчей еще до обеда. Один PR добавляет тесты, другой переименовывает функции, третий чинит lint, четвертый обновляет промпты, а еще два закрывают крайние случаи. Счетчик растет быстро, а пользователи все равно получают одно небольшое изменение.

Из-за этого метрики pull request'ов плохо заменяют прогресс. В командах, которые используют AI-инструменты, сам инструмент часто задает форму работы. Очень легко наделать много чистых, удобных для проверки диффов и при этом почти ничего по-настоящему важного не выпустить.

Проблема становится хуже, когда менеджеры вознаграждают за объем. Люди начинают дробить работу на более мелкие PR, потому что таблица результатов поощряет активность. Неделя с 18 мерджами может выглядеть лучше, чем неделя с 4, даже если во второй неделе вышел более сильный релиз и было меньше инцидентов.

Маленькие PR — не проблема. Часто они даже упрощают ревью. Проблема начинается тогда, когда счетчик становится целью.

Сразу видны несколько искажений:

• Одна задача превращается в несколько PR, потому что AI-инструмент предлагает отдельные проходы по чистке кода.
• Люди сливают малозначимые правки, чтобы цифры продолжали расти.
• Время на ревью уходит на повторяющиеся диффы, а не на рискованные изменения.
• Качество релизов падает, потому что команда гонится за мерджами, а не за стабильными выпусками.

Ревьюеры обычно чувствуют это первыми. Каждый лишний PR требует заголовка, контекста, комментариев, проверок и решения. После пятого похожего диффа люди уже просматривают все по диагонали. Вот тогда и проскальзывает настоящая проблема: слабый тест, скрытая зависимость или миграция, которая выглядела безобидно.

На дашборде такой паттерн заметить легко. Разработчик с помощью AI обновляет onboarding flow, и инструмент выдает восемь PR за два дня. Шесть из них — чистка и правки промптов. Один исправляет тест. Один меняет сам flow. График показывает рост результата. Клиенты почти ничего не замечают, пока не выходит финальный PR.

Вот почему метрики AI-разработки должны смотреть на долю принятых изменений, долю откатов и дефекты, дошедшие до пользователей. Эти числа связывают работу с тем, что действительно попало в релиз и насколько он был стабилен, а не просто с движением в репозитории.

Что измерять вместо этого

Измеряйте работу, которая выдерживает встречу с продакшном. В командах, использующих AI-инструменты, код может появляться быстро и в больших объемах. Но вопрос важнее простой: изменение удержалось, релиз не развалился и пользователи не столкнулись с проблемами?

Доля принятых изменений отвечает на первый вопрос. Она показывает, сколько слитой работы все еще остается в использовании через заданный срок, например через 7, 14 или 30 дней. Если команда мерджит много AI-помощи, но потом значительную часть удаляет, заменяет или тихо отключает, результат выглядел сильным, а прогресс был слабым.

Доля откатов отвечает на второй вопрос. Она показывает, как часто релиз приносит столько проблем, что команда его откатывает, выключает или срочно выпускает исправление. Плотный календарь релизов мало что значит, если каждый третий релиз требует аварийной уборки.

Дефекты, дошедшие до пользователей, отвечают на третий вопрос. Это баги, которые пользователи, support или мониторинг в продакшне находят уже после релиза. Они показывают, что проскочило мимо ревью, тестов и внутренних проверок. Пользователям все равно, сколько pull request'ов вы закрыли.

Нужны все три числа вместе. Доля принятых изменений показывает, держится ли выпущенная работа. Доля откатов показывает, создает ли релиз проблемы для команды. Дефекты, дошедшие до пользователей, показывают, дошли ли эти проблемы до реальных людей.

Любое одно число может ввести в заблуждение. У команды может быть высокая доля принятых изменений просто потому, что она избегает рисков и выпускает крошечные правки. Другая команда может иметь низкую долю откатов, потому что почти ничего не релизит. Дефекты, дошедшие до пользователей, добавляют проверку на реальность: что произошло, когда живые люди начали пользоваться продуктом?

Представьте команду, которая за месяц слила 80 изменений. Через две недели 62 из них все еще в продакшне. Два релиза пришлось откатить. После запуска появилось пять пользовательских багов. Теперь у вас есть цифры, с которыми можно работать. Можно посмотреть, почему 18 изменений не удержались, что вызвало откаты и где тесты не заметили реальное поведение.

Это куда полезнее отчета, который говорит только о том, что команда слила 200 pull request'ов.

Как определить долю принятых изменений

Доля принятых изменений показывает, сколько выпущенной работы действительно удержалось. В командах, использующих AI-инструменты, это важнее сырых метрик pull request'ов. Команда может слить много кода и все равно породить лишнюю возню, если половина потом откатится, будет исправлена или заменена уже на следующий день.

Определение должно быть простым. Считайте изменение принятым только если оно дошло до продакшна и осталось там на фиксированный период, не будучи откатанным или быстро переписанным. Если вы пропустите период ожидания, метрика превратится еще в один счетчик мерджей, только с более красивой упаковкой.

Сначала выберите временное окно, а уже потом публикуйте цифру. После этого не меняйте его. Для многих продуктовых команд разумно начать с 7–14 дней. Семь дней подходят, если вы деплоите часто. Четырнадцать дней безопаснее, если релизы идут медленнее или дефекты проявляются позже.

Рабочее правило выглядит просто:

• Начните с изменений, которые были смержены и дошли до продакшна.
• Подождите, пока пройдет согласованное окно.
• Уберите все, что команда откатила, быстро исправила хотфиксом или заменила из-за того, что оно не выдержало.
• Разделите то, что осталось, на общее число изменений, попавших в продакшн за этот период.

Если за месяц 100 изменений дошли до продакшна и 82 из них все еще живы через 14 дней, доля принятых изменений составляет 82%.

Будьте строги в том, что считается «быстро замененным». Используйте одно правило, а не еженедельные споры. Если другое изменение удаляет или переписывает выпущенное поведение в пределах того же окна, потому что первая версия не выдержала, считайте исходное изменение непринятым. Косметические доработки после этого — другое дело. Запишите правило один раз и сделайте его скучным.

Используйте одно и то же определение во всех репозиториях и командах. Это касается app-кода, backend-сервисов, внутренних инструментов и автоматизации вокруг AI-процессов. Если одна команда использует окно в 7 дней, а другая — в 30, сравнение перестает быть полезным. Последовательность важнее идеальной формулы.

Эта метрика становится полезной, когда руководители относятся к ней как к сигналу качества, а не как к счету, который надо накрутить. Командам должно быть безопасно выпускать меньше, если то, что доходит до релиза, действительно остается на месте.

Как отслеживать долю откатов

Начните с правила, которому команда может следовать каждый раз. Откат — это любое выпущенное изменение, которое пришлось удалить, отменить или выключить, потому что оно нанесло вред в продакшне. Если каждую неделю спорить об исключениях, цифра поплывет, и метрика превратится в шум.

Обычно в rollback events стоит включать:

• откат кода после релиза
• хотфикс, который убирает или отключает новое поведение
• выключение feature flag для плохого релиза
• изменение конфигурации, которое возвращает старое поведение
• частичную отмену одной части более крупного деплоя

Используйте один и тот же знаменатель и не меняйте его. Самый чистый вариант — число откатов, деленное на число принятых изменений за тот же период. Если вы смотрите метрику раз в неделю, используйте одно и то же недельное окно каждый раз. Если один деплой содержит двадцать AI-правок, не считайте это двадцатью откатами, если вы на самом деле не отменили двадцать принятых изменений.

Также полезно разделять полный и частичный откат. Полный откат означает, что команда полностью забрала изменение назад. Частичный откат означает, что часть осталась в продакшне, а сломанную часть выключили. Эта разница важна. Частичные откаты часто указывают на слабые границы релиза, смешанные партии или feature flags, которые появились слишком поздно.

Для каждого отката записывайте короткую причину. Держите список небольшим, чтобы люди пользовались им одинаково: неверная бизнес-логика, пробел в тестах, плохой промпт или сгенерированный код, проблема интеграции, проблемы с производительностью или надежностью.

Этот список причин важнее, чем кажется. Рост доли откатов привлекает внимание, но причина подсказывает, что именно чинить. Если большинство откатов связано с сгенерированным кодом, который трогает старую платежную логику, вам нужен более строгий ревью именно там, а не лекция о скорости разработки.

Следите за всплесками после поспешных пачек AI-изменений. Небольшая команда, использующая AI-инструменты, может за один день выпустить недельный объем работы, а затем еще два дня выключать флаги и возвращать старое поведение. Фиксируйте такие события, отмечайте причину и разбирайте их вместе. Вот тогда доля откатов становится реальным сигналом, а не показателем ради показателя.

Как отслеживать дефекты, дошедшие до пользователей

Дефекты, дошедшие до пользователей, — это баги, найденные после релиза. Эта метрика помогает команде оставаться честной. AI может помочь выпустить больше кода, но клиенты все равно судят продукт по тому, что ломается в продакшне.

Считайте только дефекты, о которых сообщили после релиза. Включайте сообщения от пользователей, support, sales и аккаунт-менеджеров. Если инженер нашел баг до того, как его увидели клиенты, не включайте его. Смешивание багов до и после релиза делает цифру шумной.

Одного общего числа мало. Группируйте дефекты по серьезности, чтобы мелкие раздражители не прятали серьезные сбои:

• Уровень 1: потеря данных, проблемы с безопасностью, сбои в платежах или продукт не может выполнить основную задачу
• Уровень 2: функция работает плохо, но люди все еще могут закончить задачу с усилием или обходным путем
• Уровень 3: мелкие баги интерфейса, неверный текст, косметические дефекты или небольшие раздражители

Так плохая неделя не будет выглядеть безобидно только потому, что на дашборде написано «12 багов» без контекста. Один сбой в оплате никогда не должен выглядеть так же, как одиннадцать исправлений опечаток.

Когда вы заносите дефект, привязывайте его к релизу, окну деплоя, тикету или набору изменений, который, скорее всего, его внес. Идеальная атрибуция встречается редко, особенно если вы деплоите по несколько раз в день. Важнее последовательность. Если команда обычно может отследить производственный баг до одного релиза или диапазона коммитов, закономерности быстро становятся видны.

Задайте одно правило для дублей и придерживайтесь его. Считайте дефект один раз, а потом записывайте, сколько сообщений по нему пришло. Шесть клиентов, столкнувшихся с одной и той же ошибкой в биллинге, — это все еще один дефект, дошедший до пользователей, но число сообщений показывает, насколько широко распространился ущерб. То же самое делайте с ложными тревогами. Если support сообщает о баге, а команда подтверждает ожидаемое поведение, закрывайте это как ложную тревогу и не включайте в метрику.

Простого журнала из пяти полей достаточно: дата обнаружения, серьезность, источник сообщения, предполагаемый релиз и статус. Этого хватит для понятной еженедельной картины. За месяц вы увидите не только сколько багов было. Вы увидите, какие релизы создают проблемы, какие вопросы доходят до клиентов и правильно ли команда исправляет основные вещи.

Простая схема, с которой можно начать уже в этом месяце

Вам не нужен большой проект с дашбордом, чтобы получить полезные цифры. Выберите одну команду, одну продуктовую область и один ежемесячный отчет. Этого достаточно, чтобы проверить, помогают ли метрики принимать решения или просто добавляют споров.

Запишите правила до того, как кто-то начнет смотреть на график. Если пропустить этот шаг, люди будут каждую неделю спорить о частных случаях и перестанут доверять отчету. Сделайте правила короткими, понятными и неизменными хотя бы на один месяц.

Практичный старт выглядит так:

• Возьмите данные по изменениям из системы контроля версий.
• Возьмите события деплоя и откатов из логов релиза.
• Возьмите дефекты, дошедшие до пользователей, из баг-трекера или очереди support.
• Сложите цифры в одну общую таблицу или короткий отчет.
• Просматривайте их раз в неделю по 15 минут.

У многих команд система контроля версий, данные о деплоях и тикеты уже закрывают большую часть работы. Если у вас уже есть GitLab, CI-логи и Sentry, скорее всего, у вас достаточно сырых данных, чтобы начать без новых покупок.

Делайте отчет маленьким. Одной страницы достаточно. Отслеживайте долю принятых изменений, долю откатов и дефекты, дошедшие до пользователей, а также короткую заметку о чем-то необычном, например о рискованном релизе, праздничной неделе или крупном рефакторинге.

Делайте встречу короткой

Еженедельный разбор не должен превращаться в сеанс поиска виноватых. Смотрите на движение, а не на оправдания. Если доля откатов растет две недели подряд, спросите, что изменилось в релизной практике, тестовом покрытии или в том, как промпт превращается в код и ревью.

Не стоит бурно реагировать на одну плохую неделю. Команды, использующие AI-инструменты, часто выпускают работу рывками, и это может искажать метрики pull request'ов сильнее, чем раньше. Тренды за 6–12 недель расскажут гораздо более чистую историю, чем любой отдельный всплеск.

Простой пример хорошо это показывает. Допустим, команда из пяти человек стала выпускать больше кода после внедрения AI-инструментов для программирования, но доля принятых изменений упала, а дефекты, дошедшие до пользователей, выросли. Обычно это значит, что команда выпускает быстрее, чем успевает ревьюить, тестировать или готовить релизы. С этим можно работать. Сырый счетчик pull request'ов этого бы не показал.

Начните просто, зафиксируйте определения и дайте тренду один-два месяца, чтобы устояться. Скучные измерения всегда лучше эффектных графиков.

Реальный пример небольшой команды, использующей AI-инструменты

Команда из пяти человек добавила AI-инструменты для программирования в ежедневную работу. Два инженера использовали генерацию кода для рутинных тикетов, один — для заготовок тестов, и команда начала выпускать намного быстрее. В первый полный месяц они слили 94 pull request'а вместо привычных 48.

Сначала это выглядело как победа. Дашборд показывал больше активности, больше слитой работы и более короткий цикл. Но неделя после релиза оказалась грязной.

Support получил больше жалоб от клиентов. На странице настроек у части пользователей все ломалось. Исправление по биллингу потребовало двух патчей. Один релиз принес баг, из-за которого команде пришлось в тот же день откатить часть деплоя. К концу месяца команда выпустила почти вдвое больше pull request'ов, но доля откатов выросла с 3% до 11%.

Более серьезная проблема проявилась через несколько недель. Многие из этих быстрых изменений не удержались. Инженеры постоянно возвращались к ним, переписывали их или откатывали назад, когда всплывали крайние случаи. Доля принятых изменений за 30 дней упала с 79% до 62%.

Дефекты, дошедшие до пользователей, тоже пошли в неверную сторону. Обычно команда видела около 5 проблем в продакшне в месяц, которые не поймали тесты. После попытки выпускать больше это число выросло до 14. Сначала это почувствовал support. Потом — инженеры, потому что им пришлось больше времени тратить на исправление живых проблем и меньше — на новую работу.

Команда поменяла курс, не отказываясь от AI-инструментов. Она замедлила мерджи, стала делать меньшие партии и потребовала человеческое ревью для кода, который затрагивает платежи, авторизацию и удаление данных. Они также усилили тесты вокруг тех мест, которые ломались чаще всего.

Через шесть недель картина стала лучше. За месяц pull request'ов было 63, доля откатов упала до 4%, доля принятых изменений вернулась к 81%, а дефекты, дошедшие до пользователей, снизились до 6.

Этой команде не нужно было меньше инструментов. Ей нужны были более хорошие метрики AI-разработки. Как только она перестала хвалить сырой счетчик pull request'ов, стало видно, какие изменения действительно остаются в продакшне, а какие только создают больше работы.

Ошибки, которые искажают картину

Эти метрики помогают только тогда, когда вы делаете их скучными и стабильными. Большинство проблем в отчетности связано с тем, как команды считают, сравнивают и реагируют на цифры.

Если поменять определение в середине квартала, тренд ломается. Если в апреле доля принятых изменений означает «смёржено в main», а в мае — «дошло до продакшна и осталось там», график перестает рассказывать понятную историю. Зафиксируйте определение на весь период отчетности. Если вам нужно новое определение, начните новую базовую линию и отметьте разрыв.

Следующая проблема — плохие сравнения. Команда, которая выпускает десять маленьких обновлений в день, выглядит совсем не так, как команда, которая релизит раз в неделю большими партиями. Их доля откатов и дефекты, дошедшие до пользователей, не означают одно и то же, даже если подписи одинаковые. Сначала сравнивайте каждую команду с ее собственной недавней историей. Сравнивайте команды между собой только тогда, когда стиль релизов, риск продукта и размер изменений достаточно похожи.

Если считать все дефекты одинаковыми, картина тоже искажается. Сломанный checkout flow и опечатка на экране настроек не должны весить одинаково. Считайте уровни серьезности отдельно или добавьте простой балл влияния на основе боли клиента, усилий support и времени на исправление.

Использовать эти числа для ранжирования отдельных инженеров — быстрый способ их испортить. Люди начинают дробить работу на странные куски, избегать рискованных, но необходимых изменений или перекладывать дефекты на чужую очередь. Метрики AI-разработки работают лучше, когда они описывают здоровье команды и качество поставки, а не личную ценность.

Контекст имеет значение. Если после запуска вырос поток тикетов в support или продуктовая команда выкатила крупную переработку workflow, цифры обязательно сдвинутся. Это не всегда значит, что команда стала хуже. Метрика без контекста продукта и support — это просто число на слайде.

Когда график меняется, добавляйте рядом короткую заметку. Напишите, что изменилось в продукте, релизном процессе, нагрузке клиентов или объеме обращений в support. Эта простая привычка спасает от множества плохих решений.

Быстрые проверки перед тем, как поднимать отчет наверх

Плохие метрики становятся еще хуже по пути наверх. К тому времени, как еженедельный отчет доходит до основателя, CTO или совета директоров, расплывчатое число может превратиться в неверный вывод.

Начните с простого языка. Если один менеджер говорит, что доля принятых изменений — это «смёрженный код», а другой — что это «код, который дошел до продакшна и остался там», метрика уже сломана. Каждое число должно укладываться в одно короткое предложение, которое любой тимлид сможет повторить без сносок.

Даты тоже должны совпадать. Если релиз ушел во вторник, пользователи сообщили о баге в среду, а команда откатила его в ночь на среду, дашборд должен показывать ту же историю. Когда даты деплоя, отката и бага расходятся между инструментами, люди спорят о хронологии вместо того, чтобы чинить процесс.

Хороший отчет должен помогать заметить плохой релиз за секунды. Вам не должно требоваться читать тридцать PR, чтобы увидеть, что после одного окна релиза упали доля принятых изменений, выросла доля откатов и поднялись дефекты, дошедшие до пользователей. Если сигнал появляется только после ручного копания, дашборд слишком слабый.

У метрик должен быть короткий цикл обратной связи. Команда должна посмотреть на них и что-то изменить в пределах одного спринта. Это может быть уменьшение релизов, более строгие тестовые барьеры или пауза на сгенерированный код в одной рискованной области. Если никто не действует, отчет — просто украшение.

Есть еще одна проверка: не превращайте это в табель для отдельных разработчиков. Команды, использующие AI-инструменты, могут очень быстро выпускать много кода, а значит личные метрики становятся еще более обманчивыми. Эти показатели описывают здоровье релиза, а не то, кто работал тяжелее.

Один инженер с сильными промптами или агентами может открыть много pull request'ов и все равно устроить хаос для эксплуатации. Другой инженер может выпускать меньше изменений, избегать откатов и удерживать дефекты на низком уровне. Второй человек обычно приносит бизнесу больше пользы.

Если ваш отчет показывает, что было выпущено, что удержалось в продакшне, что проскочило мимо и что команда изменит в следующем спринте, его уже можно отправлять.

Что делать дальше

Начните с одной продуктовой области, а не со всей компании. Выберите поток, который часто релизится и получает реальный пользовательский трафик, а затем соберите 30 дней данных, прежде чем что-то менять. Эта базовая линия важна, потому что большинство команд спорит на основе памяти, а память обычно подводит.

Держите настройку простой. Вам не нужен новый проект с дашбордом или длинный политический документ. Вам нужен общий способ считать долю принятых изменений, долю откатов и дефекты, дошедшие до пользователей, одинаково каждую неделю.

Хорошо работает такой первый шаг:

• Выберите одну продуктовую область с частыми релизами.
• В течение 30 дней фиксируйте три метрики по текущему процессу.
• Разберите цифры на одной встрече с engineering, product и support.
• Поменяйте одну привычку за раз, а потом смотрите на следующие 30 дней.

Эта встреча важнее, чем ожидает большинство команд. Engineering может объяснить, где сгенерированные изменения ускоряли работу или создавали лишнюю чистку. Product может сказать, действительно ли принятые изменения двигали roadmap вперед. Support может показать, где дефекты, дошедшие до пользователей, задели реальных людей, а не только внутренний QA.

Когда закономерности станут видны, меняйте привычки исходя из них. Если доля принятых изменений низкая, ужесточите prompts для ревью, уменьшите размер задачи или просите делать более мелкие мерджи. Если доля откатов растет после быстрых релизов, уменьшите размер партии или добавьте одну дополнительную проверку перед деплоем. Если дефекты продолжают проскальзывать, чините пробелы в тестах, а не вините модель.

Именно здесь метрики AI-разработки начинают приносить реальную пользу. Они перестают быть таблицей результатов и начинают работать как обратная связь. Команда, которая выпускает меньше pull request'ов, но приносит больше принятых изменений и меньше откатов, делает более качественную работу.

Если ваша команда слишком близко к проблеме, поможет внешний разбор. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и советник, в том числе по AI-усиленным рабочим процессам и бережливым системам поставки. На практике такой порядок обычно начинается с более четких определений и спокойных релизных привычек, а не с лишнего процесса.