Cursor делает разработчиков менее эффективными?

Одно любопытное исследование опубликовала некоммерческая организация Model Evaluation and Threat Research (METR). Они пригласили 16 опытных разработчиков, работающих над крупными open-source репозиториями, чтобы те исправили 136 реальных багов. Оплата составила 150 долларов в час. Части разработчиков выдали для работы AI-инструменты ^[1], другим — нет. Исследователи записывали экраны участников, а затем изучили и проанализировали 146 часов видеозаписей. Вывод оказался следующим:

«Удивительно, но мы обнаружили, что при использовании AI-инструментов разработчики тратят на 19% больше времени. AI делает их работу медленнее. (…) Разрыв между восприятием ^[2] и реальностью поразителен: разработчики ожидали, что AI ускорит их работу на 24%, и даже после того как фактически замедлились, они продолжали верить, что стали работать на 20% быстрее».

Результат действительно удивляет! Но в чём же дело? Давайте внимательнее посмотрим на само исследование ^[3].

Исследование посвящено влиянию Cursor на продуктивность разработчиков. Практически все участники использовали именно Cursor, с моделями Sonnet 3.5 или 3.7. При этом 44% разработчиков никогда раньше не работали с Cursor, а большинство остальных использовали его не более 50 часов.

Разработчики с AI тратили меньше времени на написание кода, но суммарное время выполнения задач у них было больше. Они также меньше времени уделяли ресёрчу и тестированию. Но при этом больше времени уходило на промптинг, ожидание откликов от AI, проверку его результатов и так называемый «IDE overhead» (накладные действия в среде разработки). В итоге дополнительное время, потраченное из-за AI, полностью нивелировало экономию на кодинге, исследовании и тестировании, показало исследование.

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

Разработчики переоценивают влияние AI на продуктивность — по крайней мере, на первых порах. Из опроса: 

«И эксперты, и разработчики сильно завышают полезность AI для продуктивности разработки, даже после того как провели много часов, работая с этими инструментами. Это подчёркивает важность проведения полевых экспериментов с чётко измеряемыми результатами вместо того, чтобы полагаться только на прогнозы экспертов или опросы среди разработчиков».

Один разработчик, который пользовался Cursor более 50 часов, показал значительное ускорение! В исследовании был всего один такой участник, и он продемонстрировал впечатляющее увеличение скорости работы на 38%. Но выборка в один человек явно не может быть репрезентативной для группы из 16 участников:

Разработчик по имени Саймон Уиллиссон — которого я считаю независимым экспертом в области AI-инструментов для разработчиков — интерпретирует результаты исследования так:

«Моя интуиция ^[6] подсказывает, что это исследование в основном показало: кривая обучения ^[7] в AI-ассистированной разработке достаточно крутая, и пока разработчики пытаются встроить её в свои рабочие процессы, их эффективность падает».

Действительно, он высказывал схожую мысль в одном из выпусков подкаста Pragmatic Engineer: «Нужно приложить очень много усилий, чтобы разобраться, исследовать, поэкспериментировать и научиться пользоваться инструментом. При этом никакого руководства нет».

В исследовании ^[8] AI-инструментов, проведённом этим изданием на основе откликов примерно 200 инженеров, мы получили следующие данные: те, кто использовал AI-инструменты менее 6 месяцев, чаще имели о них негативное мнение. Очень типичный фидбэк от инженеров, которые перестали пользоваться такими инструментами: они пробовали, но результат не оправдал ожиданий, поэтому бросили.

Инженер, который показал ускорение на 38% по сравнению с коллегами без AI, дал интересный комментарий. Этот единственный участник с опытом более 50 часов работы в Cursor — аспирант Квентин Энтони. Вот что он говорит об исследовании и о том, как AI-инструменты влияют на эффективность разработчиков:

1. Ускорение от использования AI слабо коррелирует со способностями разработчика.

Все участники этого исследования были очень сильными инженерами. Думаю, дело скорее в том, что и модели, и люди склонны попадать в одни и те же «режимы отказа». Я работаю с множеством потрясающих инженеров, занимающихся pretraining-разработкой, и вижу, что у всех возникают схожие проблемы.

Мы любим говорить, что LLM ^[9] — это инструмент, но на деле относимся к ним как к волшебной пуле.

Любой разработчик знаком с тем чувством удовлетворения, когда наконец удаётся отладить особо запутанный баг. LLM — это огромная «дофаминовая кнопка», которая иногда решает проблему одним выстрелом. Будешь ли ты продолжать нажимать на кнопку, которая имеет 1% шанс всё исправить? Это гораздо приятнее, чем идти долгим и изнурительным путём, по крайней мере, для меня.

2. У современных LLM крайне неравномерное распределение способностей.

Думаю, это связано в первую очередь с тем, для каких задач по программированию у нас есть достаточно чистых данных, и какие бенчмарки и метрики выбирают лаборатории LLM для оценки успеха.

Например, LLM отвратительно справляются с низкоуровневым системным кодом (GPU-ядра, параллелизм, коммуникации и т. п.). Причина в том, что таких данных в обучающем корпусе мало, а оценивать подобные навыки у моделей очень трудно (подробнее я разбираю на github ^[10]).

«Поскольку такие задачи составляют значительную часть моей работы как инженера, занимающегося pretraining-разработкой, я хорошо понимаю, какие из них подходят для LLM (например, написание тестов ^[11], разбор незнакомого кода), а какие — нет (написание ядер, понимание семантики синхронизации при коммуникации и т. д.). Я использую LLM только тогда, когда уверен, что модель способна надёжно справиться с задачей.

Когда я решаю, подходит ли новая задача для LLM, я стараюсь жёстко ограничивать время работы с моделью, чтобы не провалиться в бесконечную кроличью нору. Опять же, очень трудно оторваться от LLM в тот момент, когда кажется, что «вот-вот получится!».

3. Во время ожидания ответа от LLM очень легко отвлечься.

Экономика внимания ^[12] в соцсетях безжалостна: люди могут пролистать ленту полчаса, пока ждут результат 30-секундной генерации.

Всё, что могу посоветовать: нужно знать собственные слабые места и постараться провести время ожидания от LLM с пользой. Если задача требует высокой концентрации — лучше заняться подзадачей или обдумать какие-то вопросы. Даже если модель сразу даст правильный ответ, что ещё мне останется непонятым? Если задача не требует высокой концентрации — можно выполнить мелкую работу параллельно (ответить на письмо или сообщение в Slack, прочитать или отредактировать абзац текста и т. п.).

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

Квентин подытоживает:
«LLM — это инструмент, и нам нужно учиться понимать его подводные камни и иметь саморефлексию. Одна из причин, почему людям так нравятся выступления Андрея Карпати, в том, что он очень вдумчивый пользователь LLM. Он пришёл к этому раньше многих благодаря своему участию в их предобучении.

Если мы хотим действительно эффективно использовать этот новый инструмент, нам нужно понимать его (и свои собственные!) ограничения и адаптироваться к ним.»

Я думаю, не может ли переключение контекста стать ахиллесовой пятой AI-инструментов для программирования. Как разработчик, я наиболее продуктивен, когда нахожусь «в потоке» — полностью сосредоточен на задаче, без отвлекающих факторов, когда всё внимание направлено только на работу. Я прекрасно знаю, насколько дорого обходится возвращение в это состояние после того, как его потеряешь.

Но я не могу оставаться «в потоке», когда использую экономящий время AI-инструмент: пока код генерируется, я вынужден переключаться на другие дела, а это неизбежно прерывает концентрацию, и каждое такое переключение замедляет меня. Это отвлекает.

А что если само ограничение «быть в потоке» при написании кода — это не баг, а фича? И что если опытные разработчики, которые не пользуются AI-инструментами, оказываются продуктивнее большинства тех, кто их применяет, именно потому что осознанно остаются «в потоке» и концентрируются лучше? Возможно, те, кто работал без AI, находились в состоянии глубокой концентрации и показывали более высокую результативность, чем разработчики, которых AI вынуждал снова и снова переключать внимание.

Есть над чем задуматься: сэкономленное на написании кода время ещё не означает рост общей продуктивности при создании программного обеспечения.

Читать другие статьи по теме:

• Обзор AI-ассистента Cursor для разработчиков ^[13]

• Cursor vs Windsurf vs GitHub Copilot ^[14]

• Как использовать AI-агент Claude Code: советы опытного разработчика ^[15]

ИИ может тормозить процессы, если использовать его без грамотной методики. Практический курс «AI для разработчиков» ^[16] — про то, как встроить Copilot/Cody и агентные фреймворки без потери фокуса: где модели реально экономят (тесты, документация, рефакторинг), а где их стоит выключать, плюс практики безопасной интеграции.

Приходите на открытые уроки, которые бесплатно проведут преподаватели курса:

• 12 ноября: Обзор AI-технологий для разработчиков: от идей до рабочих решений. Записаться ^[17]

• 17 ноября: Создание UI с Claude Code и Playwright MCP. Записаться ^[18]