Как измерять продуктивность AI в разработке

Не строками кода.

Не количеством коммитов.

И точно не количеством промптов.

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

Я бы смотрел на другие метрики:

— Review Time — сколько времени уходит на проверку AI-кода. Если код генерируется за минуту, а ревью занимает два часа, ускорения не произошло.

— Revert Rate — как часто изменения приходится откатывать. Быстро написанный код, который ломает прод, — это не продуктивность.

— Lead Time — сколько проходит от постановки задачи до доставки результата пользователю.

— Throughput — сколько завершённых изменений команда действительно выпускает за период, а не сколько начинает.

— Change Failure Rate — какая доля изменений приводит к инцидентам, откатам или срочным исправлениям.

— Количество ручных исправлений — сколько работы остаётся разработчику после генерации: переписать логику, добавить проверки, исправить архитектуру.

— Процент принятого AI-кода — какая часть предложений доходит до итогового изменения без существенной переработки.

Но важное ограничение: эти метрики нельзя превращать в рейтинг разработчиков или соревнование между командами.

Иначе AI начнут использовать не там, где он полезен, а там, где проще улучшить цифру.

Главный вопрос не в том, сколько кода написал AI.

Главный вопрос — помог ли он быстрее доставить качественное изменение без роста риска и скрытой ручной работы.

Не всякую задачу, которую может сделать AI, стоит ему отдавать

Когда обсуждают AI в разработке, разговор быстро превращается в список:

— пишет код; 
— генерирует тесты; 
— делает документацию; 
— анализирует логи.

Но «AI это умеет» — слабый критерий для делегирования.

Я бы оценивал задачу по четырём параметрам.

1. Повторяемость

Задача регулярно возникает и каждый раз решается примерно одинаково? Чем больше рутины, тем больше смысла в автоматизации.

2. Формализуемость

Можно ли чётко описать входные данные, ограничения и ожидаемый результат? Если постановка звучит как «посмотри и предложи что-нибудь нормальное», AI придётся додумывать контекст.

3. Проверяемость результата

Можно ли быстро и объективно понять, что ответ правильный? Компиляция, тесты, линтер или сверка со схемой снижают риск. «Архитектура выглядит разумно» — уже не проверка.

4. Цена ошибки

Что произойдёт, если AI ошибётся? Придётся поправить черновик документации или восстанавливать production?

Хорошие первые кандидаты:

— boilerplate-код; 
— заготовки тестов; 
— документация; 
— типовые миграции с проверкой; 
— первичный анализ логов.

Плохие кандидаты:

— архитектурные решения при неясных требованиях; 
— критические миграции без rollback; 
— самостоятельные действия с production-данными; 
— изменения, ошибку в которых сложно заметить сразу.

Получается простое правило: чем выше повторяемость, формализуемость и проверяемость, а цена ошибки ниже, тем больше работы можно отдать AI.

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

Генерация миграции и выполнение этой миграции в production — две совершенно разные задачи. И границу между ними лучше проводить до первого инцидента.

AI сэкономил разработчику десять часов. Почему команда не стала быстрее

Представим, что с AI разработчик пишет код в два раза быстрее.

Логично ожидать, что фичи тоже начнут выходить в два раза быстрее.

Но delivery почти не изменился.

Причина простая: написание кода занимает лишь часть пути от задачи до продакшена.

До AI:

- код — 20%
- ревью — 20%
- ожидание — 40%
- релиз — 20%

После внедрения AI:

- код — 8%
- ревью — 25%
- ожидание — 47%
- релиз — 20%

Это условный пример, но он хорошо показывает механику.

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

Более того, если кода стало больше, нагрузка на ревью и тестирование может вырасти.

Именно поэтому локальная экономия десяти часов не превращается в десять часов для всей команды.

Исследования DORA предлагают смотреть не на скорость написания кода, а на весь поток: lead time, частоту поставки, стабильность изменений и время восстановления.

Atlassian приходит к похожему выводу со стороны developer experience: значительная часть рабочего времени теряется из-за организационных препятствий, переключения контекста и неэффективных процессов.

AI редко устраняет бутылочное горлышко.

Чаще он просто переносит его из написания кода в ревью, тестирование или ожидание.

Поэтому после внедрения AI полезно спрашивать не «насколько быстрее мы пишем код?», а:

насколько быстрее изменение доходит до пользователя?