Cursor не ускоряет разработку, а создает техдолг

Вышел paper Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. Его главный тезис такой: Cursor сначала разгоняет поток кода, потом раздувает технический долг, после чего сам же съедает собственную выгоду.

Если перевести это с академического языка на инженерный, вывод звучит так: AI кодинг не решает проблему разработки. Он ускоряет только выпуск кода. А вместе с ним ускоряет выпуск будущих проблем.

И это не очередной лабораторный бенчмарк на игрушечной задаче. Авторы взяли открытые GitHub-репозитории, где заметили внедрение Cursor, сравнили их с похожими проектами без Cursor и посмотрели, что происходит со скоростью и качеством кода после adoption.

Ниже самое интересное.

Авторы собрали:

1. 807 open source репозиториев с наблюдаемым Cursor adoption.

2. 1380 похожих open source без Cursor adoption в период наблюдения.

Дальше они сравнили динамику до и после внедрения Cursor.

Картина вышла неприятная.

В начале AI действительно разгоняет выпуск кода

Paper не спорит с очевидным. Cursor умеет быстро поднимать output.

Авторы оценивают, что:

1. в первый месяц после adoption, коммиты растут на 55.4%;

2. в первый месяц количество строк кода растёт на 281.3%;

3. во второй месяц коммиты растут на 14.5%;

4. во второй месяц количество строк кода растёт на 48.4%.

Это и есть главный наркотик AI кодинга. В первые недели все выглядит блестяще. Код льется рекой. Команда чувствует ускорение. Менеджмент видит движение. Кажется, что старые инженерные ограничения сняты.

Вот только этот праздник длится недолго.

Буст скорости быстро сдувается

Главное наблюдение paper: значимый прирост скорости держится только первые два месяца.

Дальше устойчивого эффекта уже нет.

Это важный момент. Речь не о том, что AI вообще не умеет ускорять. Речь о другом: AI не дает стабильного выигрыша в реальной кодовой базе. Он дает вспышку. Потом система начинает платить по счетам.

Вместе со скоростью растет и долг

Авторы отдельно смотрят на метрики качества кода и получают еще более неприятную картину:

1. static analysis warnings растут на 29.7%;

2. code complexity растет на 40.7%;

3. duplicate line density в среднем не показывает убедительного значимого роста.

Это тоже важное наблюдение. Главная проблема не в том, что AI якобы просто плодит копипасту, а в том, что кодовая база становится тяжелее, запутаннее и дороже в сопровождении.

Скорость начинает жрать сама себя

Здесь у paper самая сильная идея. Авторы описывают self-reinforcing cycle:

1. Cursor поднимает темп генерации кода.

2. Вместе с темпом растет технический долг.

3. Технический долг начинает тормозить будущую разработку.

4. Начальный выигрыш по скорости съедается.

Вот это уже похоже на реальную жизнь, а не на рекламный лендинг AI инструмента.

Если в команде слабые review, слабые тесты и слабая привычка к упрощению кода, AI кодинг превращается в машину по ускоренному накоплению проблем.

Но есть одна ложка дёгтя в этом исследовании

Проблема этого paper не в том, что он ошибается против AI кодинга. Проблема в том, что он измеряет беду слишком грубо — исследование неровное. Но даже в таком виде сигнал выходит токсичный для всего нарратива про магическое ускорение разработки.

Они измеряли не использование Cursor, а следы Cursor в git

Авторы считали, что у репозитория случился adoption, если в истории появились:

1. .cursorrules;

2. .cursor/.

То есть "репозиторий с Cursor adoption" в этом paper означает не "мы точно знаем, что команда активно кодила через Cursor", а "в git появился наблюдаемый след Cursor".

Это слабое место.

Потому что между этими двумя вещами пропасть:

1. конфиг мог закоммитить один человек;

2. инструмент могли использовать неделю, а потом просто забить на эти rules;

3. его могли применять только для мелких правок, тестов или документации;

4. часть команды могла вообще не работать с Cursor;

5. активное использование без коммита конфигов paper не увидит вовсе.

Здесь трактовка измерена грубо.

Но плохая новость для фанатов AI кодинга в другом. Даже при таком грубом прокси негативный сигнал все равно вылезает.

"Сложность кода" у них тоже прокси, а не инженерная реальность целиком

Для оценки качества кода авторы использовали SonarQube Community и считали три метрики:

1. static analysis warnings;

2. duplicate line density;

3. code complexity, то есть overall cognitive complexity кодовой базы.

Это не бесполезные метрики, но и не истина в последней инстанции.

Cognitive complexity может поймать:

1. ветвления;

2. вложенность;

3. запутанный control flow;

4. локальную трудность чтения отдельных участков.

Она плохо ловит:

1. архитектурную сложность;

2. связанность модулей;

3. лишние абстракции;

4. размазанную по слоям доменную логику;

5. реальную цену сопровождения системы целиком.

Другими словами, paper фиксирует рост sonar-метрик. Это не одно и то же, что полный замер инженерного развала.

С этим хорошо совпадает с недавним текстом OpenAI о том, почему в продукте Codex Security они не делают ставку на SAST. Логика у них такая: статические анализаторы сильны там, где проблема укладывается в формальный паттерн или более-менее прямой data flow. Но они слабы там, где нужно понимать смысл проверки, порядок преобразований данных и реальное поведение системы.

Именно там начинаются самые дорогие инженерные проблемы:

1. проверка в коде формально есть, но по сути она ничего не защищает;

2. защита стоит не в том месте пайплайна и ломается из-за порядка трансформаций;

3. фреймворк, динамический dispatch, reflection или glue-code скрывают реальную картину потока данных;

4. баг сидит не в source-to-sink паттерне (прямой цепочке от входных данных до опасной операции), а в нарушенном инварианте, состоянии или бизнес-логике.

Это важный минус по наивной вере в "объективные" quality-метрики. Статанализ хорошо видит отдельные сигналы, но плохо понимает, что система на самом деле стала дороже в изменении, опаснее в сопровождении и менее прозрачной для команды.

И здесь для AI кодинга это не оправдание, а еще одна плохая новость. Потому что главная боль от AI кода как раз часто сидит выше уровня SonarQube:

1. границы модулей плывут;

2. код становится многословным;

3. логика размазывается по дополнительным слоям;

4. система теряет локальную понятность;

5. цена изменений растет быстрее, чем это видно по отдельным warning.

То есть paper видит только часть проблемы и даже эта часть выглядит плохо.

Из этого нельзя честно сделать сильное причинное заявление

Авторы используют difference-in-differences (сравнение того, как метрики меняются до и после события у "вылеченой" группы относительно похожей контрольной) и panel GMM (панельную эконометрическую модель, которая пытается оценить динамические причинные связи во времени). Это уже серьезнее, чем обычная корреляция по двум столбикам на графике.

Но здесь все равно остается несколько дыр:

1. reverse causality — проект мог сначала ускориться и усложниться, а Cursor подключить уже на фоне растущего хаоса;

2. confounders — рост команды, релизная гонка, внешний поток PR, слабый ревью и смена мейнтейнеров тоже могли влиять и на adoption, и на метрики;

3. analysis level — они смотрят на репозиторий помесячно, а не на конкретные AI-assisted commits и PR;

4. attribution gap — paper не ловит Cursor за руку на уровне конкретных изменений.

Это значит одно: формулировка "paper доказал, что Cursor напрямую делает код хуже" слишком жирная.

Но и обратная защита не работает.

Корректный вывод звучит так: даже при грубом измерении adoption, даже при proxy-метриках качества, даже без точной привязки к каждому коммиту от AI исследование все равно вытаскивает знакомую инженерам картину. AI кодинг дает локальный всплеск output и создает системное давление на сопровождение.

Вот где paper недомерил главную проблему

Самая большая ошибка в чтении этого paper — спорить только о том, "доказали они причинность или нет".

Главный вопрос другой.

Почему вообще AI кодинг так быстро превращается в плохую сделку для команды?

Ответ неприятный:

1. код генерируется быстрее, чем его успевают понять;

2. код меняется быстрее, чем ревью успевает отличить рабочее решение от мусора;

3. архитектурные решения принимаются слишком дешево;

4. объем изменений растет быстрее, чем покрытие тестами;

5. локальная скорость маскирует глобальное ухудшение системы.

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

Пока человек пишет сам, у него естественным образом встроены трение, паузы и цена решения. При AI кодинге цена генерации падает почти до нуля. Вместе с ней падает и порог на плохие архитектурные решения, лишние абстракции и лишний код.

Система начинает тонуть не потому, что AI всегда пишет нерабочий код. Она тонет потому, что команда перестает чувствовать стоимость изменения.

Что из этого следует на практике

Если смотреть на paper как на инженерное предупреждение, выводы получаются очень приземленные.

1. После AI ускорения код надо упрощать чаще.

2. Рефакторинг больше нельзя откладывать на потом.

3. Требования к тестам нужно повышать, а не размывать.

4. Review должен становиться жестче, а не мягче.

5. Quality gates (линтеры, тесты) надо встраивать прямо в AI workflow.

6. AI нужно использовать не только как генератор, но и как инструмент на поиск лишней сложности, дублирования и плохой декомпозиции.

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

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

Итог

Этот paper не идеален.

Он грубо измеряет adoption.

Он берет proxy-метрики вместо полного инженерного замера.

Он не доказывает причинность на уровне конкретного коммита от AI.

Но даже в таком виде он показывает главное: AI кодинг не делает разработку здоровее. Он делает быстрее только одну вещь — накопление кода, который потом приходится дорого понимать, проверять, резать и переписывать.

Поэтому главный вывод для меня звучит так.

AI кодинг не работает как стратегия ведения живой кодовой базы.

Он хорошо работает как ускоритель набора текста.

Он плохо работает как способ удерживать систему простой, понятной и дешевой в изменении.

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

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

Тимур Хахалев про AI Coding, подписывайтесь