Как измерять эффект от 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 сокращается, потому что код генерируется быстрее, а 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 полезен как сигнал, но не как целевая метрика. Высокое значение может означать, что разработчик бездумно принимает всё подряд. Низкое — что 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.