Мы провели рандомизированное контролируемое исследование (RCT), чтобы оценить, как инструменты искусственного интеллекта начала 2025 года влияют на продуктивность опытных open-source разработчиков, работающих в своих собственных репозиториях. Неожиданно оказалось, что при использовании ИИ-инструментов разработчики выполняют задачи на 19% дольше, чем без них — то есть ИИ замедляет их работу.
Мы рассматриваем этот результат как срез текущего уровня возможностей ИИ в одном из прикладных сценариев. Поскольку системы продолжают стремительно развиваться, мы планируем использовать аналогичную методологию в будущем, чтобы отслеживать, насколько ИИ способен ускорять работу в сфере автоматизации R&D[1].
Подробности — в полной версии статьи.
Мотивация
Хотя бенчмарки по программированию и агентному взаимодействию доказали свою полезность для оценки возможностей ИИ, они, как правило, жертвуют реализмом ради масштабируемости и эффективности: задачи в них самодостаточны, не требуют предварительного контекста и оцениваются алгоритмически, что не отражает множество важных способностей. Эти особенности могут приводить к завышенной оценке возможностей моделей. С другой стороны, поскольку бенчмарки не предполагают живого взаимодействия с человеком, модели могут не справляться с задачей из-за незначительных узких мест, которые в реальных условиях человек легко бы устранил. Это, наоборот, может преуменьшать их реальные способности. В целом, сопоставить бенчмарк-результаты с практическим эффектом в реальном мире — непросто.
Одна из причин, по которой мы хотим изучать влияние ИИ «в дикой природе», — это стремление лучше понять его влияние на собственные процессы R&D в AI, которое может нести существенные риски. Например, чрезмерно быстрый прогресс в AI может привести к поломке механизмов контроля или обходу систем безопасности. Оценка влияния ИИ на продуктивность разработчиков — это дополняющее бенчмарки свидетельство, дающее понимание того, как ИИ влияет на ускорение R&D в целом.
Методология
Чтобы напрямую измерить влияние ИИ-инструментов на разработку программного обеспечения в реальных условиях, мы пригласили 16 опытных разработчиков из крупных open-source репозиториев (в среднем: 22 000+ звёзд, более 1 млн строк кода), в которые они вносят вклад уже несколько лет. Участники предоставили список реальных задач (всего 246) — багфиксы, фичи и рефакторинги, которые они в обычном порядке включили бы в свою текущую работу.
Каждая задача была рандомно распределена на одну из двух групп: с разрешением или запретом использования ИИ. В условиях разрешения разработчики могли использовать любые инструменты по своему выбору (в основном — Cursor Pro с Claude 3.5/3.7 Sonnet, на тот момент — фронтирные модели). В другой группе они работали без генеративной помощи ИИ.
Разработчики выполняли задачи (в среднем по две часа на каждую), записывали экран и самостоятельно фиксировали общее время реализации. За участие в исследовании каждому платили $150 в час.
Ключевой результат
Когда разработчикам разрешается использовать ИИ-инструменты, они выполняют задачи на 19% дольше — существенное замедление, которое противоречит как ожиданиям самих разработчиков, так и прогнозам экспертов. Этот разрыв между восприятием и реальностью поразителен: разработчики ожидали, что ИИ ускорит их на 24%, а даже после фактического замедления продолжали считать, что ИИ сократил им время на 20%.
Ниже представлены необработанные средние значения: прогнозируемое время выполнения задач по оценке самих разработчиков и фактическое зафиксированное время реализации — разница очевидна: с ИИ разработчики работают заметно дольше.
Учитывая как важность понимания возможностей и рисков ИИ, так и разнообразие взглядов на эти темы, мы считаем необходимым заранее предотвратить возможные недопонимания или чрезмерные обобщения наших результатов. В таблице 2 приведены утверждения, для которых мы не предоставляем доказательств.
|
Мы не утверждаем, что: |
Пояснение |
|
ИИ-системы в настоящее время не ускоряют работу многих или большинства разработчиков программного обеспечения |
Мы не утверждаем, что наши разработчики или репозитории представляют большинство или значительную долю работы в области разработки ПО |
|
ИИ-системы не ускоряют работу отдельных лиц или групп в других областях, кроме разработки ПО |
Мы изучаем только разработку программного обеспечения |
|
В ближайшем будущем ИИ-системы не смогут ускорить работу разработчиков в аналогичных условиях |
Прогнозировать развитие сложно, но за последние пять лет ИИ сделал значительный шаг вперёд[2] |
|
Не существует способов более эффективного использования уже доступных ИИ-систем для ускорения работы в наших условиях |
Cursor использует относительно мало токенов от языковых моделей; могут быть не оптимальные подсказки или структура взаимодействия, а обучение, адаптированное под домен/репозиторий, или обучение с малым числом примеров могли бы дать положительный прирост скорости |
Факторный анализ
Мы исследуем 20 возможных факторов, которые могли бы объяснить замедление, и находим подтверждение тому, что 5 из них, скорее всего, действительно вносят вклад:
Мы исключаем множество возможных экспериментальных артефактов — разработчики использовали передовые модели, следовали назначенному условию (разрешено/запрещено использовать ИИ), не отказывались от задач выборочно (например, не отказывались от сложных задач без ИИ, что могло бы занизить среднюю сложность в этой группе), и отправляли pull-запросы схожего качества как с ИИ, так и без. Замедление сохраняется при различных метриках результата, методах оценки и во множестве других подмножеств/анализов наших данных. Подробности и дополнительный анализ — в полной версии статьи.
Обсуждение
Как же согласовать наши результаты с впечатляющими результатами ИИ на бенчмарках, сообщениями о его полезности в реальной практике? В совокупности, данные из этих источников дают частично противоречивые ответы о том, насколько ИИ-агенты способны выполнять полезные задачи или ускорять работу человека. В следующей таблице приводятся основные источники свидетельств и краткое резюме состояния наших данных по каждому из них.
Обратите внимание: таблица не претендует на полноту, а лишь схематично указывает на некоторые важные различия.
|
|
Наше РКИ |
Бенчмарки вроде SWE-Bench Verified, RE-Bench |
Практическое применение ИИ |
|
Тип задач |
Pull-запросы в крупных, качественных open-source проектах |
SWE-Bench Verified: PR’ы с тестами от авторов; RE-Bench: задачи ИИ-исследований с алгоритмической оценкой |
Разнообразные сценарии |
|
Определение успешности |
Человек доволен, что код пройдет ревью — включая стиль, тесты, документацию |
Алгоритмическая оценка (например, автотесты) |
Человек считает код полезным (возможно, как прототип или код для разовой задачи) |
|
Тип ИИ |
Чат, режим агента в Cursor, автодополнение |
Обычно полностью автономные агенты, которые могут обрабатывать миллионы токенов, использовать сложные scaffold’ы |
Различные модели и инструменты |
|
Наблюдения |
Модели замедляют людей на реалистичных задачах продолжительностью 20 мин – 4 ч |
Модели часто справляются с задачами на бенчмарках, которые очень сложны для человека |
Многие пользователи отмечают полезность ИИ для сложных задач (>1 часа) в различных областях |
Согласовать эти разные источники данных сложно, но важно — и отчасти это зависит от того, на какой вопрос мы пытаемся ответить. В некотором смысле, разные источники действительно отражают разные аспекты способностей моделей. Например, нас интересуют как возможности моделей при максимальной “эвокации” (например, при генерации миллионов токенов или десятках/сотнях попыток/траекторий на каждую задачу), так и при стандартном или распространенном использовании. Однако некоторые свойства делают результаты нерелевантными для большинства реально важных вопросов об их полезности в реальной жизни — например, самооценки могут быть неточными и чрезмерно оптимистичными.
Ниже приведены несколько обобщенных категорий гипотез, которые, на наш взгляд, наиболее правдоподобно объясняют, как эти наблюдения можно согласовать (это очень упрощённая ментальная модель):
В этих схемах красным отмечены различия между источником данных и «истинным» уровнем способностей модели представляют собой ошибку измерения или предвзятость, из-за которой данные могут вводить в заблуждение, тогда как синие различия (например, в сценарии «Mix») отражают допустимые различия в том, что именно представляют разные источники данных — например, если они просто оценивают разные подмножества всего спектра задач.
Используя эту схему, мы можем рассматривать аргументы за и против различных способов согласования этих источников данных. Например, наши результаты RCT менее актуальны в условиях, где можно запрашивать у моделей сотни или тысячи вариантов/траекторий, чего наши разработчики, как правило, не делают. Также возможно, что у инструментов ИИ вроде Cursor есть выраженные эффекты обучения, проявляющиеся только после нескольких сотен часов использования — тогда как наши разработчики обычно используют Cursor лишь несколько десятков часов до и во время исследования. Наши результаты также указывают, что способности ИИ могут быть сравнительно ниже в условиях с очень высокими стандартами качества или с множеством неявных требований (например, связанных с документацией, покрытием тестами или форматированием), на освоение которых у людей уходит значительное время.
С другой стороны, бенчмарки могут переоценивать способности моделей, так как они измеряют успех только в четко ограниченных задачах с алгоритмической оценкой. И теперь у нас есть убедительные доказательства того, что субъективные оценки ускорения работы (speed-up) часто оказываются неточными.
Ни один метод измерения не является совершенным — задачи, которые люди хотят, чтобы ИИ выполнял, разнообразны, сложны и трудно поддаются строгому анализу. Каждый подход имеет свои компромиссы, и в будущем важно продолжать развивать и использовать разнообразные методологии оценки, чтобы получить более полное представление о текущем состоянии ИИ и о том, куда мы движемся.
Что будет дальше?
Мы с энтузиазмом планируем проводить аналогичные версии этого исследования в будущем, чтобы отслеживать тенденции ускорения (или замедления) от ИИ, особенно потому, что эту методологию оценки, возможно, труднее подделать, чем бенчмарки. Если ИИ-системы действительно смогут существенно ускорять разработчиков в наших условиях, это может свидетельствовать о быстром ускорении прогресса в ИИ-исследованиях в целом, что, в свою очередь, может привести к рискам распространения, сбоям в механизмах контроля и надзора или чрезмерной концентрации власти. Эта методология дополняет данные бенчмарков, фокусируясь на реалистичных сценариях использования, и помогает более полно понять возможности и влияние ИИ, чем при опоре исключительно на бенчмарки и субъективные данные.
FAQ
Как получилось, что разработчики работали медленнее, если у них была возможность не использовать ИИ?
После завершения исследования разработчики в среднем оценили, что ИИ ускорил их на 20 %, то есть они ошибались в оценке влияния ИИ на свою продуктивность. Более того, возможно, разработчики используют ИИ-инструменты не только ради чистой продуктивности, например, потому что процесс кажется им более приятным или они воспринимают его как инвестицию в развитие навыков, которые пригодятся при работе с более совершенными системами в будущем.
Какова была мотивация этого исследования? Были ли у нас стимулы/мотивы получить такой результат?
METR — это некоммерческая организация (финансируемая за счёт пожертвований), заинтересованная в понимании того, насколько близки ИИ-системы к ускорению ИИ-исследований, что может нести значительные дестабилизирующие риски[1].
Это исследование было задумано как способ получить данные в смежной области: опытные open-source разработчики, работающие над проектами, в которых они хорошо ориентируются. Изначально мы в целом ожидали увидеть положительное ускорение — научная добросовестность является для нас основополагающей ценностью, и мы были (и остаемся) готовы делиться результатами вне зависимости от их характера.
В исследовании участвовало всего 16 разработчиков, что ограничивает возможность обобщения и воспроизведения результатов.
Мы рассчитали доверительные интервалы с учётом размера выборки, используя кластеризованные стандартные ошибки (не указано в опубликованной версии статьи, но будет в будущей). Поскольку мы не наблюдаем существенной структуры внутри разработчиков, а каждый из них решал задачи в обеих условиях, 246 выполненных задач дают нам (едва достаточную) статистическую мощность, чтобы отвергнуть нулевую гипотезу об отсутствии ускорения/замедления. См. Приложение D для обсуждения нашей эмпирической стратегии.
При этом остаётся вопрос репрезентативности — то есть вероятных смещений в том, какие разработчики в итоге участвовали в исследовании. Например, возможно, что опытные разработчики с открытым кодом, которые верят в существенное ускорение от ИИ, решили не участвовать, потому что не хотели быть вынуждены не использовать ИИ в 50 % задач. Ни один участник не сообщил о подобной мотивации, но мы не можем исключить такую (или любую другую) выборочную предвзятость.
Разработчики — новички в использовании Cursor/ИИ-инструментов? Это объясняет результат?
Разработчики, по-видимому, находятся в пределах распределения типичных пользователей Cursor Pro, хотя мы не можем исключить эффект обучения за пределами 50 часов использования. Почти все разработчики имеют значительный опыт (десятки или сотни часов) взаимодействия с LLM. См. Приложение C.2.7 для более подробного обсуждения/анализа уровня навыков работы с ИИ-инструментами.
Означают ли эти результаты, что ИИ бесполезен в разработке ПО?
Нет, вполне возможно или даже вероятно, что ИИ-инструменты полезны в других условиях, отличных от нашего, например, для менее опытных разработчиков или при работе в незнакомом коде. См. Приложение B для перечня возможных неправильных интерпретаций/обобщений, которые мы не поддерживаем на основании наших данных.
Неправильно использовать гомоскедастичные стандартные ошибки. Почему вы так делаете?
Приложение C.3.5 рассматривает альтернативные способы оценки, включая включая наивный ratio-estimator. Все альтернативные методы дают схожие результаты, что говорит о том, что вывод о замедлении устойчив к используемой эмпирической стратегии. Тем не менее, мы активно исследуем дополнительные методы оценки стандартной ошибки в ответ на обратную связь от сообщества (спасибо всем, кто её дал!).
Автор: kucev
