Отдали проект целиком Cursor на 14 дней — итог: минус 10 часов команды

В VibeLab мы работаем с AI-инструментами каждый день. Cursor используем с 2024 года, но всё это время — как ассистента у разработчика. Хотелось понять, что будет, если вместо «помоги написать функцию» дать ему весь проект и попросить вести его самому. Эксперимент рассчитали на 14 дней.

Проект — реальный рабочий инструмент команды: веб-приложение с REST API, базой данных и фронтендом. Не прототип на коленке, а вещь, которой собирались пользоваться. Тариф Cursor Pro, 20 долларов в месяц. На вход — обычные продуктовые задачи: новые фичи, рефакторинг, исправление багов.

Первая неделя выглядела многообещающе. На типовых задачах Cursor выдавал ускорение в 40–60%. CRUD-эндпоинты, которые у разработчика занимают 30–40 минут, он лепил за 5–10. Юнит-тесты и бойлерплейт штамповал как из конвейера. По грубой оценке за неделю мы сэкономили около 20 часов разработки — и сначала решили, что эксперимент удался.

Ко второй неделе картина изменилась. К этому моменту в проекте было больше 7000 строк сгенерированного кода, и стало видно, как он на самом деле выглядит. Решения несогласованные — в одной части модуля используется одна архитектурная идея, в соседней — другая, и они не договариваются между собой. Технический долг копился слой за слоем.

В зависимостях оказалось 47 пакетов вместо реально нужных 32. Cursor добавлял библиотеку под каждую задачу, не проверяя, не решается ли она уже подключённым. Самое неприятное — в продакшене всплыла SQL-инъекция: классическая, через конкатенацию пользовательского ввода в запрос. Модель не видела разницы между «ввод от формы» и «безопасным параметром».

Чтобы привести всё в порядок, на вторую неделю ушло около 30 часов работы опытного инженера: переписать критичные модули, вычистить лишние зависимости, переделать слой работы с базой. Вычисляем итог: первая неделя — минус 20 часов, вторая — плюс 30. Чистый результат — минус 10 часов. То есть отрицательная продуктивность относительно того, как если бы код писали руками.

Что мы из этого вынесли. Cursor хорош как ассистент на локальных задачах с человеческим ревью каждой выдачи — там ускорение 40–60% реально и оно остаётся. Но как самостоятельный исполнитель на боевом проекте он не годится: у модели нет памяти про архитектурные решения, она не обрабатывает безопасность как отдельный класс задач, и технический долг растёт быстрее, чем считает экономию по часам.

По сходимости с внешними цифрами наблюдение совпадает с исследованиями CMU и CodeRabbit за прошлый год — там приходили к похожим выводам: AI-кодер ускоряет на коротких горизонтах, но проигрывает на длинных, как только начинают копиться архитектурные несогласованности и неотлаженные зависимости. Мы это подтвердили на одном живом проекте.

Что мы поменяли в процессе после эксперимента. Cursor оставили в работе, но в режиме «один разработчик плюс Cursor», не «Cursor сам по себе». Каждая выдача проходит обязательное человеческое ревью — особенно если задача касается работы с базой данных, аутентификации или пользовательского ввода. На типовых CRUD-эндпоинтах и тестах модель остаётся очень полезной и продолжает экономить часы.

Для команд, которые думают в эту сторону: главный риск не в том, что AI напишет плохой код в моменте — это видно сразу. Риск в другом — что качество всего проекта незаметно поплывёт за две-три недели, потому что архитектурные решения принимались без человека и без контекста того, что было раньше. Это надо ловить ревью, не доверием к инструменту.