Продуктивность ИИ в программировании требует DORA и METR

Продуктивность ИИ в программировании нельзя оценивать, выбирая победителя между DORA и METR. DORA показывает малому или среднему бизнесу, способна ли его система поставки доводить полезные изменения до продакшена без дополнительного ущерба. METR проверяет более узкий причинный вопрос: изменил ли доступ к конкретным инструментам ИИ время, которое опытные разработчики тратили на поставленные задачи в уже знакомых репозиториях? Покупателю нужны оба взгляда, потому что выигрыш во времени на задаче может исчезнуть на ревью, тестировании, выпуске или исправлениях.

Для зрелой кодовой базы я бы выбрал время до приемки задачи как локальный результат, а метрики DORA как системные ограничения. Я бы также измерял повторную работу, усилия ревьюера и дефекты, ушедшие в продакшен. Такое сочетание ловит две дорогие ошибки, которые я вижу в экспериментах с ИИ: отказ от полезного инструмента из-за почти незаметного изменения широкой метрики поставки и покупку инструмента из-за ощущения высокой скорости у разработчиков, пока все издержки достаются следующим этапам.

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

DORA измеряет, как приложение или сервис поставляет изменения. Текущая модель объединяет пять показателей в скорость потока и нестабильность: время от коммита до развертывания, частоту развертываний, время восстановления после неудачного развертывания, долю неудачных изменений и долю повторных развертываний. Это результаты работы всей системы поставки. На них влияют продуктовые решения, готовность задач, архитектура, доступность ревьюеров, скорость тестов, правила выпуска и эксплуатация, а не только набор или генерация кода.

Именно поэтому данные DORA важны владельцу бизнеса. Расходы на команду превращаются в пользу для бизнеса, только когда безопасное изменение доходит до пользователя. Если ИИ сокращает время реализации, но увеличивает очереди на ревью, размер изменений, число экстренных исправлений или объем восстановительных работ, компания не получила полезной мощности. DORA обнаруживает такой перенос усилий, даже если редактор кода сообщает о тысячах принятых подсказок.

Широкий охват также ограничивает выводы DORA. Ежегодное исследование использует большой массив опросных данных и статистические модели, чтобы изучить связи между практиками, внедрением ИИ, опытом разработчиков, поставкой и результатами организации. Открытые вопросы опроса 2025 года показывают, что многие входные данные участники сообщают сами о своем основном приложении или сервисе. Такой дизайн описывает закономерности во множестве сред, но не распределяет ИИ случайным образом между одной командой и контрольной группой. Связь между внедрением и скоростью потока не дает причинной оценки для вашей биллинговой системы, которой двенадцать лет.

Год выпуска отчета имеет значение. Анализ Accelerate State of DevOps за 2024 год связал более широкое внедрение ИИ со снижением скорости и стабильности поставки. В частности, рост внедрения на 25% соответствовал расчетному падению скорости потока на 1,5% и стабильности на 7,2%. Отчет State of AI-assisted Software Development за 2025 год связал более широкое внедрение с ростом скорости потока и одновременно нестабильности, а ИИ описал как усилитель окружающей системы. Если цитировать одну цифру без года отчета, модели и результата, получится уверенный, но бесполезный аргумент для покупки.

Сама DORA предупреждает, что нельзя превращать метрику в цель или сравнивать разные приложения. Следуйте этому совету. Сравнивайте один сервис с его собственной историей. Платежный API, который выпускают под регуляторным контролем, не должен соревноваться с маркетинговым сайтом по частоте развертываний. Полезный вопрос звучит иначе: стал ли тот же сервис поставляться лучше после вмешательства при прежней или более высокой стабильности?

METR изолирует время задачи в знакомых репозиториях

METR измеряет, меняет ли доступ к ИИ прошедшее время до выполнения задачи в контролируемых условиях. В рандомизированном эксперименте начала 2025 года 16 опытных разработчиков проектов с открытым исходным кодом выполнили 246 реальных задач в зрелых проектах, которые хорошо знали. В среднем у них было около пяти лет опыта работы с соответствующим репозиторием. Исследователи описывали задачи до случайного распределения, в одном условии разрешали инструменты ИИ начала 2025 года, в другом запрещали их, а работу проверяли по записям экрана и данным репозитория.

Такой дизайн отвечает на вопрос, на который DORA ответить не может: привел ли доступ к инструменту у этого участника и на этом наборе задач к более быстрому завершению работы? Ответ удивил почти всех. По оценке METR, доступ к ИИ замедлил завершение на 19%, а опубликованный интервал составлял от 2% до 39% замедления. До работы разработчики ожидали ускорения на 24%. После эксперимента они по-прежнему считали, что работали на 20% быстрее. Малому и среднему бизнесу стоит запомнить именно расхождение между измеренным временем и ощущением скорости.

Результат убедителен для условий эксперимента, но не доказывает постоянный штраф за ИИ в программировании. Участники знали свои репозитории необычно хорошо. Средняя задача занимала около двух часов. Они работали с инструментами и моделями, доступными с февраля по июнь 2025 года, в основном Cursor Pro с Claude 3.5 или 3.7 Sonnet. Современный агент, который выполняет ограниченную миграцию в закрытом сервисе, это другое вмешательство. Младший разработчик, изучающий незнакомый модуль, это другая группа.

В обновлении за февраль 2026 года METR обозначила это ограничение еще яснее. В более позднем эксперименте возникло смещение отбора: разработчики, высоко ценившие ИИ, часто не хотели отправлять работу, которую могли назначить в условие без ИИ. Параллельные агенты также усложнили учет времени задачи. METR признала новые данные ненадежным сигналом, хотя отзывы участников указывали, что современные инструменты, вероятно, помогают больше, чем инструменты начала 2025 года. Это хороший научный подход: исследователи ослабили собственное утверждение, когда дизайн перестал его поддерживать.

Не превращайте ранний эксперимент в лозунг о том, что ИИ замедляет хороших инженеров. Воспринимайте его как предупреждение о локальном измерении. Опытные разработчики могут ошибаться в оценке собственной скорости, зрелые репозитории требуют дорогого погружения в контекст, а аккуратный тест может описывать неподходящий набор задач.

Исследования отвечают на разные вопросы руководителя

DORA и METR находятся на разных уровнях одной цепочки создания ценности. Если считать их соперничающими табло, смешиваются причинность, охват и время.

1. DORA наблюдает за поставкой приложения или сервиса. METR наблюдает за разработчиком, который выполняет заранее определенную задачу. Ваш эксперимент должен наблюдать за принятым изменением внутри одного сервиса.
2. Основные результаты DORA, это скорость потока и нестабильность. Результат METR, время выполнения задачи. Вашему эксперименту нужны активное инженерное время и ограничения по поставке.
3. DORA показывает, как практики и результаты меняются вместе в разных организациях. METR оценивает причинную разницу во времени для изученной выборки. Ваш эксперимент может обосновать ограниченное утверждение об одном процессе, одной команде и одном периоде.
4. DORA не может изолировать время набора кода или доказать локальный причинный эффект. METR не может измерить всю производственную систему или навсегда описать современные инструменты. У вашего эксперимента будет маленькая выборка, а само наблюдение изменит поведение людей.
5. Используйте DORA, чтобы находить перенесенные издержки и ущерб эксплуатации. Используйте METR, чтобы честно построить сравнение и не доверять одному ощущению скорости. По локальному результату решайте, где расширять, менять или останавливать применение ИИ.

Таймер задачи работает как микроскоп. Метрики поставки похожи на жизненные показатели организма. Микроскоп видит локальное изменение, слишком мелкое для общих показателей. Общие показатели обнаруживают вред, который локальное улучшение принесло большой системе. Один инструмент не заменяет другой.

Это различие снимает кажущееся противоречие. ИИ может сократить активное время реализации, но частота развертываний останется прежней, потому что ограничением служит согласование выпуска. Частота развертываний может вырасти вместе с долей неудачных изменений, если команда выпускает более крупные порции работы. ИИ может замедлить эксперта по репозиторию на тонкой задаче сопровождения и одновременно помочь другому инженеру написать тесты в незнакомом модуле. Одно среднее значение не описывает все четыре эффекта.

Для малого и среднего бизнеса вопрос не в том, какой источник авторитетнее, DORA или METR. Определите, какое звено цепочки ценности способен проверить каждый показатель. Данные по задачам оценивают непосредственную экономию труда. Данные по поставке проверяют, дошла ли сэкономленная мощность до продакшена без потерь.

Зрелая кодовая база меняет ожидаемую отдачу

В зрелой кодовой базе контекст важнее синтаксиса. Самая трудная часть обычно скрыта в недокументированных инвариантах, старых путях миграции, неожиданных местах вызова, производственных данных и причинах, по которым некрасивое условие все еще остается в коде. Опытный специалист может печатать медленно и принимать правильные решения. Инструмент ИИ способен быстро создать правдоподобное изменение и заставить этого специалиста доказывать ошибочность каждой предпосылки.

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

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

• Локальная работа с понятным образцом, например добавление одного валидатора рядом с похожими валидаторами.
• Исследование репозитория, где инженер должен найти поведение и объяснить зависимости до редактирования.
• Изменения в нескольких модулях, которые затрагивают контракты, миграции, разрешения или обратную совместимость.
• Проверочная работа, включая тесты, ревью, исправление инцидентов и подготовку выпуска.

Ожидайте разных ответов. ИИ может хорошо справляться с повторяющейся локальной работой и заготовками тестов, не давать выигрыша в исследовании и проигрывать на небольшом изменении со скрытым инвариантом. Это не противоречие. Именно такой результат нужен, чтобы разумно направлять разные виды работы.

Готовность репозитория также меняет вмешательство. Понятные команды сборки, быстрые тесты, доступные для поиска решения, типизированные интерфейсы и небольшие модули дают агенту полезную обратную связь. Нестабильный интеграционный набор и знания только в головах делают проверку каждого созданного изменения дорогой. Утверждение DORA 2025 года об усилителе соответствует этому механизму: ИИ усиливает систему, в которую попадает. На практике нужно фиксировать условия готовности, а не объяснять любой провал плохим инструментом.

Я сразу не доверял бы результату команды, которая посреди эксперимента меняет репозиторий, инструкции агента, модель и правила ревью, а затем публикует одно среднее. Обучение работе с инструментом существует, но неконтролируемые изменения разрушают сравнение. Фиксируйте каждую версию вмешательства. Анализируйте стабильные периоды отдельно.

Строки кода и число задач введут в заблуждение

Строки кода, принятые подсказки, отправленные запросы, коммиты, пул-реквесты и закрытые задачи показывают активность. Их дешево собирать и легко увеличить без дополнительной пользы. Поэтому их популярность опасна для решения о расходах на команду.

ИИ часто меняет форму работы. Он способен создавать более многословный код, делить работу на лишние коммиты, добавлять малополезные тесты или превращать одну задачу в несколько. Команда может увеличить каждый показатель активности, потратить больше времени ревьюеров и поставить тот же результат для клиента. METR описывала задачи до случайного распределения в том числе для защиты от этой двусмысленности: объем результата меняется без изменения объема необходимой работы.

Story points еще хуже подходят для сравнения условий. Команды оценивают их, пересматривают и осваивают внутреннюю шкалу. Если разработчики знают, что руководство ждет роста продуктивности, шкала сдвигается. Оставьте баллы только как грубое поле для распределения задач, но никогда не ставьте их в числитель расчета отдачи от ИИ.

Платить имеет смысл за принятое изменение, которое выполняет исходные условия и остается исправным после выпуска. Считайте задачу выполненной, когда согласованные проверки прошли, ревьюер ее принял, а нужная эксплуатационная работа и документация готовы. Повторно открытая работа возвращается в ту же запись задачи. Последующее исправление, вызванное этим изменением, это повторная работа, а не новый результат.

Не превращайте измерение в слежку. Запись экрана подходила для согласованного исследования с оплачиваемыми участниками и определенным протоколом. Работодателю обычно нужны временные метки событий, классы задач, условие применения инструмента, трудозатраты на ревью и результаты. Собирайте только необходимое, опубликуйте правила до эксперимента и никогда не ранжируйте отдельных разработчиков. Люди, которые ждут персонального табло, начнут улучшать журнал, а не программу.

Субъективная продуктивность все же нужна в данных, но как отдельный показатель. Раз в неделю задавайте короткий вопрос о концентрации, раздражении и пользе инструмента. Расхождение между ощущением и измеренным временем может показать цену обучения или скрытую работу ревьюеров. Оно не заменяет часы.

Изменение разрешений показывает, почему это важно. Представим, что агент находит промежуточный слой авторизации, добавляет проверку роли, пишет модульные тесты и за сорок минут открывает аккуратный пул-реквест. В стандартном процессе другой инженер потратил на похожую задачу девяносто минут. Таймер объявляет большой выигрыш. На ревью специалист вспоминает, что старые арендаторы могут наследовать роли через таблицу миграций, которую модульные тесты не загружают. Изменение ИИ требует второй реализации, фикстуры данных и еще одного круга ревью. Если эти минуты попадут в новую задачу или только в календарь ревьюера, эксперимент по-прежнему запишет первой задаче результат в сорок минут.

Ошибка началась не с плохой арифметики, а со слабого определения завершения. Принятый результат должен учитывать путь наследования роли, нужную регрессионную фикстуру и одобрение ревьюера. Запись должна прикреплять отклоненную попытку и второй проход к той же задаче. При таком определении эксперимент все еще может найти выигрыш, но он измерит работу, которая действительно требовалась компании.

Рассмотрим обратный случай. Инженер просит агента найти все места вызова старой функции расчета цены и подготовить план изменения до редактирования кода. Реализация ускоряется только на десять минут, зато ревью сокращается на час, потому что план заранее выявляет двух скрытых потребителей. Метрика генерации кода не замечает пользу, а время до приемки задачи ее учитывает. Поэтому число запросов и токенов плохо подходит в качестве результата. Процесс включает исследование, планирование, реализацию и доказательство. Измеряйте границу вокруг всех этих этапов.

Проведите контролируемое перекрестное сравнение без остановки команды

Шестинедельное перекрестное сравнение даст полезный ответ для малого или среднего бизнеса, если у команды есть базовый период, достаточно повторяющихся типов задач и честные правила завершения. Университетская лаборатория не нужна. Но метод анализа нужно выбрать до просмотра результата.

1. Потратьте две недели на проверку телеметрии и определение классов задач, завершения, повторной работы, активного времени и исключений. По существующей истории рассчитайте базовые метрики DORA для одного сервиса.
2. Выберите один процесс работы с ИИ и зафиксируйте модель, инструкции репозитория, разрешения и правила ревью на весь период сравнения. До начала измерения обучите участников в оплаченное рабочее время.
3. Заранее классифицируйте подходящие задачи по риску, типу и примерному размеру. Случайно назначайте условие с разрешенным ИИ или стандартный процесс внутри каждого класса. Исключите инциденты, чувствительную работу и случаи, где запрет инструмента создает неприемлемый риск.
4. Проведите два блока измерения по две недели. Меняйте условия для участвующих инженеров, чтобы различия в знании репозитория не превратились в эффект инструмента.
5. Вместе анализируйте принятые задачи, брошенные задачи, повторную работу, минуты ревьюеров и результаты поставки. Не смешивайте результат на уровне задачи с результатом на уровне сервиса.

Случайное распределение должно происходить после описания задачи и до начала реализации. Если разработчики выбирают условие сами, они естественным образом отправят шаблонную работу ИИ, а тонкие ошибки оставят себе. Такое сравнение измеряет отбор задач, а не влияние инструмента. Проблема набора участников в позднем эксперименте METR показывает обратную сторону: когда люди сильно предпочитают ИИ, принудительное условие без него меняет состав задач и разработчиков в исследовании. Фиксируйте отказы и исключенные задачи, потому что отсутствие тоже дает информацию.

Парное сравнение уменьшает шум. Если есть две похожие задачи миграции, поместите их в разные условия. Если обе выполняет один инженер, меняйте порядок, чтобы уменьшить эффект обучения. Не запускайте вариант с ИИ вторым каждый раз: знания, полученные в первой задаче, сделают вторую искусственно быстрее.

Основным показателем задачи должны быть активные инженерные минуты на принятую задачу, а не только прошедшее календарное время. Отдельно учитывайте ожидание CI, ревью или другой команды, потому что ИИ может перенести ограничение, а не убрать его. Показывайте медианы и полный диапазон по каждому классу задач. Одно общее среднее может зависеть от единственного инцидента или пачки мелких изменений.

Установите пороги решения до пилота. Например, расширяйте применение, только если медианное активное время снижается хотя бы на 15% в двух подходящих классах задач, время ревьюера растет не более чем на 10%, а показатели стабильности DORA заметно не ухудшаются. Эти числа, это ваши рабочие решения, а не универсальные результаты исследований. Выберите значения, которые покрывают цену лицензии, обучение и стоимость организационных изменений.

Собирайте доказательства по задачам, способные выдержать спор

Небольшой записи событий достаточно для разбора большинства разногласий. Храните одну запись на задачу в версионируемых данных эксперимента или во внутренней аналитической таблице. Не сохраняйте запросы и созданный код, если отдельная проверка безопасности этого не разрешила.

{"task_id":"BILL-1842","service":"billing-api","class":"cross_module","condition":"ai_allowed","engineer":"anon-07","started_at":"2026-08-03T09:12:00Z","active_minutes":138,"ci_wait_minutes":24,"review_minutes":41,"completed_at":"2026-08-04T14:20:00Z","accepted":true,"rework_14d_minutes":35,"escaped_defect":false,"treatment":"agent-v1"}

Такая структура предотвращает три знакомых спора. Поля condition и treatment доказывают, что именно тестировали. Раздельное активное время, ожидание CI и время ревью показывают перенос усилий. Поле повторной работы за четырнадцать дней не дает поспешному изменению выглядеть дешевым только потому, что исправление попало в другой спринт.

Создайте карточку задачи до назначения условия. Укажите ожидаемое поведение, значимые ограничения, обязательные проверки и критерий готовности. Не задавайте способ реализации, иначе вы уберете часть работы, с которой должен помогать инструмент. По возможности приемку должен проводить ревьюер, который не знает назначенного условия. Полностью скрыть его трудно, когда стиль сгенерированного кода заметен, но отсутствие ярлыка все равно уменьшает влияние ожиданий.

Используйте еженедельную сводку, понятную основателю:

class          condition       accepted  median_active  median_review  rework_14d
local_pattern  standard        11        74m            18m            9%
local_pattern  ai_allowed      12        48m            21m            8%
cross_module   standard         7       166m            39m           14%
cross_module   ai_allowed       6       181m            57m           27%

Пример не объявляет ИИ хорошим или плохим. Он предлагает направить локальную работу по образцу в проверенный процесс, а задачи с несколькими модулями пока не отдавать ему, пока не улучшатся инструкции, контекст или проверка. Это полезнее заявления о росте продуктивности всей компании на 23%.

Разбирайте брошенные и ограниченные наблюдения. Если разработчик прекращает неудачную попытку с ИИ и завершает работу вручную, оставьте время ИИ в задаче. Если пилот исключает самую сложную работу, покажите долю исключений. Иначе узкий успех превратится в завышенный прогноз мощности.

Оставьте DORA ограничителем безопасности продакшена

Выигрыш на задачах учитывается, только пока сервис остается безопасным и пригодным к поставке. Получайте показатели DORA из систем развертывания и учета инцидентов для одного и того же приложения до, во время и после эксперимента. Во всех периодах применяйте одинаковые определения.

Время выполнения изменения должно начинаться с коммита и завершаться развертыванием в продакшене. Частота развертываний считает успешные развертывания сервиса в продакшен. Время восстановления после неудачного развертывания охватывает период, необходимый для восстановления после выпуска, потребовавшего немедленного вмешательства. Доля неудачных изменений показывает часть развертываний с таким вмешательством. Доля повторных развертываний показывает часть незапланированных выпусков для устранения производственного инцидента. Если текущая панель использует старые названия или определения, опишите соответствие, а не переименовывайте график молча.

Читайте пять показателей вместе. Меньшее время задачи при большем времени выполнения изменения указывает на очередь на следующем этапе. Рост числа развертываний вместе с долей неудачных изменений означает, что команда купила скорость за счет надежности. Стабильная поставка при меньшем времени задачи может быть настоящим локальным выигрышем, даже если частота развертываний не способна вырасти из-за продуктового согласования.

Для эксплуатации используйте недельные скользящие значения, но решение о покупке принимайте на интервале, где успевают проявиться повторная работа и инциденты. Зрелый сервис с редкими выпусками может не дать достаточно развертываний для устойчивого процента за шесть недель. Не создавайте ложную точность. Покажите количество событий, продолжайте следить за ограничениями после завершения эксперимента по задачам и разрешите только ограниченное расширение.

Держите размер порции изменений рядом с набором DORA. Это не один из пяти текущих показателей эффективности, но анализ ИИ от DORA называет крупные изменения возможным путем от быстрой генерации к нестабильности. Учитывайте измененные файлы или удобный для ревью размер изменения как диагностический показатель, а не цель. Если размер растет, сначала сузьте границы задачи и лишь затем обвиняйте модель.

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

Принимайте решение по двум осям

Решение о покупке требует двух осей: локальной экономики задач и здоровья системы поставки. Расширяйте применение только при приемлемом результате по обеим осям. Так вы не требуете от каждого инструмента движения каждой метрики и не позволяете локальному ускорению скрыть эксплуатационные затраты.

1. Расширяйте те классы задач, которые выполняются быстрее при таком же или меньшем времени ревью и объеме повторной работы, пока ограничения DORA стабильны или улучшаются.
2. Если задачи выполняются быстрее, но ревью или стабильность ухудшаются, исправьте размер порции, тесты, инструкции или разрешения, затем повторите эксперимент.
3. Если время задачи не улучшилось, а DORA остается стабильной, остановите этот класс задач, если обучение или качество не дают отдельно измеряемой пользы.
4. Если задачи выполняются медленнее, но качество растет или эксплуатационная нагрузка падает, оцените стоимость предотвращенных проблем до решения.
5. Если задачи выполняются медленнее, а поставка ухудшается или не меняется, остановите процесс и сохраните доказательства.

Переводите принятое сэкономленное время в деньги только после успешной проверки по этой схеме. Используйте полную стоимость инженерного часа, а не одну зарплату. Вычитайте стоимость лицензии, время обучения, дополнительное ревью, повторную работу и поддержку инструкций агента и интеграций. Не превращайте каждый сэкономленный час в экономию фонда оплаты труда, если спрос не поглощает освободившуюся мощность или штат в действительности не меняется.

Практичная формула выглядит так:

monthly_net_value = accepted_hours_saved * loaded_hourly_cost
                  - tool_cost
                  - training_and_admin_cost
                  - added_review_and_rework_cost

Рассчитайте низкий, ожидаемый и высокий сценарии, потому что маленький эксперимент дает широкую неопределенность. Сохраняйте результат по классу задач. Выигрыш 25% на работе, занимающей 10% месяца, дает 2,5% валового прироста мощности до учета затрат, а не трансформацию всей команды на 25%.

Основатели часто просят один вердикт, потому что им нужен ответ по бюджету. Дайте его, но обозначьте границы: расширить, пересобрать или остановить названные процессы в одном сервисе. Team & AI Audit от oleg.is может подготовить такой базовый уровень и найти экономию до широкой трансформации, но доказательства должны оставаться понятными команде, которой предстоит жить с решением.

DORA задает границу продакшена. METR дает дисциплину измерять время, а не доверять энтузиазму. Только собственное перекрестное сравнение оценивает нынешний инструмент, нынешнюю команду и нынешнюю кодовую базу. Если до эксперимента компания не способна назвать классы задач, правило завершения и ограничения стабильности, ей рано цитировать процент продуктивности.