Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, как пересобрать метрики инженерной команды, когда значительная часть изменений делается с участием ИИ‑агентов, а старая панель показателей начинает вводить в заблуждение.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

Ситуация такая. Вы внедрили агентов в команде, прошло два квартала. На дашборде velocity вырос, число пулл‑реквестов (дальше — PR) выросло, тикетов закрывается больше.

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

И тут приходит CTO с вопросом: «Мы платим за токены столько‑то, покажи, что это окупается».

Показать нечем — почти все операционные цифры выросли, а доверия к ним нет.

Ниже маршрут на четыре недели, который делается силами тимлида и одного дата‑инженера на полставки, не останавливая поставку.

Исходные условия

Чтобы маршрут был воспроизводимым, зафиксирую вводные. У меня они были примерно такими, и если ваши сильно отличаются, часть шагов придётся адаптировать.

• Продуктовая команда 25–40 инженеров, 4–6 сервисов на Java/Kotlin, монорепозиторий не используется.

• Агенты доступны всей разработке. Доля изменений, в которых использовались агенты, оценивается в 40–60%. Именно изменений, а не строк кода: доля «машинных строк» неизмерима без договорённости о том, что считать машинной строкой.

• Git‑хостинг с нормальным API (GitLab или GitHub), задачи в Jira, CI на GitLab CI или Jenkins.

• Есть какой‑то сбор DORA‑метрик, чаще всего кривой и никем не проверенный.

• Бюджет на изменения: ноль. Всё делается на существующем стеке.

• История PR, деплоев и инцидентов за 12 месяцев уже существует в Git, Jira и CI. Неделя маршрута уходит не на накопление истории, а на её нормализацию. Без неё измерять эффективность AI‑агентов в разработке рано: сравнивать не с чем.

Почему старые цифры перестали работать

Долгое время я считал, что DORA — универсальный язык для разговора с бизнесом.

Оказалось, что язык остался, а значения слов поменялись.

DORA в отчёте ROI of AI‑assisted Software Development описывает это как verification tax: время, сэкономленное на генерации, частично возвращается в систему в виде дополнительной проверки и аудита.

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

Дальше цифры, от которых мне стало не по себе.

По телеметрии Faros медианное время нахождения PR в ревью выросло на 441%, размер PR — на 51,3%, а доля PR, вливающихся вообще без ревью, выросла на 31%. Узкое место сместилось из «написать» в «проверить», а часть проверок молча отвалилась.

Третье: исследование Стэнфорда, на которое ссылается InfoQ, даёт прирост в 35–40% на простых задачах на чистом листе и порядка 10% или меньше на сложном легаси. Если основная работа команды связана со сложным легаси и интеграциями, ориентироваться на greenfield‑эксперименты опасно: ожидания у руководства сформированы первым сценарием, а живёте вы во втором.

Помню, как однажды я сам попал в эту ловушку. Мы отчитались за квартал ростом числа смёрженных PR. Через месяц выяснилось, что треть прироста дали PR на 40 строк с правкой конфигов, которые агент нарезал вместо одного нормального изменения. Формально рост в полтора раза, фактически та же работа, размазанная тоньше.

История, которую стоит знать до того, как заводить дашборд

В конце 2025 — начале 2026 по индустрии прокатилась мода, которую назвали токенмаксингом: потребление токенов стали выставлять как показатель продуктивности и заводить под него внутренние лидерборды.

Самая известная история произошла в Meta.

Как сообщала The Information и пересказала Fortune, отдельный сотрудник построил на внутренней платформе лидерборд Claudeonomics, ранжировавший более 85 тысяч сотрудников по расходу токенов. За 30 дней совокупный расход составил около 60,2 триллиона токенов, лидер израсходовал 281 миллиард. Через два дня после публикации лидерборд отключили — с формулировкой, что данные из него ушли наружу.

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

Метрика начала оптимизировать саму себя примерно за месяц.

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

Там же цифра из AI Impact Report 2026: 58% организаций меряют эффект от ИИ через потребление токенов, и 57% считают, что это не отражает реальную ценность.

Я вынес из этого одно правило, которое теперь пишу первым пунктом в любом соглашении о метриках: метрика, которая считает усилие вместо результата и становится KPI, очень быстро начинает оптимизироваться сама под себя. Закон Гудхарта работает быстрее, чем успевает выйти квартальный отчёт. Поэтому шаг первый — не строить новый дашборд, а разобрать старый.

Куда уезжает выигрыш

Прежде чем чинить, надо договориться о модели происходящего. На рисунке 2 та схема, которую я рисую на флипчарте, когда объясняю команде, почему «стало быстрее» и «стало хуже» — не противоречие.

Главная мысль схемы: рост скорости генерации расходится по нескольким направлениям сразу. Часть остаётся чистым выигрышем, часть перераспределяется в верификацию, часть возвращается переделкой.

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

Маршрут: шесть шагов за четыре недели

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

Шаг 1. Атрибуция AI‑ассистирования (неделя 1)

Закрываемый риск: изменения нельзя сегментировать, поэтому любое сравнение «до и после» смешивает несопоставимое.

Сразу оговорка, которая экономит много споров на ревью.

Мы не определяем происхождение кода: строка, которую написал агент, переписал человек, а потом поправил второй разработчик, не имеет однозначного авторства, и git на этот вопрос не отвечает.

Мы фиксируем заявленный уровень AI‑assistance при работе над изменением. Этого достаточно для сегментации и недостаточно для выводов о причинности.

Технически хватает трейлера в коммите и проверки в CI. Для изменения без участия агента:

Assist-Level: none

Для изменения с участием агента:

Assisted-By: claude-code
Assist-Level: assisted

(Формат — Git commit trailer, разбирается любым парсером; третье значение agent-led ставится, когда основную часть работы вёл агент.)

Дальше уровень поднимается на PR: squash‑мёрж и rebase легко теряют историю трейлеров, поэтому единицей анализа делаем именно пулл‑реквест, а атрибуцию агрегируем на него.

Проверка: атрибуция проставлена минимум в 80% смёрженных PR за неделю, и вы можете назвать долю ассистированных изменений с точностью до десяти процентных пунктов.

Шаг 2. Историческая база (неделя 1)

Закрываемый риск: нет точки отсчёта, и любой вывод превращается в спор об ощущениях.

Собираем витрину по PR за 12 месяцев. Обратите внимание на три места, где легко соврать самому себе: как называется метрика времени, что считается человеческим аппрувом и куда деваются PR без запроса ревью.

-- (SQL) базовая витрина по PR для сравнения "до / после"
SELECT
    date_trunc('week', pr.merged_at)                        AS week,
    pr.ai_assistance,                        -- none / assisted / agent-led
    pr.risk_level,
    count(*)                                                AS pr_count,
    -- это время от запроса ревью до мёржа, а не "время в ревью":
    -- внутрь попадают ожидание, доработка автора, повторные раунды и CI
    percentile_cont(0.5) WITHIN GROUP (
        ORDER BY extract(epoch FROM pr.merged_at - pr.first_review_request_at) / 3600
    ) FILTER (WHERE pr.first_review_request_at IS NOT NULL)
                                                            AS median_hours_request_to_merge,
    -- PR, на которых ревью вообще не запрашивалось, считаем отдельно,
    -- иначе они молча выпадают из перцентиля выше
    avg((pr.first_review_request_at IS NULL)::int)           AS share_no_review_requested,
    -- человеческий аппрув: боты и сервисные аккаунты исключены на этапе загрузки
    avg((pr.human_approval_count = 0)::int)                  AS share_no_human_approval,
    percentile_cont(0.5) WITHIN GROUP (ORDER BY pr.changed_lines)
                                                            AS median_pr_size
FROM analytics.pull_requests pr
WHERE pr.merged_at >= now() - interval '12 months'
GROUP BY 1, 2, 3
ORDER BY 1, 2, 3;

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

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

Шаг 3. Сегментация по риску (неделя 2)

Закрываемый риск: изменение в модуле расчёта комиссий и правка в README попадают в одну медиану и маскируют друг друга.

Путь файла — только часть признака. Высокорисковым изменение делают ещё миграция базы, схема Kafka, IAM‑политика, Terraform и Helm, фича‑флаг, фильтр аутентификации. И правила обязаны иметь приоритет, иначе PR, который трогает и payment, и docs, получит два уровня сразу.

# (YAML) условный DSL для иллюстрации, а не готовый конфиг GitLab или GitHub:
# набор признаков и способ их вычисления зависят от платформы и репозитория.
# Порядок правил задаёт приоритет, побеждает первое совпадение.
evaluation: first_match_wins
rules:
  - level: high
    match_any:
      paths: ["**/payment/**", "**/billing/**", "**/security/**"]
      change_types: ["db_migration", "kafka_schema", "iam_policy", "terraform", "helm", "auth_filter"]
    policy:
      minimum_human_approvals: 2
  - level: medium
    match_any:
      paths: ["**/service/**", "**/api/**"]
    policy:
      minimum_human_approvals: 1
  - level: low
    match_any:
      paths: ["**/docs/**", "**/*.md", "**/test-fixtures/**"]
    policy:
      minimum_human_approvals: 1
      allow_bot_only_approval: true

Политику и измерение держите раздельно. В YAML живёт требование, а в витрине — три поля: сколько аппрувов требовалось, сколько получено фактически и был ли зафиксирован обход правила.

Проверка: каждый смёрженный PR за неделю получил ровно один уровень риска, и вы можете объяснить, почему конкретный спорный PR попал именно в этот уровень. Если high‑risk начинает охватывать непропорционально большую долю изменений, сначала проверьте правила и распределение типов работ. Само по себе процентное значение бенчмарком не является: в платёжной платформе высокая доля высокорисковых изменений — норма.

Шаг 4. Нагрузка и качество контура ревью (неделя 2)

Закрываемый риск: место, куда перераспределилась нагрузка, остаётся неизмеренным.

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

Проверка: вы отвечаете за тридцать секунд на вопрос «сколько высокорисковых PR за месяц ушло в прод без человеческого аппрува» и можете открыть список этих PR, чтобы разобрать конкретные обходы политики.

Шаг 5. Переделка после мёржа (неделя 3)

Закрываемый риск: настоящая цена скорости невидима, потому что переделка не считается работой.

Здесь я сознательно не изобретаю собственную метрику, хотя соблазн есть. В актуальной модели DORA уже есть deployment rework rate — доля деплоев, которые не были запланированы и были выполнены, чтобы устранить инцидент или пользовательскую проблему в проде. В апреле 2026 её добавили в DORA Quick Check вместе с обновлёнными индустриальными бенчмарками, так что это общий язык, а не самоделка.

И вот тут важный момент, на котором я сам однажды собрал неверный дашборд. Деплой не имеет уровня AI‑assistance. В релиз уезжает десяток PR с разной атрибуцией, и приписать деплою одно значение можно только произвольным правилом. Поэтому rework rate считаем общей метрикой здоровья потока, без разбивки:

-- (SQL) deployment rework rate помесячно, без разбивки по атрибуции:
-- у деплоя нет собственного уровня AI-assistance
SELECT
    date_trunc('month', d.deployed_at)                                   AS month,
    count(*)                                                             AS deployments,
    count(*) FILTER (WHERE d.is_unplanned AND d.incident_id IS NOT NULL)::numeric
        / nullif(count(*), 0)                                            AS deployment_rework_rate
FROM analytics.deployments d
WHERE d.deployed_at >= now() - interval '6 months'
GROUP BY 1
ORDER BY 1;

А сравнение групп ведём там, где атрибуция определена однозначно — на уровне PR:

-- (SQL) признаки переделки на уровне PR, где атрибуция определена
SELECT
    pr.ai_assistance,
    pr.risk_level,
    count(*)                                        AS pr_count,
    avg(pr.has_revert::int)                         AS share_reverted,
    avg(pr.has_hotfix_within_72h::int)              AS share_hotfixed,
    avg((pr.incident_id IS NOT NULL)::int)          AS share_incident_linked,
    avg(pr.has_followup_fix::int)                   AS share_followup_fix
FROM analytics.pull_requests pr
WHERE pr.merged_at >= now() - interval '6 months'
GROUP BY 1, 2
ORDER BY 1, 2;

Правило простое: всё, что считается на уровне деплоя, остаётся без AI‑разбивки, всё, что сравнивается по атрибуции, считается на уровне PR. Смешение этих двух гранулярностей — самая частая ошибка в таких дашбордах.

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

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

Могу себе представить, как на этом шаге команда напряжётся. Проговорите заранее и жёстко: цифры смотрим по системе, а не по людям. Как только переделка становится персональным KPI, вы получите ту же историю, что с токен‑лидербордами, только в миниатюре.

Проверка: есть deployment rework rate за три месяца как общий показатель потока и доля переделки по PR в разрезе атрибуции и риска. И вы можете назвать хотя бы одну гипотезу, объясняющую разницу между группами.

Шаг 6. Стоимость и разговор с бизнесом (неделя 4)

Закрываемый риск: вы всё посчитали, но продолжаете отчитываться старыми цифрами, потому что новые некому объяснить.

Сначала таблица соответствий, которую можно унести на встречу.

Про последнюю строку скажу отдельно, потому что сам долго использовал старый термин. В актуальной модели DORA пять метрик, разделённых на throughput и instability, и прежний MTTR заменён на failed deployment recovery time — время восстановления после неудачного деплоя, потребовавшего немедленного вмешательства.

Это показатель именно про неудачное изменение, а не про любой инцидент. Он измеряет другой участок потока — способность команды быстро вернуть систему в рабочее состояние, — поэтому анализировать его нужно отдельно от throughput‑метрик, а не в одном ряду с ними.

Но всё перечисленное измеряет поток поставки и не отвечает на вопрос CTO про деньги. Грубая рамка, которую я использую, чтобы разговор с финансами не превращался в обмен ощущениями:

чистый эффект ≈ оценка высвобожденного инженерного времени
              − стоимость инструментов и токенов
              − прирост стоимости верификации
              − стоимость переделки и инцидентов

прирост стоимости верификации ≈ Δ(часы ревью)
                                × полная стоимость часа инженера для компании

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

Точность тут будет невысокой, и это нормально. Сама DORA в ROI‑отчёте предлагает считать три сценария — консервативный, реалистичный и оптимистичный — и приносить в разговор с финансами диапазон, а не одну цифру.

Проверка: на встрече вы показываете диапазон чистого эффекта с явно названными допущениями, и разговор идёт про допущения, а не про velocity.

Общий маршрут — на рисунке 3.

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

Где этот подход не сработает

Честно про ограничения, потому что универсального решения тут нет.

• Первое и главное: всё описанное позволяет сравнивать группы изменений и искать связанные с внедрением агентов эффекты, но не доказывает причинность. Команда, которая внедрила агентов, обычно одновременно поменяла ещё три вещи — ветвление, состав ревьюеров, частоту релизов.

Не сравнивайте среднее «до» со средним «после» без контроля за типом изменений. Минимальный честный baseline — сопоставление изменений с совпадающими уровнем риска, типом работы (фича, багфикс, рефакторинг, миграция, документация), размером и сервисом. Ассистированную фичу и рукописную миграцию базы бессмысленно ставить рядом, даже если у обеих high‑risk и триста строк.

• Второе: если сопоставимых изменений мало, медианы будут нестабильны. Ориентируйтесь не на численность команды, а на число сопоставимых изменений за период — у шести человек с пятью сотнями PR статистики больше, чем у тридцати с сорока.

• Третье: любая метрика на уровне отдельного разработчика ломает конструкцию. DORA‑показатели не проектировались как персональная оценка, и попытка их так использовать возвращает вас в мир лидербордов.

И главное ограничение: всё это меряет поток поставки, а не ценность продукта. Здесь принято ссылаться на широко цитируемое исследование MIT Project NANDA “The GenAI Divide: State of AI in Business”, где около 95% рассмотренных корпоративных GenAI‑инициатив не дали измеримого эффекта на P&L.

Цифру стоит трактовать аккуратно: это не «95% всех AI‑проектов провалились», а результат по конкретной выборке из нескольких сотен публичных внедрений и полутора сотен опрошенных руководителей, с довольно узким критерием успеха — многие пилоты просто не имели зафиксированного baseline до внедрения.

Направление вывода при этом сомнений не вызывает: аккуратная панель метрик не спасёт продукт, который делает не то. Она честно покажет, с какой скоростью вы делаете не то.

Что дальше

Главная проблема метрик в эпоху агентов не в том, что DORA устарела. Проблема в том, что мы берём показатели одного этапа системы и предъявляем их как доказательство эффективности всей системы.

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

Если формулировать одним предложением: перестаньте измерять объём AI‑активности как замену продуктивности и начните измерять путь изменения от идеи до прода вместе с его полной стоимостью.

ЧТО ПОЧИТАТЬ ПО ТЕМЕ:

• Путь до CTO: как пройти его самому и помочь пройти другому

Когда команда растёт, CTO важно понимать, какие показатели действительно отражают состояние разработки, а какие создают ложное ощущение контроля. Разобраться с отдельной метрикой — это только первый шаг. Главная задача — научиться принимать технические решения с учётом бизнес‑целей, видеть риски и управлять эффективностью команды.

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

• 8 сентября в 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться

• 16 сентября в 20:00. «Диагностика команды: как выявить проблемы до того, как они повлияют на результат». Записаться

• 22 сентября в 20:00. «Метрики CTO: показатели, которые действительно нужно контролировать». Записаться

Полный список бесплатных уроков сентября собрали в дайджесте.