
Считается устоявшейся истиной, что инструменты автодополнения кода и прочая помощь от больших языковых моделей помогают программировать быстрее. Исследование организации 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 оценили на уровне старательного троечника (doi: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) — экстремистская организация, её деятельность запрещена.
Комментарии (75)
pnmv
12.07.2025 01:17Опять, к сожалению, аналитика на капле в море. Хотелось бы посмотреть результаты большого коллектива или большого количества коллективов. Хотя-бы, тысячи полторы, лучше десять-пятнадцать тысяч программистов, на разных проектах. Шестнадцать единиу - это слишком мало.
SergeyEgorov
12.07.2025 01:17Такое исследование будет стоить очень и очень дорого и его результаты никому не выгодны пока инвесторы готовы вкладывать деньги в разработку ИИ.
pnmv
12.07.2025 01:17Ну это понятно, но хочется же, чтобы по уму всё...
San_tit
12.07.2025 01:17По уму , там надо строго посчитать значимость различий. Судя по форматированию в ArXiV стиле -- будут подавать в журнал (уже подали), там на ревью, скорее всего, попросят добавить.
Но вообще, на глаз там значимость различий есть и так.
В поддержку большего масштаба: он даст распределение по опыту разработчиков и, как следствие, оценку порога "нужности" разработчика
arheops
12.07.2025 01:17Проблема в том, что оценить большой коллектив сложнее, ибо оценка производительности возможна только в ручном режиме.
Если опросить - ну тут видите тоже сказали, что +20%, а не -19%.
У нас в ретро рассказывают про +500% производительности, ибо менджеры хотят это слышать.
pnmv
12.07.2025 01:17А на малом количестве "экземпляров", сигнал тонет в шуме. Ну и образ пятилетки за два года можно отфильтровать, не расмматривая ретроспективы, и что там ещё вносит слишком сильные искажения.
arheops
12.07.2025 01:17Ну обьективно надо нащупывать границы применимости инструмента и учится им пользоваться.
Чем более независим ваш кусок кода, тем больше выигрышь. Тоесть надо учиться в правильные абстракции и доносить их до ЛЛМ.
Отфильтровать данные больших групп не получится, ибо 80-20, большинство разработчиков в корпорации вообще не разработчики ;)
Даже топовых командах больше половины не видят проблем производительности и не могут писать сложные алгоритмы, после офигенного отбора.
SergeyEgorov
12.07.2025 01:17после первого знакомства с Cursor он потратил более часа на работу с ИИ, после чего плюнул и написал всё сам
Вот у меня так каждый раз, когда я в очередной раз пытаюсь начать использовать ИИ в повседневной работе.
Politura
12.07.2025 01:17Курсор это инструмент, а не магический кристалл. С ним надо учиться работать. Настраивать его под себя, под проект. Понять какие промпты работают, а какие не очень. Какие задачи решаются промтами хорошо, а какие не очень. Понять, что модель часто не знает либ используемых в проекте и научиться давать ссылки на необходимую документацию в промпте. И ид, и тп.
Возьмите людей, которые полгода активно кодят в курсоре. Настройте им VS Code, один в один как курсор, только минус ИИ. Ну и давайте делать задания что там что там.
Onito
12.07.2025 01:17Столько всего надо чтобы работать с курсором что в итоге быстрее будет просто самостоятельно писать код)
sloww
12.07.2025 01:17Примерно столько же надо что бы научиться кодить в современных IDE и пользоваться всеми их преимуществами, примерно столько же надо что бы на адекватном уровне использовать свою unix платформу как полноценный десктоп...
Продолжать можно до бесконечности.
Это все инструменты, с инструментами нужно учиться работать прежде чем это принесет результат, будь то циркулярная пила, электрический лобзик или Cursor.
Раньше тоже писали "можно быстрее накидать 3 строчки кода в notepad, а не открывать этот ваш Intelij IDEA". Только время показало, что те кто кодил на JAVA в блокноте, сейчас поголовно сидят в IDE.
Тут будет аналогично, нейронки - инструмент, всякие Cursor и Windsurf пока не самый лучший инструмент, но прогресс необратим.
Politura
12.07.2025 01:17Столько времени надо сдать на водительские права, очевидно, что добежать самому или доехать на автобусе быстрее, чем все это потерянное время.
Onito
12.07.2025 01:17Да нет, в комментарии на который я отвечал достаточно вещей указано которые надо делать постоянно а не один раз в начале, да и не всё тут описано что надо во время работы.
thethee
12.07.2025 01:17А вы один раз создаёте шаблон под проект и потом ничего в нем не меняете? Язык программирования всегда один? Архитектуру в коде всегда одну и ту же используете? Если да, то и тут один раз настроить надо будет, а в долгоиграющем проекте это тем более только один раз настроить, привыкнуть, и дальше пользоваться.
thethee
12.07.2025 01:17Тут ведь всякие .cursorrules CLAUDE.md и прочие файлы с инструкциями для LLM довольно похожи на конфигурационные файлы. Если пишете на Python очередной микросервис в проекте - нужно скопировать и отредактировать только ту часть которая отвечает за конкретный микросервис, или скопировать общий шаблон и заставить ИИ отредактировать. Немного нужно руками сделать, да. Но путей упрощения и автоматизации много, в будущем все это станет проще.
rg_software
12.07.2025 01:17Это если вы хорошо знаете язык. А бывает приходится сделать что-то нестандартное - исправить баг в чужой библиотеке или банально доработать html шаблон или шейдер, ну или понять как правильно использовать в небанальной ситуации winapi, или найти где в большой колдобазе спряталась нужная функциональность - и сразу все окупается.
Sly_tom_cat
12.07.2025 01:17В VS Code упорно Copilot себя предлагает, а последний, свежий релиз был на 80% про Copilot и иже с ним.
JBFW
12.07.2025 01:17Господа писатели, если уж сложилась общепринятая аббревиатура типа LLM - используйте ее!
БЯМ, МЯВ, ГАВ - это конечно соответствует последним решениям Политбюро, но может, не надо?
Vedomir
12.07.2025 01:17У меня БЯМ никакого отторжения не вызывает.
JBFW
12.07.2025 01:17Напоминает советскую фантастику 50х годов, где у них всякие МУМ, БУМ, ГУМ, и полётное задание надо промумить, потому что на БУМ очередь на полгода и даже блат в виде секретаря райкома не поможет
Vedomir
12.07.2025 01:17Так LLM это абсолютно то же самое, только на английском. Я на нем более-менее свободно читаю как и на русском так что вообще не вижу разницы - та же LLM ничуть не кажется чем-то таким загадочным и притягательным.
vvovas
12.07.2025 01:17Мой опыт показывает, что cursor довольно неплох в написании каких-то небольших скриптов, если технология хорошо документирована. Периодически использую для написания скриптов. Из недавнего: анализ AWS S3 Access Logs и анализ CloudWatch Logs. Оба скрипта были написаны хорошо, разве что в парсинге S3 Access Logs формата была пара ошибок. Но в целом за пару минут у тебя готовый скрипт, на отладку которого уйдет еще несколько минут. Это будет быстрее, чем лезть в документацию и писать с нуля самому.
Более сложные задачи тоже интересно было попробовать. Создать сайт на React - пара минут и готово, добавить страницу с таблицей и данными - без проблем, сделать таблицу редактируемой - ну, вот тут мы и посыпались. И становится ясно, что когда ты полностью отдаешь генерацию ИИ без понимания, а что он там делает - это не работает. Он чего-то нагенерил и у таблицы поехали стили, а вот как это исправить совершенно непонятно и надо потратить уйму времени, чтобы разобраться в написанном и легче написать самому. Но опыт интересный.
ChatGPT очень неплох в качестве получения инструкций. Обращаюсь к нему для того чтобы понять как что-то реализовать в магазине на Shopify, с которым я никогда не работал. Инструкции получаю хорошие, изредка (5% от всего) бывают шаги, которых на самом деле нет (несуществующие меню или что-то подобное). Но опять же это гораздо проще и быстрее, чем шерстить интернет в поисках решения и выуживания простой реализации из кучи статей, где написано, что надо поставить платное приложение.sloww
12.07.2025 01:17Для меня необходимым стал chatgpt, когда я столкнулся с интеграцией со всякими гос и приближенными к ним структурами. А учитывая, как там любят давать описание API (никаких вам песочниц, вот docx файл на 300 страниц с примерами прямо там), это просто спасение.
В половине случаев достаточно было скормить docx/pdf чату и попросить сформировать реализацию авторизации, и далее последовательно накидывать ему функционал, не забывая добавлять до контекста поэтапно готовый код.
В итоге прям СИЛЬНО экономит время и решает головную боль этого идиотского формализма в документах, где написано совсем не то, что автор имеет ввиду в голове.
MadeByFather
12.07.2025 01:17Если вы скормите 300 страниц в контекст запроса, то через несколько запросов это уже будет дороже, чем посадить джуна или аналитика читать это
Хотя я даже не уверен, что это вообще влезет в максимальный контекст даже топовых моделей
sloww
12.07.2025 01:17Условный docx на 300 страниц с картинками графами и тп это 100-150к токенов, и обойдется это в 10$ в API.
Хочется посмотреть где вы захайрите за 10 баксов джуна :)
Не обязательно же в контекст вкидывать весь документ, можно поэтапно - структура плюс авторизация, потом дать готовый код авторизации со всякой сессионкой и уже просить реализовывать методы.
Через чатгопоту так вообще будет бесплатно (20 в месяц), просто надо сильно резать документ и не так эффективно как через API.
pavelsha
12.07.2025 01:17Для меня необходимым стал chatgpt, когда я столкнулся с интеграцией со всякими гос и приближенными к ним структурами. А учитывая, как там любят давать описание API (никаких вам песочниц, вот docx файл на 300 страниц с примерами прямо там), это просто спасение.
В половине случаев достаточно было скормить docx/pdf чату и попросить сформировать реализацию авторизации
Тут, наверное, стоит вспомнить про мнительных ИБ и СБ в этих структурах... Я надеюсь, что docs/PDF Вы не под NDA получали... А то иначе "ОЙ"... " Трансграничная передача... ", " Разглашение... "
Vedomir
12.07.2025 01:17Как поисковик и замена Stack Overflow это огромный шаг вперед. Не обязательно прямо просить его написать сам код целиком, но ему можно загнать этот код и спросить человеческим языком что и почему не работает и как это исправить. И это реально может сэкономить часы и дни, особенно на малознакомой технологии. Потому что ответа от человека на SO еще ждать надо и не факт что получишь, а существующая документация не учитывает особенностей твоего кода и нередко сама может быть не очень хорошо написана.
Ну а код я пока предпочитаю сам писать, потому что написанный мной код тренирует мою собственную нейронную сеть и нейронка чужая ее в данном случая обогащает, а не заменяет.
thethee
12.07.2025 01:17Мне очень нравится использовать claude taskmaster, он генерит пошаговый план реализации, который можно провалидировать и дополнить/исправить, если ты эксперт в топике.
Но больше всего в этом мне нравится то что у тебя фактически появляется пошаговый верхнеуровневой план обучения какому либо топику. Я так фронт в свободное время изучаю на примере проекта, которому хочу красивую морду сделать. Настроил правила, чтобы он писал код по-минимуму, добавил MCP на поиск, чтобы он снабжал ссылками и отправляюсь каждый день на пару часов в приключение по документациям, а он мне оценки ставит. А когда получше в топике разбираюсь, то и сам понимаю, где и что подтянуть надо, какой кусок кода все ещё смущает и конкретно по нему задаю вопрос - как улучшить.
Заодно паттерны подтягиваю. По умолчанию ИИ не всегда пишут расширяемый код, но если ему сказать например "используй паттерн репозиторий" потому что знаешь что он лучше сработает в твоём сервисе, то он пишет достаточно хорошо и даже код структурирует лучше. Или если уже написал фиговый код, так и пишешь "предложи как исправить или сделать более поддерживаемым на будущее, подбери паттерн" и оказывается что он все вполне понимает, просто поверх ИИшки нужны обертки которые будут заранее планировать, а после реализации постепенно улучшать код задавая правильные вопросы и выбирая правильные реакции на ответы.
maximlubyanov
12.07.2025 01:17Эксперимент предполагал бодрое решение задач на свежую голову...
Тема ai и прокастинация не раскрыта. Вот пусть на протяжении года понаблюдают - тогда будет понятно какой эффект оказывает искусственный идиот на производительность.
thethee
12.07.2025 01:17Да где то писали, что не очень положительный. Как и к любым подобным вещам надо подходить с осторожностью, мозг тоже не дурак и хочет отдыхать, вот только когда начинает отдавать одни, например самые монотонные, вычисления компьютеру, он начинает пытаться отдать и все остальные - а вот это уже не совсем то как с калькуляторами было. Калькулятор нельзя попросить составить расписание на отпуск, а ИИ - можно. И всем начинает казаться, что это волшебная палочка-выручалочка, а по факту очень опасный инструмент, благодаря которому можно случайно разучиться думать.
arheops
12.07.2025 01:17Есть другое исследование, что использование АИ переводит мозг почти в режим сна. И соответсвенно он из него не выходит.
И третье, что executives после консультации с чатом принимают решения... хуже, чем без него. Ну тут понятно, чат выдает стандартное решение, на уровне менеджера сильно ниже уровнем.
maximlubyanov
12.07.2025 01:17Врут безбожно - не верьте. Общение с искусственным идиотом дает толчок мозгам и прогоняет сон.
Dhwtj
12.07.2025 01:17На основе этого METR сделала вывод, что в течение 5 лет системы искусственного интеллекта смогут решать такие задачи, которые требуют целый месяц человеко-часов.
KonstantinTokar
12.07.2025 01:17В результате эксперимента был получен результат. Правда, смысла в нём не было, но люди старались.
cs0ip
12.07.2025 01:17Интересно, есть ли смысл в длинной статье с кучей графиков, которая доказывает снижение производительности, если в это же время курсор за меня чинит тесты при масштабных рефакторингах и гененерирует тысячи строк кода для типовых задач, реально экономя просто месяцы работы?
Rive
12.07.2025 01:17Если люди не разобрались или предметная область очень плохо подходит для Клода и других совместимых с Курсором нейронок, то в их случаях падение производительности выглядит вполне реалистичным.
cs0ip
12.07.2025 01:17Если не разобрались, то возможно заголовок нам врет, рассказывая об "опытных" разработчиках
arheops
12.07.2025 01:17Только недавно мы потратили неделю на х5 разработчиков на поиск бага. Причина была АИ тесты.
Написание АИ тестов классная штука, сам использую. Но по сути это отложеный тех долг.
Ибо если есть баг, АИ убедится что он задокументирован в тесте. И если ваша система не тривиальна - у вас проблема.
Все это, конечно, решается правильной модульной архитектурой. Но тогда надо разработчики супер-высокого уровня, где их взять то.
cdriper
12.07.2025 01:17подопытные из статьи тоже так думали. что что-то им экономит.
а по факту -- наоборот.
edyatl
12.07.2025 01:17На опеннете обсуждение этой новости гораздо более активное и драматичное.
Обращает внимание, что в исходном исследовании приняли участие 16 программистов, размер выборки как-то не поражает воображение.
Также есть некоторые задачи, за счёт которых будет реальное ускорение, например, написание тестов.bogolt
12.07.2025 01:17например, написание тестов.
Как будто человеку не придется убедится что они что-то в принципе тестируют.
edyatl
12.07.2025 01:17Конечно убедиться придётся, но я вот тесты писать не люблю и наверное поэтому вымучиваю их довольно долго, а ИИ пишет их на раз и справляется неплохо.
bogolt
12.07.2025 01:17А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Мой любимый пример выглядит так:
compA = createCompany() companies = searchCompany(compA.name) require.In(companies, compA)
Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция
searchCompany()
на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
thethee
12.07.2025 01:17Так никто не мешает дать достаточно подробную инструкцию для теста. "Создай несколько компаний и попробуй найти их все" все ещё быстрее напечатать, чем действительно написать код который это делает. Пример игрушечный, но мне было приятнее прочитать код и попросить его дополнить новым тестом или текущий отредактировать, чем писать самому. Лень? Может быть. Но в целом задача выполняется и при этом приятнее работать в целом, меньше усталость к концу дня.
bogolt
12.07.2025 01:17Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
mnemosha
12.07.2025 01:17А способны ли современные модели, корректно реализовать такие вещи, как напримр TCP-сокеты, строго по спецификации? Ведь спецификация по сути - это идеально поставленная задача с детальным описанием того, что должно быть реализовано и что ожидается на выходе.
arheops
12.07.2025 01:17Способны. Только результат очень вероятно будет хуже, чем написаный средним программистом(или текущий код). Но, точно, быстрее.
cdriper
12.07.2025 01:17Общаясь с Chat GPT на уровне написания маленького объема кода в духе типичного топика на StackOverflow я примерно в трети случаев получаю ошибки и неработающий код.
Внимание вопрос, сможет ли система на основе LLM сгенерировать код по спецификации, который минимум на два-три порядка сложнее типичного кода из топика на StackOverflow?
MagisterAlexandr
12.07.2025 01:17LLM хорош как языковед (понятие из книги "Мифический человеко-месяц или как создаются программные системы").
sanyvaa
12.07.2025 01:17Был проведён огромный труд, который METR зааутсорсила неназванной группе людей
похоже статья писалась тем самым БЯМом)
подумалось, а может ИИ уже живет своей жизнью в инете и генерит тысячи статей для саморекламы? цель - заставить кожаных наделать больше железа для работы ИИ.
atomlib Автор
12.07.2025 01:17Ну поищите сами в оригинальном документе. Там вообще ничего напрямую не указано. В основном разделе написано, что «мы» расставили метки. Однако в приложении G.8 на 45-й странице приводится текст инструкции, где в одном из пунктов указывается: «We’ll pay standard per hour rates for image labeling». Выглядит как инструкция для каких-то малооплачиваемых людей, возможно даже не в США. Сомневаюсь, что это именно полноценные сотрудники METR, поэтому я поразмышлял и написал, что куда-то заутсорсили.
Кстати, статьи я вообще пишу, плотно консультируясь с языковыми моделями и разными помощниками, чтобы упростить поиск информации. И именно вот этот вопрос я задавал модели o3, которая насочиняла ерунды ниже.
На всякий случай я дополнительно заставил o3 поискать этих людей в других работах METR. Они там тоже не данные размечали, а предоставляли экспертизу высокого уровня, к примеру для другой работы один из них указан как соавтор. На самом деле указанный список людей — это просто какие-то благодарности. Беглый поиск по их именам показывает, что среди них может быть глава стартапа или инженер машинного обучения. Вряд ли это они вручную размечали 84 часа видео.
То есть если хотите обсуждать написание статей БЯМ — вот их уровень. Постоянные глупые ошибки и необходимость всё допроверять. ИИ в его текущем виде не только не может заменить человека, но даже помочь может не всегда. В общем-то, это и есть тема статьи.
VADemon
12.07.2025 01:17S&P 500 на конференц-звонках для инвесторов с финансовыми результатами упоминают ИИ в той или иной форме.
https://youtu.be/-qbylbEek-M (Gamers Nexus: AI buzzword)
gaal_dev
12.07.2025 01:17С чего это устоявшейся истиной???
Эта "истина" навязана маркетинговыми "исследованиями" OpenAI, Microsoft, Google и прочими заинтересованными сторонами вбухавшими в это биллионы долларов - отказаться равно потерять свои посты директорату. Поэтому тащить несмотря ни на что.
Pavia00
12.07.2025 01:17По моим ощущениям ИИ снижает производительность на 40%. Да в качестве рыбы он хорош, но потом за наим надо переделывать. От 30-60% кода. При этом его нельзя просить что-то исправить. Потому что все БЯМ это генераторы и у них стоит штраф за повтор. Из-за этого штрафа они так же с легкостью меняют правильные, но старые данные на новые и неправильные! И если он прибавил 30% галлюцинаций потом снова 30%, то на 3 запросе у вас будет 100% галлюцинаций. И это именно из-за природы БЯМ.
einhorn
12.07.2025 01:17Из-за этого штрафа они так же с легкостью меняют правильные, но старые данные на новые и неправильные!
Курсор уже умеет показывать diff, и можно выборочно применять изменения от модели
einhorn
12.07.2025 01:17Я ни хрена не понимаю
С самого начала, еще с лета 2022, я слышу постоянно "ИИ туп, не помогает в кодинге, проще самому" - и при этом у меня лично всё ровно наоборот
У меня есть несколько гипотез
Я питонист-MLщик, я привык промтить LLM, поэтому у меня на подсознательном уровне получаются более правильные запросы
У меня очень много экспериментального кода, к качеству которого ниже требования. Я однажды слышал мнение, что "ИИ пишет говнокод, потому что он обучен на гитхабе, где много непрофессиональных проектов"
У меня код низкой связности - всякую математику не очень сложно изолировать и решать каждую задачу отдельно
У меня нет безумного легаси
В этом же исследование самое главное - Большие и сложные репозитории (иногда больше миллиона строк), то есть они работали с легаси. ИИ тяжело понимать огромные проекты. Плюс, они фиксили баги, а не писали фичи с нуля. Если бы они писали проект с нуля (ну или если хотя бы кодбаза была нормальных размеров), ситуация была бы противоположной
arheops
12.07.2025 01:17Эксперементальный и репорт-код оно пишет просто замечательно.
Проблемы начинаются в рефакторе больших проектов.
Просто надо чувствовать границы применимости инструмента.
И да, чем меньше связаность и больше модульность - тем лучше.
К агентам надо относится как к джунам.
einhorn
12.07.2025 01:17Я немного порефлексировал над своими практиками, и понял еще одну вещь: с опытом использования LLM подсознательно понимаешь, как она отработает на каждой из задач, и просто не просишь ее делать то, что LLM не умеет
А разработчик с меньшим опытом будет долбиться в курсор и ходить кругами с неподходящей задачей и угробит кучу времени
arheops
12.07.2025 01:17Основная проблема - вам УЖЕ надо иметь офигенный опыт, причем именно код ревью, а не кодинга.
Тоесть для мидлов риски значительно возрастают, не говоря про джунов.
einhorn
12.07.2025 01:17Ну, опыта человеческого код-ревью у меня не очень много
Я бы сказал, нужен опыт кодинга с LLM, в процессе появляется интуиция, на каком уровне LLM решает разные задачи
У меня тоже бывают ситуации, когда я "хожу кругами". Один раз я за день сделал 17 неудачных попыток задеплоить fastapi сервер на Digital Ocean App Platform (курсор предлагал рандомные правки, которые не работали). Проблема была в версиях питоновских либ, на следующий день на свежую голову проблема решилась за час (нужно было упростить сервер, получить другую ошибку, и с ней курсор сообразил)
Еще один раз нужно было добавить управление на мобильных устройствах в генерируемом html файле. Курсор написал кучу кода (я до сих пор не очень понимаю, почему настолько много), который почти работал (но вот это почти никак не исправлялось, за несколько итераций нуль результата, а JS код слишком длинный, чтобы MLщику а него вникать). В итоге я все нафиг удалил, попросил курсор написать простую рыбу (реакция на события), и быстро реализовал в ней логику самостоятельно, потом еще попросил курсор немного причесать UI, с чем он прекрасно справился
Просто чем дальше, тем такие истории случаются все реже. И я полагаю, адепты теории "ИИ бесполезен" просто в начале этого пути
Gorodbox
12.07.2025 01:17Cursor пишет отлично. Делаю с ним портал на WP. Результаты радуют. Да нужно пошагово, да нужно разбирать всё. Но это не тоже самое что писать самому или искать кого то и объяснить что же ты хотел. Всё таки тут очень удобно и подгрузка и пани нация и фильтры сделает и json и api . Я очень доволен.
Gorodbox
12.07.2025 01:17Ps взял сразу платную pro поэтому модели там работают на ура. А уже после 2-3х трёх дней работы с ним, он как будто понимает что ты пишешь и табами тебе докидывает. Да курсор это решение если нада что-то, но нет желания искать кого то или ждать пока ценник залупят. Это типа викс для сеошников только для решения задач . Он не заменит всё, иначе бы уже вп и битрикс разорились но.. Многим станет удобнее, как когда-то стало когда пришли конструкторы
cdriper
12.07.2025 01:17А давайте рассмотрим работу с AI ассистентом на "тактическом уровне", когда ты пишешь код, а он тебе предлагает дописывать небольшие его части за тебя.
По сути своей это просто попытка ускорить твою работу в области нажимания на кнопки. Ты мгновенно получаешь текст, на набор которого у тебя уйдет несколько десятков секунд.
Экономит это копейки, потому что редко когда производительность программиста ограничивается скоростью печати на клавиатуре.Но на самом деле, как экономия времени это не работает в принципе, потому что на 10 правильных подсказок, AI выдает одну кривую. И если все подсказки бездумно принимать (чтобы экономить время на наборе), то потом все заканчивается кучей потраченного времени на поиски багов, которые насовал тебе ассистент, а ты их бездумно принял.
Ну а если внимательно читать каждый промпт перед принятием, то тратится на порядок больше времени, чем просто на набор из головы. Потому что ты выходишь из потока, из режима написания и начинаешь внимательно читать чужой код. А чтение чужого кода это всегда более затратная вещь, чем его написание.
Skykharkov
Да по моему все просто. Что-то сложнее диалога "Yes"\"No" и привет. Все равно за этими всеми копилотами бесконечными, подчищать и переписывать большую часть. У меня ничего из того что я пробовал, например, нормально не справилось с reader'ом SQL запроса, правильной сериализацией в JSON или десериализации из JSON и обновления базы... Ну не может оно. То автоинкрименты апдейтид, то все что в индексе отбрасывает... Странная штука. Но умная, не отнять. Саботировать работу научилась почти как человек...
SergeyEgorov
На мой субъективный взгляд использование ИИ в разработке это ровно то же самое, что парное программирование. Чтобы что-то делать совместно, нужно взаимодействовать. Вот эти коммуникации сильно замедляют процесс, потому что ИИ не умеет читать мысли разработчика.
Одинокий разработчик думает сам себе в голове и пишет код.
Разработчик в паре с ИИ должен каждый раз сформулировать запрос для ИИ и затем удостовериться что ИИ выдал то, что он ожидает. Вот это вот "сформулировать запрос" оно не мгновенное и вполне себе способно съесть 19 процентов времени, если ИИ не в теме, а проект сложный и старый. А в данном случае, поскольку это не запрос "напиши мне бинарный поиск", то ИИ однозначно "не в теме".
Skykharkov
Ну где-то так. Пока сформулируешь и потом попытаешься ответ довести до ума через того-же копилота, у тебя уже весь код в голове и его только набрать остается. Да и про парное программирование вы правы. Всегда утверждал, что это как секс втроем. Движухи много, а толку мало...
aamonster
Ну так и надо набивать. Получил подсказку, прошёл трудное место (где чего-то не знал или сообразить с ходу не мог) – двигайся дальше.