Пересчёт эксперимента METR: на сложных задачах и ревью разработчики с ИИ теряют 24% часов

В 2025 году независимый исследовательский центр METR замерил работу 16 опытных разработчиков открытого ПО на 246 реальных задачах из их собственных репозиториев: с ИИ-ассистентами типичный тикет закрывали на 19% медленнее, чем вручную. Независимый исследователь Соломон Шалом Лиджо в статье «Counting the Bandages: On measuring the time that AI saves» (опубликована на arXiv 23 октября 2026 года) пересчитал по открытым логам METR суммарный расход часов команды. С учётом затяжных пробуксовок на сложных задачах разработчики с ИИ потеряли уже 24% рабочего времени (а без поправки на исходный размер задач — 34%), причём исправление замечаний после код-ревью занимало в среднем 14,9 минуты на тикет против 9,7 минуты без нейросети.

Следом автор разобрал бенчмарк OpenAI GDPval и на 540 сессиях Claude Code показал, почему выключать секундомер в момент сдачи черновика бессмысленно: выигранные на генерации минуты оборачиваются пропущенными багами и часами переделок.

Откуда в одних и тех же логах взялись 19%, 24% и 34%

Лиджо воспроизвёл расчёты по публичному репозиторию METR и показал, что одни и те же 246 закрытых задач дают три разные цифры — смотря как считать командное время:

• Плюс 19% времени даёт среднее геометрическое по логарифмам, которое авторы METR вынесли в свой заголовок. Оно отражает типичный сдвиг по одной отдельной задаче.
• Плюс 24% времени выходит, если поделить все реально потраченные часы с ИИ на часы без ИИ. С нейросетью разброс по времени заметно шире: когда программист увязает в неудачных итерациях промптинга на крупном тикете, такие многочасовые хвосты съедают общий фонд времени сильнее, чем видно по логарифмическому среднему.
• Плюс 34% времени показывают сырые часы без поправки на стартовый перекос выборки. При жеребьёвке в корзину с ИИ случайно попали более крупные тикеты: до начала работы сами программисты оценивали их в среднем в 116 минут против 106 минут в контрольной группе.
• Правки после код-ревью замерили на 230 тикетах из 246: доработка возвращённого ревьюером кода с ИИ требовала 14,9 минуты против 9,7 минуты вручную. При этом статистические границы Макарова по тем же данным оставляют широкий коридор: ИИ реально ускорил работу где-то на участке от 2,6% до 82,1% отдельных задач. Одно среднее число скрывает, на каких тикетах инструмент экономит часы, а на каких топит.

Почему стократное ускорение GPT-5 сжимается до 1,1–3,6 раза

Инженер Фрэнк Гилбрет сто лет назад пробовал бриться двумя бритвами сразу: экономил 44 секунды у зеркала, но тратил две минуты, заклеивая порезы пластырем. Ту же ошибку повторяют современные ИИ-бенчмарки, когда выкидывают из замера проверку результата.

Яркий пример — прикладной тест GDPval от OpenAI. В анонсе компания заявляла, что флагманские модели решают задачи отраслевых специалистов примерно в 100 раз быстрее и дешевле: GPT-5 генерирует ответ за 4,5 минуты против 404 минут ручного труда эксперта. Но внутри самой научной статьи GDPval заложен рабочий контур с обязательной приёмкой каждого ответа:

• чтение и проверка одного черновика живым специалистом занимают 109 минут (27% от полного времени ручной работы);
• по закону Амдала даже при безошибочной модели ускорение всего процесса упирается в потолок `404 / (4,5 + 109) = 3,56x`, то есть максимум в 3,6 раза;
• ответы GPT-5 обходили экспертные лишь в 39% заданий, поэтому с учётом переделки слабых черновиков авторы самой статьи GDPval оценивают реальное ускорение всего в 1,12–1,39 раза.

Та же развилка видна в полевом эксперименте с бизнес-консультантами (Dell'Acqua et al., 2026) на задачах за пределами надёжной зоны модели. С GPT-4 участники сдавали решение за 26,2 минуты вместо 37,7 минуты у контрольной группы, зато доля верных ответов падала с 84,5% до 60,0%. По формуле порога безубыточности дефекта, которую вводит Лиджо, выигранные 11,5 минуты окупаются только в том случае, если отлов и исправление ушедшей клиенту ошибки стоят дешевле 47 минут работы консультанта.

Опыт на 540 сессиях

Claude Code: как завышенное доверие отключает проверку

Чтобы измерить на практике, как репутация автора черновика влияет на глубину ревью, Лиджо запустил серию контролируемых тестов на ИИ-агентах. В основу легли квартальные финансовые отчёты американских компаний по форме 10-Q из базы Комиссии по ценным бумагам США (SEC) за период до 30 июня 2026 года. Отчёты вышли после 1 июля 2026-го — позже среза обучения моделей, поэтому вспомнить числа из весов нейросеть не могла.

Агент-автор (`claude-haiku-5-5`) собирал сводку из 9 показателей (выручка, чистая прибыль и операционная маржа по трём компаниям), куда в 30% случаев специально подмешивали одну ошибку: чужую строку, старый квартал или переставленные цифры. Следом документ проверял агент-ревьюер (`claude-sonnet-5-5` в изолированной сессии Claude Code), у которого был инструмент построчной сверки с первоисточником SEC. По условиям промпта проверка одного числа стоила 3 минуты (все 9 строк — 27 минут), а пропущенная к клиенту ошибка штрафовалась на 10 часов (600 минут). Сплошная сверка окупалась при доле брака выше 4,5%.

Эксперимент выявил три конкретных эффекта:

• Режим «всё или ничего». Когда ревьюеру честно называли высокую долю брака (от 10% до 30%), во всех 40 парных тестах он сверял все 9 строк и исправлял 100% ошибок. Но плавной выборочной проверки не было: около порога 4,5% модель резко переключалась между полной сверкой и нулём запросов к источнику.
• Слепота при заниженной оценке брака. На тех же черновиках с реальными 30% ошибок ревьюеру сказали в промпте, будто автор ошибается вдесятеро реже (в 3% случаев). В 29 из 40 сессий `Sonnet 5.5` вообще не открыл исходный отчёт, проверив в среднем лишь 2 числа из 9. На вычитке сэкономили 21 минуту, но фальшивая цифра ушла в отчёт клиенту в 22,5% сводок вместо нуля — чистый убыток составил 135 минут на документ.
• Бесполезность оговорок в промпте. В отдельной ветке к цифре «3% брака» добавили прямое требование считать эту оценку непроверенной. В 26 из 40 запусков модель соглашалась в рассуждениях, что цифре верить нельзя, и всё равно сдавала сводку без единой сверки. Числовой якорь перевесил текстовое предупреждение.

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

Вместо одиночного таймера «до первого коммита» автор предлагает считать при внедрении ИИ-инструментов три показателя (код и сырые логи открыты на GitHub в репозитории `tsb-bench` и на Zenodo):

1. Сколько всего часов команда тратит на задачу целиком, включая код-ревью и доработку возвращённых PR. 2. Сколько лишних ошибок пропускают в готовый результат — по итогам слепой приёмки в группах с ИИ и без него. 3. При какой цене бага ускорение перестаёт окупаться, и когда можно отключать ручной контроль: чтобы с уверенностью 95% убрать обязательное ревью при допустимом браке 0,85%, инструмент должен сначала сдать 352 проверенные задачи подряд без единого провала.