Как измерять эффект от AI-инструментов

60% инженерных лидеров называют отсутствие чётких метрик главной проблемой при внедрении AI-инструментов. Компании тратят десятки тысяч долларов на лицензии Copilot или Cursor для команд, но не могут ответить на вопрос: мы стали быстрее? Nicole Forsgren, создательница DORA и SPACE, в октябре 2025 года прямо заявила: AI сломал привычные метрики продуктивности разработчиков. Строки кода, количество коммитов, velocity — всё это стало бессмысленным, когда 41% кода пишет машина.

Проблема: почему старые метрики не работают

Строки кода перестали быть proxy для продуктивности в тот момент, когда AI начал генерировать сотни строк за секунды. Команда, которая измеряет продуктивность через lines of code, увидит рост на графиках и решит, что AI работает. Но данные Faros AI показывают другую картину: разработчики на командах с высоким AI-adoption завершают на 21% больше задач и мержат на 98% больше pull requests, при этом среднее время ревью вырастает на 91%, а размер PR увеличивается на 154%.

Больше кода. Больше pull requests. Больше времени на ревью. Такой же delivery velocity на выходе. Faros AI назвали это «парадоксом AI-продуктивности»: AI-ассистенты увеличивают output разработчика, но не увеличивают output компании. Бутылочное горлышко смещается от написания кода к ревью и релизу.

Опросы «стали ли вы продуктивнее» тоже не работают. Исследование METR показало разрыв в 39 процентных пунктов между субъективной оценкой и объективным измерением. Разработчики верили, что AI ускорил их на 20%, а реальное измерение зафиксировало замедление на 19%. Ощущение продуктивности и продуктивность — разные вещи.

Фреймворки: что предлагают эксперты

DORA в эпоху AI

Четыре метрики DORA (deployment frequency, lead time for changes, mean time to restore, change failure rate) по-прежнему измеряют то, что важно: скорость доставки и стабильность. Но Forsgren предупреждает, что AI меняет интерпретацию. Lead time может сократиться, потому что AI генерирует код быстрее, но change failure rate может вырасти, потому что разработчики ревьюят AI-код менее внимательно.

Команды, которые используют DORA, могут добавить сегментацию: сравнивать метрики для AI-assisted коммитов и human-only коммитов. Если deployment frequency растёт, а change failure rate остаётся стабильным — AI даёт реальную пользу.

SPACE и DevEx Framework

SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) от Forsgren и коллег включает субъективные и объективные компоненты. Для AI-эпохи критически важно не полагаться на один тип метрик. Satisfaction покажет, что разработчикам нравится AI. Activity покажет, что они генерируют больше кода. Но Performance покажет, изменился ли бизнес-результат.

DevEx Framework (Noda, Storey, Forsgren, Michaela Greiler, 2023) фокусируется на трёх измерениях: feedback loops, cognitive load, состояние потока. AI влияет на все три. Ускоряет feedback loops, когда подсказывает код в реальном времени. Увеличивает cognitive load, когда разработчик тратит ментальную энергию на проверку генераций. Прерывает состояние потока, когда цикл «промпт → генерация → ревью → принятие/отклонение» заменяет непрерывное написание кода.

Acceptance rate как proxy

Acceptance rate — процент AI-генераций, которые разработчик принял без изменений — стал популярной метрикой. GitHub отслеживает acceptance rate для Copilot и публикует данные: в среднем разработчики принимают около 30% предложений. METR зафиксировала 44% у опытных разработчиков.

Acceptance rate полезен как сигнал, но не как целевая метрика. Высокий acceptance rate может означать, что разработчик бездумно принимает всё, что генерирует AI. Низкий может означать, что AI предлагает качественный код, который разработчик дорабатывает перед принятием.

Как измерять на практике

Контролируемые эксперименты

Самый надёжный метод — A/B-тестирование на уровне команд или задач. Разработчики случайным образом получают задачи с AI или без AI, как в исследовании METR. Проблема: это дорого, сложно организовать и создаёт трение у разработчиков, которых просят отказаться от привычных инструментов.

Практичная альтернатива — within-subject design: один и тот же разработчик выполняет часть задач с AI, часть без. METR использовала именно этот подход.

Телеметрия на уровне организации

Faros AI и похожие платформы собирают данные с GitHub, Jira, CI/CD и строят картину: как меняются cycle time, PR throughput, review time, deployment frequency после внедрения AI. Преимущество — масштаб и объективность. Недостаток — корреляция, а не каузальность. Если команда внедрила AI и одновременно перестроила CI, непонятно, что дало эффект.

Комбинированный подход

Forsgren рекомендует сочетать три источника данных.

Первый: системная телеметрия (DORA-метрики, cycle time, PR-данные). Показывает, что происходит с delivery pipeline.

Второй: данные инструментов (acceptance rate, количество генераций, процент AI-кода в production). Показывает, как разработчики используют AI.

Третий: опросы по DevEx Framework (feedback loops, cognitive load, состояние потока). Показывает, как разработчики ощущают изменения. Но эти данные нужно читать с поправкой на bias, обнаруженный в METR.