Метрики AI-разработки: чем измерять эффект Coding Agents, если не строками кода

Когда компания внедряет Coding Agents, первый отчёт обычно выглядит так: сколько разработчиков пользуются агентом, сколько запросов, сколько строк, какой процент кода написал AI. Цифры растут, и кажется, что эффект есть.

Короткий ответ. Эти цифры показывают, что инструментом пользуются. Они не показывают, стала ли поставка быстрее и надёжнее. Эффект AI в разработке измеряют по пути изменения до пользователя: Lead Time от идеи до продакшена с ожиданием по этапам, 4 ключевые метрики DORA, доля переделок, время ревью и стоимость принятого изменения.

Почему метрики написания кода обманывают

Строки кода — плохая метрика для людей. Для агентов она ещё хуже: агенту строки ничего не стоят. То же касается токенов, числа запросов к модели, числа активных пользователей ассистента и «доли кода, написанного AI».

Хороший пример — Google. В октябре 2024 года компания сообщала, что AI генерирует больше четверти нового кода, затем его проверяют и принимают инженеры. В апреле 2026 года Сундар Пичаи назвал уже 75% нового кода, сгенерированного AI и одобренного инженерами, — против 50% осенью 2025-го. Цифра впечатляющая. Но методика подсчёта не раскрыта, и это метрика написания кода. Она ничего не говорит о том, как быстро и надёжно изменения доходят до пользователей, и не означает, что AI делает 75% работы инженеров.

Метрики написания кода обманывают ещё и потому, что рост объёма может быть признаком проблемы. DORA в отчёте 2024 года объясняет падение стабильности поставки именно этим: с AI растёт размер пакетов изменений, а большие пакеты повышают риск. Faros AI в вендорском отчёте 2025 года видит в командах с высоким использованием AI PR крупнее на 154%.

Второй источник обмана — ощущения. В рандомизированном эксперименте METR начала 2025 года 16 опытных разработчиков с AI решали задачи на 19% дольше, но считали, что ускорились примерно на 20%. Выборка маленькая, а в 2026 году METR сам сообщил о небольшом ускорении на новых данных и изменил дизайн исследования из-за эффекта отбора. Поэтому я не использую эту работу как «AI замедляет». Урок другой: ощущение ускорения и измеренное время могут расходиться даже по знаку. По DORA 2025, больше 80% респондентов считают, что AI повысил их продуктивность, — и это тоже самоотчёт, а не замер.

Три уровня метрик

Я делю метрики AI-разработки на три уровня. У каждого своя задача, и ошибка — принимать нижний уровень за верхний.

УРОВЕНЬ 3 · РЕЗУЛЬТАТ          быстрее и надёжнее доходит до пользователя?
  Lead Time идея → продакшен, 4 метрики DORA, стоимость принятого изменения

УРОВЕНЬ 2 · ПОТОК И КАЧЕСТВО   где стоит работа и сколько её переделывают?
  ожидание по этапам, время ревью, размер PR, доля переделок, приёмка с первого раза

УРОВЕНЬ 1 · ИСПОЛЬЗОВАНИЕ      пользуются ли инструментом?
  активные пользователи, запросы, токены, строки, доля кода от AI

Уровень 1 нужен, чтобы понять, работает ли внедрение. Уровень 2 — чтобы найти, где тормозит. Уровень 3 — чтобы ответить руководству, есть ли эффект.

Lead Time от идеи до продакшена

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

Считать Lead Time полезно вместе с ожиданием на каждом этапе. Coding Agent сокращает время работы над кодом, но не трогает очереди — перед ревью, тестами, стендом, релизом. Почему ускорение кода в 10 раз не даёт такого же ускорения поставки и куда переезжает узкое место, я разобрал в статье о том, почему AI не ускоряет разработку в 10 раз.

Практические правила:

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

4 метрики DORA: скорость и стабильность вместе

DORA много лет использует 4 ключевые метрики поставки:

• время прохождения изменения от коммита до продакшена (lead time for changes);
• частота развёртываний (deployment frequency);
• доля неудачных изменений — сколько развёртываний приводит к сбою и требует исправления (change failure rate);
• время восстановления после неудачного развёртывания.

Первые две — про скорость, вторые две — про стабильность. Для оценки AI важно смотреть на обе пары, потому что данные расходятся. По оценке DORA 2024, при росте использования AI на 25% пропускная способность поставки снижалась примерно на 1,5%, а стабильность — примерно на 7,2%. В отчёте 2025 года связь с пропускной способностью стала положительной, а со стабильностью осталась отрицательной. Это корреляции на опросных данных, а не эксперимент, но вывод для метрик прямой: если вы смотрите только на скорость, вы можете не заметить, что покупаете её стабильностью.

DORA-шное время прохождения изменения считается от коммита. Поэтому я использую его вместе с Lead Time от идеи: первая метрика показывает конвейер поставки, вторая — весь путь.

Rework: переделки и приёмка с первого раза

Доля зелёных тестов — плохая метрика качества кода от агента. В эксперименте к выпуску «От Coding Agent к AI Development Platform» агент получал задачу добавить самовывоз в синтетический сервис доставки. Во всех 6 прогонах он писал собственные тесты, и все они были зелёными: от 19 до 26 тестов. Но независимая приёмка по требованиям дала прогонам без контекста от 2 до 4 проверок из 10, а прогонам с контекстом — 10 из 10. Тест агента в одном из прогонов закреплял бесплатную доставку, которой в требованиях не было. Подробно — в статье о том, почему AI написал код и тесты, всё зелёное, а задача не решена.

Поэтому вместо «процента зелёных тестов» я смотрю на переделки:

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

Rework — моя рекомендация, а не одна из 4 метрик DORA в том виде, как они перечислены выше. Но именно она первой показывает, что агент пишет «правильный код, который решает не ту задачу».

Время ревью и размер изменений

Когда код становится дешёвым, ревью первым превращается в узкое место. Faros AI (телеметрия более 10 000 разработчиков, вендорский отчёт, корреляция) видит в командах с высоким использованием AI на 98% больше PR, время ревью на 91% дольше и PR крупнее на 154%. При этом значимой связи с улучшениями на уровне компании авторы не нашли.

Любопытная деталь из DORA 2024: рост использования AI связан с ускорением code review примерно на 3,1% — и одновременно с падением пропускной способности поставки. Отдельное ревью стало быстрее, а система — нет. Это ещё одна причина мерить поток, а не скорость шага.

Что считать:

• время до первого ревью — сколько PR ждёт, пока его кто-то откроет;
• время в ревью — от первого комментария до одобрения;
• размер PR — строки и файлы. Это единственное место, где строки полезны: не как метрика продуктивности, а как индикатор риска;
• очередь на ревью — сколько PR ждут прямо сейчас. Если она растёт неделю за неделей, агенты производят больше, чем команда способна проверить.

Стоимость принятого изменения

Стоимость токенов и прогонов агента легко посчитать, и поэтому её считают первой. Но полезная метрика — стоимость изменения, которое реально прошло приёмку.

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

Если смотреть на стоимость прогона, условие A дешевле примерно на 30%, и контекст выглядит лишней тратой. Если смотреть на стоимость принятого изменения, условие A не дало ни одного результата, который можно мержить. Время прогона контекст тоже не сократил: в среднем около 6 минут в обоих условиях. Он изменил не скорость, а то, насколько код соответствует задаче.

В реальной команде в стоимость изменения входит ещё время людей: ревью, ответы на вопросы, исправления после возвратов. Оно почти всегда дороже токенов.

Отдельно — метрики самой платформы агентов. Самый дорогой и самый долгий прогон эксперимента, 1,85 доллара и 9 минут, получил 16 отказов в правах: я разрешил команду python, а агент запускал тесты через python3. Число отказов на задачу — хороший сигнал, что политика прав настроена плохо, об этом подробнее в статье про права Coding Agent: Allow / Ask / Deny.

Сводная таблица

Как собрать базовую линию

Отдельная аналитическая система для первого замера не нужна — хватит трекера задач и системы контроля версий.

1. Возьмите 20–30 недавно завершённых сопоставимых задач. Это стартовая выборка для диагностики, а не гарантия точности.
2. Выпишите для каждой временные метки переходов между этапами — от принятия идеи в работу до релиза.
3. Посчитайте медиану и 85-й перцентиль Lead Time и ожидания на каждом этапе.
4. Добавьте долю возвратов с ревью и долю неудачных изменений.
5. Зафиксируйте это как базовую линию до изменений и повторите замер через 1–2 месяца.

Если после внедрения агентов Lead Time не сократился, а доля переделок выросла, значит, вы ускорили не тот шаг.

Ограничения

• DORA и Faros дают корреляции, а не причинность. Faros — вендорский отчёт компании, которая продаёт аналитику продуктивности.
• METR — 16 человек и инструменты начала 2025 года; сам METR результат пересмотрел.
• Цифры Google — заявление компании без раскрытой методики.
• Мой эксперимент — 6 прогонов, один синтетический репозиторий, одна модель, проверки писал я. Это демонстрация механизма, а не бенчмарк. Расчёт стоимости принятого изменения не учитывает время людей.
• Любую метрику можно «накрутить», если сделать её целью. Поэтому метрики потока, качества и стоимости смотрят вместе.

Что делать

1. Разделите отчёт на три уровня: использование, поток и качество, результат. Не показывайте уровень 1 как эффект.
2. Снимите базовую линию Lead Time от идеи до продакшена и ожидания по этапам до масштабирования агентов.
3. Добавьте к скорости стабильность: 4 метрики DORA только вместе.
4. Замените «процент зелёных тестов» на приёмку с первого раза и долю переделок.
5. Считайте стоимость принятого изменения, а не прогона.
6. Раз в 1–2 месяца ищите этап с самым долгим ожиданием и меняйте процесс там.

Метрики — один из слоёв системы вокруг агентов, которую я называю AI Development Platform: вместе с контекстом, политиками, проверками качества и наблюдаемостью. Метрики эффекта — одно из семи измерений, по которым я оцениваю AI в разработке.

Понять, где в вашем процессе AI даёт эффект, а где упирается в следующее ограничение, помогает бесплатный AI Engineering Assessment: результат сразу, без регистрации. Это ориентировочная диагностика, а не аудит.

Пройдите бесплатный AI Engineering Assessment

Источники

• Q3 2024 earnings call remarks. Google (blog.google), 2024.
• Sundar Pichai shares news from Google Cloud Next 2026. Google (blog.google), 2026.
• Announcing the 2024 DORA report (Accelerate State of DevOps 2024). Google Cloud / DORA, 2024.
• Announcing the 2025 DORA Report: State of AI-assisted Software Development. Google Cloud / DORA, 2025.
• The AI Productivity Paradox Report 2025. Faros AI, 2025.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025.
• We are Changing our Developer Productivity Experiment Design. METR, 2026.
• Эксперимент выпуска «От Coding Agent к AI Development Platform»: 6 прогонов Claude Code (claude-sonnet-5) на синтетическом сервисе доставки. Владимир Павлунин, 2026.