METR study: почему AI замедляет опытных разработчиков
Рандомизированное контролируемое исследование METR показало, что AI-инструменты замедляют опытных разработчиков на 19%, хотя те уверены в обратном
Первоисточник
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMETR, 2025
В июле 2025 года организация METR опубликовала исследование, которое перевернуло индустриальный нарратив об AI-продуктивности. Рандомизированное контролируемое исследование (RCT) показало: опытные разработчики с AI-инструментами выполняют задачи на 19% медленнее, чем без них. При этом сами разработчики были уверены, что AI ускорил их на 20%. Разрыв между ощущением и реальностью составил 39 процентных пунктов.
Дизайн исследования
METR набрала 16 опытных разработчиков из крупных open-source проектов. Средний размер репозиториев — 22 000+ звёзд на GitHub и более миллиона строк кода. Каждый участник работал над своим собственным проектом, который знал вдоль и поперёк: годы коммитов, глубокое понимание архитектуры.
Разработчики составили списки реальных задач для своих проектов — баг-фиксы, фичи, рефакторинги. Всего 246 задач. Каждую задачу METR случайным образом назначила в одну из двух групп: «с AI» или «без AI». Когда AI разрешён, разработчик использовал любые инструменты на свой выбор (большинство выбрали Cursor Pro с Claude 3.5/3.7 Sonnet). Когда AI запрещён — работал без генеративных инструментов. Средняя задача занимала около двух часов, разработчики записывали экран и сами фиксировали затраченное время. Оплата — $150/час.
Это был не синтетический бенчмарк, где незнакомый разработчик ковыряет чужой код. Участники решали реальные задачи в проектах, которые они же и создали.
Главный результат: 19% замедление
Задачи с разрешённым AI заняли на 19% больше времени. Это статистически значимый результат рандомизированного эксперимента, а не корреляция из опроса.
Но ещё интереснее результаты по восприятию. До начала работы разработчики прогнозировали, что AI сэкономит им 24% времени. После выполнения задач они оценили ускорение в 20%. Разработчики не заметили, что AI их замедлил. Они были искренне уверены, что работали быстрее.
Почему AI замедлил, а не ускорил
Исследователи выделили несколько механизмов.
Низкий acceptance rate. Разработчики приняли менее 44% генераций AI. Больше половины сгенерированного кода они отвергли, но перед этим потратили время на чтение, тестирование и редактирование. Каждый rejected suggestion — это потерянное время с нулевым выхлопом.
Высокие стандарты. Опытные разработчики в своих собственных проектах предъявляли к коду требования, которые AI не мог выполнить. Даже принятые генерации требовали доработки до уровня, приемлемого для мейнтейнера.
Глубокое знание кодовой базы. Когда разработчик знает проект на уровне «я написал эту архитектуру пять лет назад», AI не даёт преимущества в скорости ориентирования. Выигрыш AI в навигации по незнакомому коду здесь обнуляется, а overhead на проверку генераций остаётся.
Переключение контекста. Разработчик формулирует промпт, ждёт генерацию, читает результат, решает принять или отвергнуть, редактирует. Этот цикл прерывает состояние потока и добавляет когнитивную нагрузку, которой нет при обычном написании кода.
Domenic Denicola, один из участников (мейнтейнер jsdom), описал опыт в блоге: он работал над проектом месяц, потратил 31.25 часов и получил $150/час. Его субъективная оценка ускорения от AI совпала со средней по исследованию: он думал, что AI помогал, хотя объективные данные показали обратное.
Критика и ограничения
Исследование вызвало бурную дискуссию. Основные аргументы критиков.
Малая выборка. 16 разработчиков — это мало для обобщений на всю индустрию. METR признаёт это ограничение.
Специфическая популяция. Опытные мейнтейнеры крупных open-source проектов — это не типичный разработчик. Для джуниоров, работающих с незнакомым кодом, результаты могут отличаться.
Инструменты начала 2025 года. Участники использовали Claude 3.5/3.7 Sonnet через Cursor. С тех пор модели и инструменты прошли через несколько поколений.
Привычка к инструментам. Разработчики, которые много лет работали без AI, могли не освоить инструменты достаточно глубоко за время исследования.
Обновление: февраль 2026
В феврале 2026 года METR опубликовала обновление. Организация начала новый эксперимент в августе 2025 года с расширенной группой участников и актуальными инструментами, но столкнулась с проблемой: 30-50% приглашённых разработчиков отказались участвовать, потому что не хотели работать без AI. Этот selection bias сделал новую выборку нерепрезентативной.
METR также обнаружила, что многие разработчики в 2026 году запускают несколько AI-агентов параллельно, и измерить «потраченное время» стало методологически сложнее. Организация перестроила дизайн эксперимента и, основываясь на разговорах с участниками, предположила, что ускорение от AI в начале 2026 года выше, чем в начале 2025.
Что это значит для команд
Исследование METR не доказывает, что AI-инструменты бесполезны. Оно доказывает три вещи.
Первое: субъективная оценка продуктивности ненадёжна. Разработчики искренне ошибаются, когда оценивают влияние AI на свою скорость. Команды, которые полагаются на опросы «стали ли вы продуктивнее с AI», получат завышенные цифры.
Второе: для экспертов в знакомом коде AI создаёт overhead, который может перевесить пользу. Это напрямую связано с метриками DX — когнитивная нагрузка и состояние потока страдают от цикла «промпт → проверка → отклонение». Наибольшую отдачу AI даёт на незнакомых кодовых базах и рутинных задачах.
Третье: ROI от AI нужно измерять объективно. Экранные записи, время выполнения задач, A/B-тесты на уровне команд — инструменты есть, и глава про измерение эффекта разбирает их подробнее.