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

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

ИИ везде

Искусственный интеллект на основе больших языковых моделей (БЯМ) призван быстро заменить труд людей в самых различных областях знаний. Возможно, ограниченный объём контекстного окна ранних моделей не позволял написать новый великий роман, но высокая практическую ценность была очевидна сразу. Компании-разработчики ИИ начали искать, какую профессию убить первой.

После выпуска GPT-4 исследователи OpenAI с гордостью рассказывали, что модель смогла пройти экзамен на юриста в США лучше 90 % людей (arXiv:2303.08774). За этим последовал шквал хвалебных статей, где всерьёз обсуждалось, что БЯМ заменит юристов (1, 2, 3).

Лишь позднее заявленное переосмыслили. Указывалось, что GPT-4 хорошо прошла тестовую часть, но подкачала в двух других. При этом сравнение с человеком проводилось для февральского экзамена, где обычно досдают те, кто провалился в июне.

Вообще, американских юристов сильно заинтересовали такие громкие заявки OpenAI. Кроме повторов эксперимента с прохождением экзамена (doi:10.2139/ssrn.4389233, doi:10.1007/s10506-024-09396-9), GPT-4 проверяли в рамках эмпирического исследования (doi:10.2139/ssrn.4539836). В этом эксперименте БЯМ дополняла человека, а не заменяла его. Для этого две группы студентов заставили прорешивать юридический экзамен в одном из вариантов 2022 года. Одна из групп при этом пользовалась GPT-4 прямо во время экзамена. С доступом к технологии слабые студенты резко улучшили свои результаты, но для сильных такого эффекта не наблюдалось. GPT-4 помогала формулировать факты и применять правила чётче, но ответы часто упускали скрытые вопросы, опирались на шаблонную структуру и ссылались на меньшее число судебных дел.

Производительность БЯМ в данной сфере считают невысокой. В другом исследовании ChatGPT оценили на уровне старательного троечника (10.2139/ssrn.4335905).

В принципе, можно даже забыть про 207 курьёзных случаев, когда в материалах дела обнаружили галлюцинации БЯМ — Дамьен Шарлотен ведёт на личном сайте любопытный список. Даже тогда реальные применения ИИ в юридической практике ограничены.

Юристам давно обещают, что автоматический анализ договоров заменит ручную вычитку, однако даже флагманские решения вроде Kira подчёркивают, что речь идёт лишь об ускорении поиска типовых ошибок, а не о стратегической правовой работе. Похожая картинка в предсказательной аналитике: сервисы Lex Machina и Premonition используют ИИ, чтобы оценивать склонность судей к тем или иным решениям, но оценки указывают, что точность ограничена объёмом и однородностью данных, а дисциплина далека от зрелости.

Аналогичная ситуация наблюдается в медицине: рекламные заявления, которые обожают цитировать в СМИ, и куда более скромная популярность в реальности.

Med-PaLM, БЯМ от Google, набирает проходной балл в медицинском экзамене США, и этот факт приводится прямо на заглавной странице проекта. Речь идёт про трёхэтапный экзамен United States Medical Licensing Examination или USMLE, необходимый для получения врачебной лицензии в США. Экзамен строгий (каждый из этапов нельзя проваливать больше 4 раз в жизни), дорогой (порядка тысячи долларов за этап) и длинный (первые два этапа требуют целый день на сдачу, третий — два). Как выяснила Microsoft, GPT-4 тоже успешно проходит USMLE (arXiv:2303.13375).

Cдавать экзамены — не то же самое, что клиническая практика. Люди любят вносить неожиданности во входные данные Даже в тестах выявлено, что мелкие опечатки или неожиданная тональность речи резко ухудшают производительность БЯМ в вопросах медицины (doi:10.1145/3715275.3732121). Как оказалось, на ответ значительно влияют клинические детали пользовательских запросов. К примеру, если в некоторых случаях в промпте поменять пол пациента на женский, то модель на 7,8 % чаще будет советовать продолжать наблюдаться на дому.

Однако и без этого врачи от БЯМ не в восторге. В исследовании 2023 года на 200 вопросов пациентов отвечали ChatGPT и реальные доктора (doi:10.1001/jamainternmed.2023.1838). БЯМ оказалась более эмпатичной, но при этом давала ошибочные или неполные рекомендации в заметной доле случаев.

В исследовании выше тестированию подвергали слабую по нынешним меркам модель GPT-3.5, поэтому многое можно списать на её примитивность. К тому же в СМИ больше писали про эмпатичность модели. Однако схожие недопустимые галлюцинации наблюдались в похожем исследовании 2024 года, где против человека выставлялась уже БЯМ GPT-4 (doi:10.1001/jamanetworkopen.2024.25953).

Крупные клиники, опираясь на такие результаты, применяют ИИ строго в режиме каких-нибудь ограниченных помощников человеку. Так, в медицинской школе Стэнфордского университета продукт DAX Copilot от Nuance Communications внедрили исключительно как писца. ИИ сам формирует черновик приёма, но врач обязан проверить и подписать документ.

Врачи аккуратны в применении БЯМ. Хорошо понятно, что ошибки ChatGPT могут лечь в основу судебных исков о медицинской халатности, пока суды и законодатели не определили чётких правил ответственности (doi:10.3389/fsurg.2024.1390684).

Куда проще и безопаснее внедрять ИИ в программирование. За медленный скрипт на веб-странице в суде не заругают.

Первые обещания

После появления популярных БЯМ почти сразу было заявлено, что ИИ если не заменит программистов полностью, то хотя бы сильно поможет писать код.

К примеру, в 2022 году компания GitHub отчиталась, что Copilot значительно повышает производительность труда разработчиков программного обеспечения. На тот момент Copilot был основан на БЯМ OpenAI Codex, которая обучалась на общедоступном коде с GitHub и считалась мощной моделью для выполнения программистских задач (arXiv:2107.03374).

В эксперименте GitHub участники с ИИ в сравнении с людьми без такого инструмента чаще заканчивали свою задачу — 78 % против 70 %. Сообщалось, что вооружённая Copilot группа разработчиков решала задачи на 55 % быстрее, чем группа без этого инструмента. При этом в опросах 88 % респондентов отвечали, что с Copilot они ощущают себя более продуктивными.

Схожие исследования цитируют в качестве рекламных заявлений о других похожих инструментах. Amazon для рекомендации CodeWhisper, собственного конкурента GitHub Copilot, приводит такие данные: снабжённые ИИ разработчики на 57 % быстрее выполняют задачи и на 27 % чаще заканчивают задачу, чем программисты без помощи БЯМ.

Эксперимент GitHub был проведён в искусственных условиях: перед 95 разработчиками поставили типовую задачу — написать сервер HTTP на JavaScript. Однако схожий тренд демонстрировали другие исследования, выяснявшие полезность БЯМ «в бою».

Например, в отчёте Google от 2024 года описывается исследование на случайно выбранных работниках компании (arXiv:2410.12944). Заявлено, что для наблюдаемых использование ИИ в работе повысило производительность на 21 %, пусть и с больши́м доверительным интервалом. Это число было чуть ниже, чем озвученное в 2023 году повышение производительности на 33 % от Duet AI, ещё одного инструмента Google.

Схожие исследования есть и про GitHub Copilot, и про Amazon CodeWhisper. Для первого есть сразу несколько научных работ, которые обнаруживают значительный скачок производительности труда разработчика, если тот прибегает к ИИ (arXiv:2409.08379, Harness, Faros). Для второго часто цитируются свидетельства очевидцев. Например, BT Group рассказывала, что за первые четыре месяца ИИ от Amazon сгенерировал более 100 тыс. строк кода и помог автоматизировать 12 % повторяющихся задач типичного программиста компании.

Важно, что эти данные не остаются забытыми цитатами из научных работ или легко игнорируемыми рекламными заявлениями. Про пользу БЯМ обожают рассказывать топ-менеджеры, чтобы заверять инвесторов в следовании общемировому тренду внедрения ИИ везде, где это возможно.

Это не всегда значит, что всё пристально дообновляется с учётом новейших данных. К примеру, ежегодный отчёт для акционеров Microsoft от 2024 года за авторством главы компании Сатьи Наделлы цитирует всё то же число (55 % улучшения), которое впервые появляется в исследовании GitHub в 2022.

Тренд глобальный. Уже почти половина компаний из списка лидеров американской индустрии S&P 500 на конференц-звонках для инвесторов с финансовыми результатами упоминают ИИ в той или иной форме. Это не только технологический сектор — про ИИ рассказывают акционерные компании сфер здравоохранения и финансов. Вещать про внедрение искусственного интеллекта полезно: в исследовании 2025 года был выявлен статистически значимый эффект роста цены акции при упоминании ChatGPT в отчётах для комиссии по ценным бумагам США (doi:10.1186/s43093-025-00470-5).

Естественно, что такие прорывы в разработке БЯМ ведут к заявлениям о скорой смерти или хотя бы значительном сокращении спроса на профессию программиста. В последнее время Марк Цукерберг даже говорит о замене менеджеров среднего звена.

В СМИ массовые увольнения разработчиков часто связывают с заменой человека искусственным интеллектом. Не чураются подобных заявлений сами компании-ньюсмейкеры. 9 июля издание Bloomberg раскрыло со ссылкой на собственные источники, что объяснял во внутренней презентации коммерческий директор Microsoft Джадсон Альтхофф.

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

Жестокая реальность

Увольнения вряд ли связаны с ИИ.

Легче говорить о коррекции избыточного найма в период глобальной ковидной удалёнки, а не резкой замене человека написанием кода на БЯМ. Даже сейчас большинство крупных американских технологических компаний имеют в штате больше сотрудников, чем до 2020 года. Резкого падения числа программистов почему-то не случилось, а если стагнация найма и есть, то незначительная.

Часть исследований сообщает, что никакого заметного прироста производительности не наблюдается. К числу таких относится отчёт 2024 года от компании Uplevel, стартапа измерения производительности разработчиков. В документе указывается, что программисты с Copilot вносят на 41 % больше багов, но при этом общая производительность почти не меняется.

Ещё одно масштабное исследование, которое бросает тень на рекламные заявления GitHub, в 2024 году провела GitClear. Эта компания аналитики, как заявляется, располагает самой крупной и подробной базой данных со структурированной информацией по изменениям кода.

Информация по коммитам у GitClear даже полнее, чем у GitHub, GitLab и Bitbucket. Данные подразделяются не просто на добавление или удаление, а на 7 различных категорий (добавление, обновление, удаление, вставка/копирование, операция «найти/заменить», перемещение, манипуляции с пробелами). В распоряжении GitClear было около миллиарда изменённых строчек, из которых проанализировали 153 млн.

Исследование предлагает восстановить реальную картину происходящего креативной интерпретацией статистики. Если с 2022 года упала доля кода, который перемещали, то это — снижение частоты рефакторинга кода из-за появления ChatGPT и Copilot. Автодополнение инструментов по типу Copilot создаёт соблазн что-то написать с нуля, а не переиспользовать существующий код в нарушение любых принципов DRY. Как было выявлено, код всё чаще добавляют, а не меняют.

Также отчёт GitClear оценивал, сколько времени прошло между добавлением кода и его последующим обновлением или удалением. Тренд схожий: в 2022 и 2023 код меньше остаётся без изменений, чем в 2020 и 2021 годах. В 2023 году доля кода, который живёт хотя бы 1 месяц без правок, упала с 25,5 % до 19,4 %. Эти отсечки взяты не с потолка. В гибких методологиях разработки после 2–3 недель спринта команда проводит ретроспективу, где обсуждается, как найти коду новое применение в следующем спринте.

Мнения о ИИ разнятся. В опросе Stackoverflow от 2024 года 43 % респондентов говорят, что высоко оценивают точность этих умных инструментов. Скептически высказываются 31 % опрошенных. При этом доверять ИИ более склонны начинающие, а не профессионалы (49 % против 42 %).

Исследование METR

Model Evaluation & Threat Research (METR) можно назвать логическим развитием ARC Evals. Последняя была внутренней командой организации Alignment Research Center, созданной американским исследователем в области искусственного интеллекта Полом Кристиано. В декабре 2023 года METR выделилась в отдельную структуру. Как и ARC, METR — организация некоммерческая. Главой METR по сей день остаётся Бет Барнс, выходец из OpenAI

В задачи METR входит системный поиск опасных способностей, а не просто прогон БЯМ по типовым бенчмаркам с целью выяснить их точность или скорость работы. К примеру, организация провела детальный анализ Claude 3.7 Sonnet и не нашла опасного уровня автономности модели. В другом случае удалось добиться обмана от БЯМ o3.

METR всё же оценивает модели и разрабатывает собственные бенчмарки, но не ради красивых чисел, а для глубокого анализа. В марте этого года организация представила исследование, где оценила способности новейших на тот момент БЯМ выполнять задачи на протяжении длительных промежутков времени (arXiv:2503.14499). Для этого была введена даже собственная метрика: горизонт времени 50-процентного выполнения задачи (50 %-task-completion time horizon). Под этим понимается время, нужное людям для выполнения тех задач, которые ИИ может выполнить с вероятностью в 50 %.

Как выяснилось, для Claude 3.7 Sonnet показатель времени 50-процентного выполнения задачи составляет 50 минут — то есть БЯМ под силу задачи, на которые человеку нужен почти час. Если сравнивать тренд, то для флагманских моделей это время удваивается каждые 7 месяцев. На основе этого METR сделала вывод, что в течение 5 лет системы искусственного интеллекта смогут решать такие задачи, которые требуют целый месяц человеко-часов.

Вообще, METR любит противопоставлять человека машине. Для исследования 2024 года RE-Bench различные БЯМ и разработчиков-людей просили выполнять задачи по программированию (https://arxiv.org/abs/2411.15114). Как выяснилось в этом бенчмарке, производительность ИИ от заметного увеличения времени на задачу не улучшается, хотя человеку дополнительные часы значительно помогают.

Любопытно, для RE-Bench было найдено много высокорепрезентативных программистов хорошего уровня: 43 эксперта из профессиональных контактов сотрудников METR, ищущие трудоустройства в METR и уже прошедшие базовый скрининг 11 соискателей и 7 аспирантов нескольких вузов — суммарно 61 человек. При этом каждый из подопытных тратил много времени — на одну попытку решения в RE-Bench затрачивалось до 8 часов. Некоторые решили не одну задачку, и от 61 участника суммарно было учтена 71 попытка решения задачек.

Также METR не поскупилась на поиск профессионалов для нового исследования «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», опубликованном 10 июля. Целью этого эксперимента было сравнить, насколько на самом деле ИИ помогает программисту. Для этого привлекли 16 участников крупных проектов с открытым исходным кодом.

Для формирования пула потенциальных подопытных задействовали профессиональные контакты сотрудников METR, поиск по сообществам машинного обучения (подреддитам /r/Python и /r/MachineLearning) и по 250 самым популярным репозиториям машинного обучения на GitHub. Важный критерий отсечки — активное участие в большом и зрелом проекте открытого программного обеспечения. Если переводить на язык требований, нужно было иметь за последние 3 месяца минимум 5 коммитов в репозиторий, у которого больше 3000 строк программного кода и не менее 500 звёзд. Последний критерий METR могла не требовать, если проект был действительно зрелым.

В результате воронки отбора из 51 заинтересованных исследователи METR выбрали 20 человек. Несколько из них отвалились по не связанным с экспериментом причинам, и в отчёте учтены только 16.

Отобранные шестнадцать — разработчики высокого класса, как правило, с десятилетием опыта или более, хотя вообще от них просили хотя бы год профессионального найма и полгода управления проектом open source. Проекты, в которые они коммитили в рамках эксперимента, оказались куда популярнее, чем требовали условия отбора. Если усреднить, у проекта получалось по 23 тыс. звёзд, 4,9 тыс. форков, 20 тыс. коммитов, 1,1 млн строк кода, 710 коммитеров. Неполный список репозиториев (три анонимизированы) приводится в таблице 8 приложения G.7 отчёта исследования.

Участников хорошо финансово компенсировали ($150 в час). Кстати, на онбординг, координационные созвоны и разборы полётов по окончании эксперимента уходило до 5 часов, которые тоже включались в оплачиваемое время. Суммарно оплачивалось до 40 часов.

Не последняя строка расходов эксперимента — 13 подписок Cursor Pro ($20 в месяц). Любопытно, что 3 из 16 разработчиков уже имели собственную подписку, поэтому им ничего не покупали. Для исследования сравнивали скорость работы с ИИ-помощниками и без, и в роли такого инструмента выступал редактор кода Cursor.

Pro — не самый дорогой тариф Cursor: стоимость Pro+ составляет $60, Ultra — $200 в месяц.

В тех 13 случаях, когда подписку покупали исследователи, собиралась статистика из дашборда Cursor. Из этого известно, к примеру, что участники эксперимента предпочитали модели Claude 3.7 Sonnet в обычном режиме и thinking, Claude 3.5 Sonnet и GPT-4o. Большая часть issue была закрыта в феврале–марте, до выхода Claude 4.0 Opus или Gemini 2.5 Pro, хотя на долю последней всё равно приходится 3 % запросов.

От разработчиков просили иметь список issue, чтобы собственно вести замеры. В ответ те предоставили 246 задачи, которые и участвовали в исследовании. Участников также просили оценить, как долго займёт закрытие issue без ИИ и с его помощью.

Также оценку хода эксперимента дали 34 эксперта-экономиста и 54 знатоков сферы машинного обучения. Всех их кратко ввели в ход работ и попросили предсказать результат. Этим экспертам не платили за труд, а предложили плавающую (зависит от точности) формулу награды в виде ставки, где можно было выиграть до $50.

В ходе эксперимента разработчики закрывали свои issue. С вероятностью 50/50 выбиралось, будет ли участник эксперимента решать задачу полностью самостоятельно или с применением ИИ. В первом случае запрещалось использовать любой генеративный ИИ. Важно, что во втором случае если разработчик считал ИИ ненужным, то его никто не обязывал к нему прибегать. Инструкция гласила: БЯМ можно пользоваться настолько много или настолько мало, насколько участник считает нужным.

Кстати, не всем был привычен напоминающий VS Code интерфейс Cursor — некоторые до этого работали в Neovim, Pycharm или другой IDE. Если для выполнения issue использовать ИИ не требовалось, то многие участники переключались обратно на свой любимый редактор кода. Однако этот экспериментальный артефакт считается незначительным, поскольку по ходу работ эффекта «привыкания» к Cursor не обнаружилось. Также на экзит-интервью никто из участников не жаловался на падение производительности от незнакомой IDE.

Вообще, допускалась гибкость ведения работы. Участники при желании могли работать хоть над несколькими issue сразу.

По окончании написания кода разработчик присылал пулл-реквест. Обычно после этого ревьюер оценивал PR, участник эксперимента вносил изменения и мёрджил обновлённый пулл-реквест. В данном исследовании все репозитории имели хорошее качество кода и высокие стандарты ревью, поэтому мёрджи редко содержали изъяны. После этого участник самостоятельно журналировал затраченное время на работу над issue.

Ход эксперимента выглядел именно как обычная работа. Ключевое различие — обязательная видеозапись экрана для последующего анализа и анализ статистики из аккаунтов Cursor.

Результат эксперимента идёт вразрез с мнением экспертов и ожиданиями самих участников. Если разработчикам разрешали использовать ИИ, на выполнение задач уходило в среднем на 19 % больше времени.

Несмотря на это сами участники эксперимента в среднем считали, что ИИ сократит времязатраты на 24 %, и даже после эксперимента заявляли о 20-процентном ускорении. Эксперты переоценивают роль ИИ ещё сильнее: они предсказали сокращение затраченного времени на 38–39 %.

Почему уходит время?

Сами по себе числа не имеют никакого смысла, если им нет внятного толкования. METR провела подробный анализ результатов.

Хотя issue было 246, METR проанализировала лишь 128 видеозаписей. Это были 143 часа видео, в части из которых нашли факты нарушения условий эксперимента, грубых (> 20 % разницы) нарушений журналирования времени и длинные (> 10 %) отсутствующие фрагменты. В итоге осталось лишь 74 ролика на 84 часа.

Был проведён огромный труд, который METR зааутсорсила неназванной группе людей. С разрешением в 10 секунд вручную был размечен каждый видеоролик на основные типы активности:

• Оценка ответа ИИ-системы;

• Промптинг ИИ-систем;

• Ожидание генерации ответа от ИИ-систем;

• Активное написание программного кода;

• Чтение или поиск информации;

• Тестирование и дебагинг кода;

• Вызов команд Git или управление своим окружением;

• Отсутствие деятельности или выполнение других работ.

Понятно, что с запретом вызывать инструменты генеративного искусственного интеллекта время использования ИИ равно нулю. Не вызывает вопросов то, что если ИИ разрешён, то на остальные категории времени будет потрачено меньше. Однако неожиданно, но если разрешалось прибегать к ИИ, участники чуть больше времени апатично тупили в экран.

METR попыталась оценить, почему в этом эксперименте ИИ замедляет разработчиков. Исследование перечисляет 5 причин этого эффекта:

• Избыточный оптимизм. Даже после первого опыта написания кода с БЯМ разработчик переоценивал роль умных инструментов и продолжал прибегать к ним. Формально участникам разрешалось всегда делать всё вручную, в том числе в замерах с использованием ИИ. Но разработчики всё равно полагались на умные функции Cursor.

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

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

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

• Большие и сложные репозитории. Как рассказывали участники эксперимента, БЯМ иногда не просто не помогали, а вносили ошибки, на исправление которых приходилось тратить время. Как предполагают исследователи METR, именно поэтому результат их эксперимента отличается от схожих исследований-предшественников.

• Низкая точность ИИ. Из дашборда Cursor известно, что подопытные приняли лишь 44 % сгенерированных фрагментов кода. Этот низкий показатель интересно иллюстрируется рассказом одного из участников: после первого знакомства с Cursor он потратил более часа на работу с ИИ, после чего плюнул и написал всё сам.

  Во время экзит-интервью все разработчики признались, что им часто приходилось править результаты генерации. Глубина этих правок разнится. 9 из 16 утверждают, что правки были крупными, другие говорят о необходимости лишь прилизать стиль.

• Подразумеваемый контекст репозитория. В разработке программного обеспечения неизбежно формируется внутреннее, незадокументированное понимание кодовой базы. Как полагают исследователи METR, это и случилось для зрелых репозиториев в эксперименте.

  Подтверждается это цитатами из экзит-интервью, где участники жалуются на отсутствие понимания у ИИ специфических случаев обратной совместимости и неправильного выбора места для внесения правок. Один из разработчиков даже сравнил БЯМ с контрибьютором-новичком.

Отчёт исследования занимает 50 страниц, в нём подробно разобраны другие факторы. Эффект девяти из них METR называет неясным и отказывается как-то учитывать. К их числу относится избыточное использование ИИ у некоторых участников (схожий эффект наблюдается и для тех, кто использовал как обычно), нерепрезентативное распределение задач (крупные issue больше 2 часов просили дробить на части, но это может быть полезно и для ИИ, и для человека) и расширение объёма задач с помощью ИИ (когда помогает ИИ, участник может «заодно» добавить лишние улучшения; в реальности такие разработчики замедлялись даже меньше).

Участнику эксперимента назначался список issue, где ИИ использовать можно и где нельзя. Порядок выполнения задач разработчик задавал сам. Можно ожидать, что для начала он бы мог выбрать issue «без-ИИ», а потом, когда силы кончатся, приступать к задачам, где ИИ вызывать можно. С другой стороны, об осознанной приоритизации участники не сообщали. Хотя полностью исключить этот эффект нельзя, у METR фактор назван невыясненным.

Возможно ли, что разработчики продолжали прибегать к БЯМ, поскольку с ним писать код приятнее и менее напряжно? Отзывы противоречивы. Часть разработчиков назвала работу с ИИ менее утомительной, часть — такой же. При этом 11 из 16 участников продолжили пользоваться Cursor после эксперимента, что намекает на какую-то пользу, но замедление не объясняет.

Ревьюеры не заметили ухудшения качества пулл-реквестов, поэтому говорить о дополнительной трате времени на ревью не приходится. Однако время доработки после ревью незначительно возросло с 9 (без ИИ) до 15 минут (с ИИ).

Медлительность генерации БЯМ объяснить разницу в 19 % не может, поскольку лишь 4 % времени было потрачено на ожидание ответа. Возможно ли, что проблема в Cursor, поскольку обычно от языковой модели IDE получает не больше пары тысяч токенов? Эту причину METR считает неподтверждённой, ссылаясь на схожие примеры в других исследованиях, где в таких же условиях наблюдается ускорение, а не падение производительности труда.

Наконец, ещё шесть факторов исследователи назвали никак не связанными с продемонстрированным эффектом. Cursor мало отличается от своего прародителя VS Code, однако даже в случае приверженности к иной среде разработки эффекта «привыкания» по ходу эксперимента не обнаружилось. Мошенничество же исключено проверкой данных. Критика способов измерения или статистических методов никак не помогает нейтрализовать обнаруженный эффект.

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

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

Не без оптимизма METR пишет, что будущие языковые модели могут оказаться на порядок более продвинутыми. Возможно, что когда-то даже опытным инженерам разработки программного обеспечения не придётся тратить драгоценное время на проверку и правку кода от БЯМ. С подобным соглашается один из участников исследования Рубен Блум: разработчика сильно поразил скачок в виде моделей Claude 4.0 Opus, Gemini 2.5 Pro и o3, произошедший за последние полгода.

На странице исследования METR напоминает, что прогресс тяжело предсказать. Пять лет назад никто не мог и ожидать, что примитивные языковые модели будут рассматриваться как замена опытному профессионалу.

Отчёт «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» опубликован на сайте METR. Авторы исследования обещают выложить анонимизированные экспериментальные данные и код проекта на аккаунте GitHub организации.

Холдинговая компания Meta (1) — экстремистская организация, её деятельность запрещена.