Статья на arXiv пересчитала METR: ИИ замедлил разработчиков на 19–24%

Сколько времени на самом деле экономит ИИ-ассистент? Соломон Шалом Лиджо в 18-страничной работе на arXiv (cs.AI, 23 октября 2026) утверждает, что показания секундомера для ответа не годятся. Автор пересчитал данные исследования METR, оценил потолок ускорения GPT-5 в бенчмарке GDPval и поставил собственный эксперимент с ИИ-ревьюерами. На одних и тех же 246 задачах разработчики оказались медленнее на 19% или на 24%, в зависимости от того, что именно считать эффектом. А когда ревьюеру сообщили, что черновик пишет почти безошибочная модель, он стал проверять меньше и пропустил неверную цифру в 22,5% брифов.

Секундомер против бухгалтерской книги

Автор различает две трактовки. В «секундомерной» сэкономленное время равно тому, что зафиксировали часы. В «бухгалтерской» это контрфактическая величина: сколько заняла бы работа без ИИ, и её нужно читать рядом с ошибками, которые работа пропустила. Лиджо защищает вторую.

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

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

Пересчёт METR и потолок GDPval

Лиджо воспроизвёл исследование METR о разработчиках по публичным данным. Результат зависит от выбора оцениваемой величины:

• замедление на 19% или 24% на тех же 246 задачах, в зависимости от estimand;
• замедление на 34%, если не корректировать случайный дисбаланс между группами;
• ИИ помог где-то на 3–82% задач. Столь широкий интервал показывает, что рандомизированное исследование отвечает на вопрос о среднем эффекте и почти ничего не говорит об эффекте на отдельной задаче.

В процессе GDPval, где проверяется каждый результат, одно только время ревью ограничивает ускорение GPT-5 величиной 3,6x. Консультанты, не входившие во фронтир, работали быстрее, но ошибались чаще. Здесь автор вместо импортированных точечных допущений ставит явные границы.

Ревьюеры, которые поверили в автора

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

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

Когда ему сообщали, что автор ошибается в десять раз реже, чем на самом деле, он проверял на 7 из 9 цифр меньше. Неверная цифра проходила в 22,5% брифов, а без этого обмана не проходила ни в одном. Работа становилась быстрее и хуже, причём целиком за счёт снижения усилий.

Что поменять в метриках внедрения

Если вы оцениваете ИИ-ассистента в команде, одной метрики скорости мало. Нужны хотя бы три числа:

• время, сэкономленное относительно контрфактического процесса без ИИ;
• число избыточных пропущенных дефектов на единицу работы;
• цена дефекта в вашем процессе и её сравнение с порогом безубыточности.

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