METR получил оценки экономии времени в 4–18%, но признал замер ненадёжным

Агент написал за минуту код, на который раньше уходило полдня. Отлично — если потом команда не потратила день на проверку и исправления. Именно этот разрыв между скоростью генерации и скоростью готовой работы пыталась измерить METR. Повторный эксперимент дал оценки сокращения времени на 4–18%, однако исследователи сочли результат ненадёжным. Разработчики всё чаще отказывались от участия, если ради него требовалось работать без ИИ.

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

Почему сравнение перекосилось

В повторном исследовании участвовали 57 разработчиков. По условиям эксперимента они заранее описывали задачи, после чего жребий определял, разрешено ли использовать ИИ. Но 30–50% опрошенных участников сообщили, что придерживали некоторые задачи: им не хотелось получить запрет на помощь модели. Одновременно стало труднее набирать людей, готовых работать без неё.

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

У вернувшихся участников оценка сокращения времени составила 18%, у новых — 4%. При этом доверительные интервалы допускают и замедление. Авторы считают возможным занижение пользы из-за отбора, но точного размера эффекта эти данные не устанавливают. Подробности опубликованы в отчёте METR от 24 февраля 2026 года. Ноябрьский пересказ стоит читать с учётом этой даты: перед нами результат более раннего эксперимента.

Отказ работать руками ещё не доказывает ускорение

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

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

Нельзя также переносить результат первой работы METR на любые современные команды. Тогда 16 опытных участников выполняли 246 задач в знакомых проектах, а использование ИИ увеличило время на 19%. Это важное предупреждение о расхождении ощущений и замера, но конкретные инструменты, задачи и опыт участников ограничивают применимость результата. Из него не следует, что каждый агент сегодня тормозит каждого разработчика.

С параллельными агентами появляется отдельная проблема учёта. Пока один меняет код, человек разбирает другой тикет, а второй агент запускает тесты. Прошло сорок минут: сколько отнести к первой задаче? Без заранее выбранного правила команды легко получат красивые, но несопоставимые отчёты. Активное время человека и календарный срок выполнения отвечают на разные вопросы.

Что считать внутри команды

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

Отдельно полезно смотреть, где возникает выигрыш. Агент может сократить написание тестов, но увеличить ревью; ускорить незнакомую задачу, но мешать автору собственного модуля. Если сложить всё в одну среднюю цифру, руководитель потеряет именно ту информацию, которая нужна для выбора инструмента и распределения работы.

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