Эффект: что измерять и как не обмануться

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

Ловушка самооценки

Самый неудобный факт для любого внедрения — разработчики плохо оценивают собственное ускорение. В рандомизированном исследовании METR 2025 года опытные разработчики в своих зрелых проектах с разрешённым ИИ тратили на задачи на 19% больше времени, но после эксперимента считали, что ускорились на 20% (METR, 2025). Ощущение и измерение разошлись даже по знаку.

Обновление METR в феврале 2026 года (57 разработчиков, 143 репозитория, более 800 задач) дало точечные оценки в сторону ускорения: для вернувшихся участников — около 18% экономии времени, для новых — около 4%. Но все доверительные интервалы включают ноль, а METR называет данные очень слабым свидетельством из-за эффектов отбора: часть разработчиков отказывалась работать без ИИ и не приносила подходящие задачи (METR, 2026). Там же отмечено, что результаты 2025 года устарели, и что учёт времени ломается, когда разработчик ведёт несколько агентов параллельно.

Вывод не в том, что агенты не работают. Вывод в том, что опросы «насколько вы ускорились» нельзя использовать как метрику.

Что показывает DORA

Отчёт DORA 2025 года — ежегодное исследование практик поставки ПО, почти 5 000 респондентов (DORA 2025):

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

Главная рамка отчёта: ИИ усиливает то, что в организации уже есть. Для измерения это значит: смотрите одновременно на скорость и на стабильность. Рост числа MR при росте возвратов и багов от клиентов — не эффект, а перенос затрат вперёд.

Кейсы вендоров — не бенчмарки

Публикации OpenAI содержат впечатляющие цифры: в статье о Symphony — рост числа смёрженных PR на 500% у некоторых команд за первые три недели, в статье о harness engineering — около 3,5 PR на инженера в день. Это реальные заявления поставщика о его собственных командах и продуктах, но не независимые измерения и не ориентир для чужих проектов. Число PR зависит от их размера и от того, как устроен процесс; в greenfield-проекте, построенном под агентов, и в клиентском легаси оно значит разное. Используйте такие кейсы как идеи, что попробовать, а не как цель для KPI.

Рамки для метрик

Чтобы не изобретать заново, опирайтесь на готовые рамки:

• DORA — частота поставки, время от коммита до продакшена, доля неудачных изменений, время восстановления. Скорость и стабильность вместе.
• SPACE — удовлетворённость, производительность, активность, коммуникация, эффективность и поток. Основная мысль авторов: ни одна метрика не описывает продуктивность целиком (ACM Queue).
• DX AI Measurement Framework — три измерения: использование, влияние, стоимость (DX). Удобно для отчёта руководству: «сколько используют, что изменилось, сколько стоит».

Что мерить в агентстве

Метрики, которые можно снять из трекера и Git-хостинга без опросов:

Аналитика рабочего пространства и Analytics API Codex покрывают использование и активность. Документация предупреждает, что категории, поля и форматы выгрузки могут меняться без уведомления, — не стройте долгосрочную отчётность на подписях дашборда (workspace analytics). Compliance API — для аудита, а не для продуктивности.

Не мерьте строки кода и число коммитов: агент увеличивает их почти бесплатно.

Как устроить пилот

1. Базовая линия. Снимите метрики за два-три месяца до пилота по тем классам задач, которые будете отдавать агенту.
2. Группа сравнения. Если возможно — похожая команда или похожие проекты без агентов в тот же период. Иначе сезонность и смена состава проектов смешаются с эффектом.
3. Классы задач. Сравнивайте тесты с тестами, багфиксы с багфиксами — не «все задачи до» со «всеми задачами после».
4. Достаточный срок. Метрики стабильности отстают: баги после релиза проявляются через недели.
5. Качество, а не только скорость. METR отмечал, что качество работы — тесты, документация — может отличаться между условиями с ИИ и без. Включите в оценку выборочный разбор MR.

Тимлидский уровень этой работы — метрики команды и их обсуждение — в уроке «Метрики».