Компания DevExperts, занимающаяся разработкой ПО, протестировала и сравнила инструменты генерации кода Copilot и Cursor, и ее методика может быть полезна другим компаниям в качестве ориентира для тестирования ИИ-инструментов разработчика, сообщает портал The New Stack.
Как компания-разработчик, специализирующаяся на брокерских решениях, Devexperts должна балансировать между скоростью инноваций и осторожностью, требуемой в высокорегулируемой отрасли. Это касается и самых горячих новинок, таких как инструменты генеративного ИИ (GenAI). В течение последних двух лет Devexperts оценивает ИИ-инструменты ИИ для повышения производительности разработчиков, в частности генераторы кода. Будучи инженерной, компания проводит тщательно измеряемые эксперименты с использованием научного метода.
Сначала Devexperts протестировала GitHub Copilot, получив как впечатляющие, так и озадачивающие результаты. Затем выдвинула гипотезу и проверила, может ли редактор кода Cursor AI работать еще лучше.
Devexperts делится с нами метриками разработчиков, на которых основывались ее эксперименты, чтобы вы также могли протестировать GenAI в своей команде.
Можете ли вы работать так же, как GitHub-разработчики?
В сентябре 2022 года GitHub опубликовала статью, в которой говорилось, что с помощью Copilot инженеры компании на 55% увеличили количество выполняемых задач. Это вдохновило Devexperts на тестирование Copilot, чтобы узнать, смогут ли их разработчики добиться таких же результатов.
Devexperts проводила эксперимент с 1 августа по 1 ноября 2024 г., в нем приняли участие пять инженеров-программистов. Затем был выполнен ретроспективный анализ с участием еще 50 человек. И было проведено сравнение обоих результатов с полученным Github 55%-ным ростом временных показателей, что соответствует ожидаемому увеличению пропускной способности ((100%/55%)-1)*100% ≈ 120%.
В целом компания хотела проследить три тенденции:
- инженеры заметно увеличивают скорость кодирования;
- инженеры заметно увеличивают количество выполненных задач;
- инженеры работают с прежним качеством.
Команда Devexperts также достаточно ознакомилась с экспериментами других организаций, чтобы предположить, что существует реальный риск того, что размер решения и потребность в доработке заметно увеличатся, поэтому она также хотела отследить и эти аспекты.
И эксперимент, и ретроспективный анализ были направлены на измерение опыта разработчиков с помощью следующих показателей:
- Время отдельного цикла (individual cycle time) — время с момента создания первого коммита до момента слияния запроса на внесение изменений (pull request, PR).
- Время открытия (time to open) — время между самым ранним коммитом в PR и моментом открытия PR.
- Время слияния (time to merge) — время между моментом открытия PR и моментом его слияния.
- Циклы обсуждения (discussion cycles) — количество раз, в течение которого обсуждение PR переходит от одного человека к другому.
- Размер PR (pull request size) — количество строк кода, которые были добавлены, изменены или удалены.
- Пропускная способность PR (PR throughput) — количество слияний PR в основную кодовую базу за определенный период времени.
- Уровень инноваций (innovation rate) — процент изменений кода, в которых пишется совершенно новый код.
- Уровень обслуживания (maintenance rate) — процент изменений, которые обновляют код, которому более трех недель.
- Переделка (rework) — процент изменений кода, которые были обновлены в течение последних трех недель.
Devexperts обнаружила, что обнаруженное GitHub улучшение на 55% оправдалось в ходе эксперимента с пятью инженерами только в трех из девяти показателей. При этом компания увидела 69%-ное сокращение циклов обсуждения и 176%-ное увеличение пропускной способности PR, что превзошло все ожидания.
Были и другие положительные изменения, в том числе сокращение времени цикла и времени слияния, но не настолько высокие, как у инженеров GitHub.
Также на 14% снизился уровень инноваций. Это означает, что во время трехмесячного испытания разработчики тратили меньше времени на решение уникальных проблем.
Последняя метрика, переделка, является важным фактором при использовании GenAI, поскольку 67% разработчиков считают, что они тратят больше времени на отладку кода, сгенерированного ИИ. Devexperts столкнулась с 200%-ным увеличением количества переделок и 30%-ным увеличением объема обслуживания. С другой стороны, в то время как большинство организаций наблюдают увеличение сложности и количества строк кода при использовании генераторов кода, эти пять инженеров отметили удивительное снижение количества созданных строк кода на 15%.
«Мы можем сделать вывод, что в ходе эксперимента Copilot не дал тех результатов, которые можно было ожидать после прочтения той статьи», — резюмировал Герман Тебиев, архитектор процессов разработки ПО, проводивший эксперимент.
Однако он считает, что результаты достаточно убедительны, чтобы поверить в то, что высокая скорость будет достигнута, если внедрить правильные процессы: «Тот факт, что пропускная способность PR показала значительный рост, говорит нам о том, что желаемое увеличение скорости может быть достигнуто, если поток задач будет обрабатываться эффективно».
Разные разработчики, разные результаты?
Результаты первого эксперимента потребовали дальнейшего изучения Copilot на более широкой аудитории.
Для еще 50 инженеров Devexperts подсчитала и перепроверила те же показатели в течение трех месяцев до внедрения Copilot и затем еще раз в течение трех месяцев после. Результаты живого эксперимента и ретроспективного анализа сильно разошлись.
«С помощью Copilot мы сократили объем работы на 20%, выполняли задачи на 45% быстрее и сохранили прежний уровень качества, — говорит Тебиев. — Самое значительное улучшение наблюдалось на этапе рецензирования».
С помощью инструмента GitHub эта большая команда сохранила, но не увеличила уровень инноваций, при этом сократив количество переделок. Самое главное, что у этой команды значительно снизилась пропускная способность.
Согласно ретроспективному анализу, эти инженеры выполнили меньше работы, но сделали ее быстрее. Однако в реальном эксперименте они не увидели увеличения скорости, но отметили рост производительности.
Поскольку количественные результаты оказались контринтуитивными, Тебиев считает, что в ретроспективном анализе и дизайне есть некоторые недостатки, поэтому необходимо проводить еще больше экспериментов: «Мы не смогли в достаточной степени изолировать процесс разработки или обеспечить достаточно мощный отбор инженеров, чтобы получить стабильные результаты».
В целом, тенденция положительная, и любое ощущение повышения производительности у большинства разработчиков — это не то, от чего стоит отмахиваться. Возможно, это просто проблемы роста или необходимость пересмотреть рабочие процессы компании.
Качественный опыт разработчиков
Цифры имеют значение, но только в определенной степени. Качественные данные, включая ощущения разработчиков, не менее важны. Часто даже восприятие продуктивности может повлиять на реальность.
Devexperts использует платформу инженерной аналитики GetDX для проведения ежеквартальных опросов разработчиков. Им в частности задают вопрос: сколько времени в среднем вы экономите каждую неделю благодаря GitHub Copilot? (с вариантами ответа: 2+ часа;
Разработчики также могли поделиться своим собственным жизненным опытом, который очень зависит от ситуации. Так, Copilot показался лучшим выбором для завершения базовых строк кода для новых функций, и в меньшей степени — когда возникают сложности работы с существующей кодовой базой.
Как сказал старший инженер-программист по имени Александр: «Он идеально подходит для отвратительных, но простых рутинных задач, таких как генерация некоторых тестовых данных, объектов, JSON и т. д. Иногда он действительно хорош для генерации юнит-тестов, но его эффективность здесь серьезно ограничена».
Но даже если Copilot избавил его от части работы, он так и не смог убедиться, что этот инструмент способен справиться с обычным кодингом, и назвал его «бесполезным» для типичного стека разработки бэкенда на Kotlin-Java.
Некоторые разработчики также пожаловались, что этот популярный ИИ-помощник по кодированию совсем не помогает в исправлении ошибок, поскольку не может работать с контекстом большой кодовой базы. По словам Дмитрия Дербенева, руководителя отдела исследований и разработок Devexperts, поскольку изолировать части внутри более сложных кодовых баз становится все сложнее, большим языковым моделям (LLM) будет все более важно понимать контекст, чтобы давать точные рекомендации.
«Copilot облегчает написание новых функций и иногда удобно завершает предложения. Он хорошо справляется с базовыми классами и моделями, но не очень помогает с исправлением ошибок и предложениями, которые составляют основную часть моей работы над проектом, — сообщил разработчик Александр. — На мой взгляд, другие решения, такие как ChatGPT и Claude, на данный момент работают лучше. Copilot определенно не революционный инструмент».
В то же время один из разработчиков фронтенда, который считает Copilot наиболее полезным, ответил, что ему будет не хватать Copilot, если его уберут, и посетовал, что он не включен в Android Studio.
Лучше ли Cursor, чем Copilot?
В ходе следующего эксперимента, проходившего с 30 октября 2024 г. по 30 января 2025 г., 11 разработчиков из Devexperts, ранее использовавших Copilot, начали внедрять в свою работу средство завершения кода Cursor.
Изначально измерение этой когорты разработчиков Cursor должно было основываться на метрике Cycle Time — измерении времени от первого коммита до слияния PR. Однако было обнаружено, что это ненадежный источник правды, поскольку он слишком сильно колеблется и имеет ограниченный охват, так как лишь «частично» отражает время, необходимое для выполнения задачи.
«При проведении экспериментов в реальной среде сложно выделить только один фактор — например, использование Copilot или Cursor. Разные рабочие нагрузки, отпуска, ограниченная продолжительность, разная кодовая база и другие факторы делают правильную постановку эксперимента одновременно сложной и важной, — говорит Дмитрий Дербенев. — Кроме того, небольшая продолжительность эксперимента — три месяца — затрудняет наблюдение значимых тенденций».
Некоторые количественные результаты оказались впечатляющими. В отличие от Copilot, при использовании Cursor исследователи получили от 5 до 10% преимущества в исправлении ошибок. Но, опять же, наибольший выигрыш был достигнут в разработке «с нуля» с поразительным улучшением на 80% — задачи, которые обычно занимали три-четыре дня, были сокращены до одного дня.
Но поскольку количественные результаты не были достаточно объективными, «при анализе результатов мы опирались в первую очередь на субъективные отзывы разработчиков, а не на чисто количественные измерения», — отмечает Дербенев. Объективные измерения по-прежнему имеют множество ограничений в разработке ПО, утверждает он, и даже могут мешать достижению целей и создавать «извращенные стимулы».
Качественные отзывы в опросе Devexperts были сосредоточены на трех вопросах:
- Будете ли вы использовать Cursor в дальнейшем?
- Будете ли вы продолжать использовать Copilot? Если да, то вместе с Cursor? Отдельно? Или ни то, ни другое?
- Любые комментарии в свободной форме.
Даже учитывая краткость проведения эксперимента, общие качественные результаты сравнения Cursor с Copilot, согласно данным опроса, оказались в пользу Cursor:
- Восемь из одиннадцати разработчиков решили продолжить использовать Cursor после эксперимента, в то время как два разработчика не считают, что будут использовать Cursor снова.
- Четыре респондента решили продолжать использовать Copilot с Cursor или без него, в то время как семь разработчиков отказались от Copilot в пользу Cursor.
Самым большим недостатком Cursor оказалось то, что, будучи форком интегрированной среды разработчика VSCode, он требует перехода на другую IDE. Дербенев объясняет, что это вполне устраивает большинство разработчиков фронтенда, но разработчики бэкенда предпочитают использовать иные IDE.
Это также вдохновило корпоративного архитектора Виктора Исаева на проведение проверки концепции применения Cursor Agent AI, причем без всякого сопровождения — просто позволяя разработчикам экспериментировать. Инструмент снова отлично справился с рутиной, но в меньшей степени с более сложной работой по решению проблем.
«По моему мнению, Cursor помогает автоматизировать 80% работы, которая занимает 20% времени, — говорит Исаев. — Он хорош для стандартных, четко определенных вещей, которые требуют большого количества шаблонов, или создания вещей, которые хорошо известны, как сделать».
Однако, как и в случае с Copilot, по мере усложнения задач и кода он обнаружил, что Cursor становится пустой тратой времени. По его словам, этот результат оказался одинаковым для всех задач, которые включали «создание проекта с нуля, проверку того, что все работает, рефакторинг, создание тестов и внедрение некоторых архитектурных слоев, таких как аутентификация и авторизация».
Существенной частью этих экспериментов является то, что ни один из них не включал в себя обучение на интеллектуальной собственности Devexperts или ее клиентов. «Я считаю, что организация работы с контекстом кодовой базы и документации правильным, безопасным и надежным способом — это самая большая проблема для получения достойного прироста производительности при использовании LLM», — говорит Дербенев.
