Étude : Cursor accélère le démarrage du développement, mais accroît ensuite la dette technique de l’équipe

Исследование о Cursor показывает неприятный для рынка AI coding сценарий: сначала инструмент ускоряет выпуск кода, но затем этот выигрыш съедают рост сложности и накопленный техдолг. Для команд это плохая новость не потому, что AI бесполезен, а потому, что локальная скорость легко маскирует будущие издержки.

Первичный буст

Авторы исследования сравнили 807 open source-репозиториев, где зафиксировали признаки внедрения Cursor, с 1380 похожими проектами без такого внедрения. Они использовали difference-in-differences-подход и смотрели не на ощущения разработчиков, а на динамику коммитов, строк кода и метрик качества до и после adoption. Это важно: речь не о лабораторном тесте на одной задаче, а о попытке понять, как AI-ассистент ведет себя в живых кодовых базах.

На старте эффект выглядит убедительно. В первый месяц после внедрения число коммитов выросло на 55,4%, а объем добавленных строк — на 281,3%. Во второй месяц прирост еще сохранялся, но уже заметно слабее: коммиты выросли на 14,5%, а строки — на 48,4%.

После этого устойчивого преимущества исследователи уже не увидели. То есть Cursor действительно может быстро разогнать output, но этот разгон не превращается в стабильное ускорение разработки на дистанции.

Цена ускорения Одновременно со скоростью исследование зафиксировало рост проблем в кодовой базе.

Число предупреждений статического анализа после внедрения Cursor увеличилось на 29,7%, а общая сложность кода — на 40,7%. При этом плотность дублирования строк не показала значимого скачка. Вывод здесь важный: дело не только и не столько в копипасте, сколько в том, что система становится тяжелее, запутаннее и дороже в сопровождении.

Для команды это обычно означает несколько вещей: review приходится тратить больше времени на большие AI-сгенерированные изменения тесты и линтеры начинают ловить больше проблем уже после генерации, а не до нее архитектурные решения принимаются слишком дешево и быстрее попадают в main branch локально удобный код хуже читается и труднее меняется через несколько недель Именно поэтому авторы говорят о самоподдерживающемся цикле. Cursor ускоряет выпуск кода, техдолг растет вместе с ним, а затем этот долг начинает тормозить следующие изменения на практике. Если у команды слабые ревью, редкий рефакторинг и недостаточное покрытие тестами, выигрыш первых недель довольно быстро превращается в новый источник замедления.

Бутылочное горлышко смещается: писать код становится легче, а понимать, проверять и упрощать его — сложнее.

Где есть оговорки При этом исследование нельзя читать как окончательный приговор.

Авторы считали, что репозиторий внедрил Cursor, если в истории появлялись файлы вроде .cursorrules или папка .cursor. Это полезный, но грубый прокси-сигнал. Он не показывает, насколько активно команда реально пользовалась инструментом, кто именно его использовал и применялся ли Cursor для основной разработки, а не для мелких правок или документации. И это ограничивает силу причинного вывода. Есть и вторая оговорка: качество оценивали по метрикам SonarQube, включая предупреждения статанализа и cognitive complexity. Эти показатели полезны, но они не измеряют всю инженерную реальность. Они хуже видят архитектурную связанность, расползание доменной логики по слоям и реальную цену сопровождения системы. Поэтому честный вывод звучит так: исследование не доказывает, что каждый AI-коммит делает код хуже, но оно уверенно показывает тревожный паттерн на уровне проектов.

Что это значит

Для бизнеса и инженерных команд это не аргумент против AI coding как такового, а сигнал перестраивать процесс вокруг него. Если использовать Cursor только как ускоритель генерации, без более жесткого review, быстрых рефакторингов и усиленных quality gates, короткий всплеск скорости легко оборачивается техдолгом. Главный урок здесь простой: AI снимает трение при написании кода, но не отменяет цену плохих решений и не делает сопровождение бесплатным.