Cursor — джун или сеньор? Какой грейд у ИИ

Cursor сделали программисты для программистов. Это не очередной чат-бот, это полноценная среда разработки. Он очень неплохо интегрирован с возможностями больших языковых моделей. 

Но насколько он хорош? Сможет ли сочинить симфонию, написать картину… то есть, конечно, сможет ли заменить живого разработчика? Мы его потыкали, протестировали и теперь хотим рассказать, на какой грейд он мог бы рассчитывать в российской ИТ-компании.

Cursor — это форк VS Code со встроенными ИИ-функциями. Он позволяет общаться с кодовой базой, генерировать код, проводить рефакторинг и многое другое. И всё на мощностях моделей вроде GPT-4. 

Но помним, качество его работы напрямую зависит от двух вещей: выбранной языковой модели и, что суперкритично, контекста. Чем лучше мы описываем задачу и чем больше релевантного кода даём на рассмотрение, тем точнее и полезнее будет результат.

Итак, чтобы оценить «грейд» Cursor, классифицируем задачи, с которыми сталкиваются разработчики. Мы условно разделяем их по уровню неопределенности:

1. Задачи с низкой неопределенностью: Четко сформулированные, с понятным ожидаемым результатом. В общем, мечта, а не задача. Это всё в духе «напиши функцию, которая сортирует массив чисел» или «переименуй переменную temp в userScore во всем проекте». Отлично подходит для джунов.

2. Задачи со средней неопределенностью: Есть общая цель, но детали реализации неясны. Например, «реализуй экран входа в приложение по дизайну» или «оптимизируй этот сетевой запрос». Такие задачки обычно решает мидл.

3. Задачи с высокой неопределенностью: Требуют архитектурных решений, анализа бизнес-требований и глубокого понимания системы. Например, «спроектируй модуль для работы с офлайн-режимом» или «исправь баг 'приложение иногда падает'». С этими задачами разбираются сеньоры.

Теперь давайте смотреть, как Cursor справляется с задачами каждого уровня.

Cursor Junior

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

• Автокомплит и генерация кода

Написать бойлерплейт, реализовать стандартный алгоритм, сгенерировать модель данных по JSON — всё это Cursor делает за секунды. Почему это полезно? Тут всё по классике — нет рутине, да — более важным вещам.

• Пакетные изменения

Нужно переименовать метод в десятках файлов? Изменить сигнатуру функции и поправить все её вызовы? Раньше это была монотонная и чреватая ошибками работа. Cursor делает это одной командой. Он сам находит все вхождения и вносит правки.

• Поддержка юнит-тестов

Покрытие кода тестами — важная, но далеко не всегда увлекательная задача. Cursor отлично справляется с написанием юнит-тестов для уже существующего кода. Он анализирует функцию и генерирует тестовые кейсы, которые покрывают основные сценарии.

Профит

На задачах уровня джун Cursor экономит огромное количество времени. Рутинные операции, которые могли занимать часы, сокращаются до минут. Что, естественно, позволяет разработчику быть продуктивнее и меньше уставать от монотонной работы.

Примеры

Посмотрим на Cursor в действии. Для начала дадим чётко поставленную задачу в рамках одного файла. 

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

Смотрим на результат выполнения. Видим, что ИИ чуток посвоевольничал и заменил свойство wasChanged на новое — transitionType.

Делаем ревью и мы понимаем, что wasChanged теперь нигде не используется. Как бы вы попросили коллегу исправить это в пулл-реквесте? 

Просто и лаконично. 

Cursor поймет эту просьбу без указания файла, потому что он хранит контекст открытого чата.

Перейдём к задачам посложнее и попросим Cursor добавить юнит-тесты файлам, с которыми работали.

Чтобы придерживаться стиля написания юнит-тестов, дадим ему почитать документацию. Cursor как старательный Junior прочитает её и примет к сведению. Не лишним будет добавить в контекст и актуальный пример тестов, чтобы нашему виртуальному коллеге было на что опираться.

Большинство ИИ-моделей, доступных в Cursor, примечательны своей, скажем так,  болтливостью. 

В конце задачи они распишут свои действия и проведут самопроверку. Это саммари поможет нам при ревью решения, но защитит ли от ошибок?

Не совсем. Здесь видим, что ИИ «выдумал» модель и сгенерированные тесты не скомпилировались. Будем ли мы это исправлять своими руками?

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

Снова делаем ревью и видим, что Cursor исправляет неправильные инициализаторы, но не останавливается на этом.

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

Этих ошибок можно было бы избежать, если бы в начальном задании мы сразу указали эти сущности. Как говорится «без внятного ТЗ — результат ХЗ». 

Но в отличие от живых коллег услужливость ИИ не позволяет ему не выдать результат. Даже если ему не хватает деталей, он придумает недостающие и выдаст решение, когда обычный Junior пойдёт задавать вопросы.

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

Более того, эта библиотека не генерирует моки для методов и свойств, добавленных в extension. Cursor просто не видит этого в файлах, но мы объясним ему это.

И он исправит проблему.

Cursor Middle

Более опытным разработчикам обычно дают более неопределенные задачи и просят найти пути решения задачи. Иными словами, их допускают к проектированию. Cursor здесь перестает быть просто исполнителем и становится настоящим напарником в парном программировании.

Ключевой подход для задач со средней неопределенностью — это работа через implementation plan. 

1. Постановка задачи и запрос плана

Вместо того, чтобы просить сразу написать код, мы ставим более общую задачу. Например, «добавить возможность сохранять адрес пользователя в профиле». И просим Cursor составить план реализации.

2. Ревью и корректировка плана

ИИ предложит шаги: «создать модель данных для адреса», «добавить поля на U», «реализовать метод сохранения в презентере», «вызвать метод в репозитории». На этом этапе мы, как более опытный разработчик, ревьюим план. Возможно, мы захотим использовать другую архитектуру, поправить названия или добавить шаг для валидации данных. Вносим правки прямо в план.

3. Отправка плана на реализацию

После утверждения плана мы отдаём его Cursor. Он последовательно реализует каждый пункт, внося изменения в кодовую базу.

4. Ревью реализации

Финальный этап — ревью кода, написанного ИИ. Он может упустить какие-то детали или выбрать не самый оптимальный способ, так что человеческий контроль всё ещё нужен.

Помним, что опасно отпускать вожжи. На каждом этапе нужно добавлять контекст. Указывать необходимые файлы и инструкции, если они есть. Без контекста ИИ как цыганка — залезет в душу, предскажет дальнюю дорогу и оставит без денег.

Профит

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

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

Пример

В этот раз минимально описываем задачу, чтобы обозначить стартовую точку и конечный результат. Ждём, что промежуточные ходы, Cursor найдёт самостоятельно. Но важно указать, в каком виде мы хотим получить план реализации.

Очень удобно ревьюить нумерованный список, где каждый пункт списка — атомарная задача для ИИ.

Ревьюить составление плана можно прямо в процессе или с выжимки. Иногда с первых шагов можно понять, что Cursor не понял задачу и начал усложнять. Тогда можно скорректировать запрос и попробовать заново.

Если же в процессе мы не замечаем ничего подозрительного, можно будет перейти к проверке предлагаемого плана.

Замечания можно оставить туду-шками. Помним, что если ИИ накосячил, то и исправлять должен сам. 

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

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

Когда нам понравится план реализации, можно попросить Cursor приступить к его выполнению. Важно повторить изначальную короткую постановку задачи и выполнять план в новом чате, чтобы очистить контекст.

После выполнения стоит проверить реализацию подобным запросом.

В отличие от примеров из предыдущей секции, результат выполнения этой задачи не вызвал ни ошибок компиляции проекта, ни падения тестов. Всё потому, что проблемы и способы их предотвращения были предусмотрены в плане.

Подход с планом реализации оказался настолько продуктивным, что в новой версии Cursor появился отдельный тип запроса для планирования.

Но он не очень хорошо работает в связке с MCP. Вместо того, чтобы использовать инструмент и посмотреть, что же мы выбрали в figma, Cursor завалил нас вопросами.

В этом режиме Cursor идёт нам навстречу — уточняет детали, пополняет контекст тем, что ему понадобится для реализации. Вопросы правильные, но на половину из них он мог бы найти ответ, если бы применил MCP.

В режиме агента проблем с MCP нет. Cursor реально читает фрейм выбранный нами в Figma, соотносит с ресурсами проекта и, в целом, делает правильные шаги.

Просто магия какая-то.

Cursor Senior

А вот тут ИИ пасует. Задачи с высокой неопределенностью — это территория, где нужны опыт, интуиция и глубокое понимание не только кодовой базы, но и бизнес-логики.

Когда мы попросим Cursor «спроектировать архитектуру нового модуля», он, конечно, что-то предложит. Скорее всего, стандартный VIPER, MVVM или другой популярный паттерн. Но он не учтёт нюансы проекта: как этот модуль будет взаимодействовать с легаси-кодом, какие требования к производительности, как это вписывается в общую стратегию развития продукта.

В задачах с высокой неопределенностью Cursor начинает «выдумывать» или «галлюцинировать». Он может предложить элегантное, но совершенно не подходящее ситуации решение. А попытки направить его в нужное русло приводят к тому, что мы тратим больше времени на объяснение контекста и исправление его ошибок, чем если бы делали все с нуля сами. 

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

Профит

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

Что там с грейдом

Cursor — это мощный инструмент, который повышает грейд самого разработчика.

• Он делает из джуна-разработчика более уверенного миддл-минус, потому что автоматизирует рутину и помогает писать тесты.

• Он делает из миддл-разработчика более продуктивного миддл-плюс — берёт на себя реализацию хорошо спланированных задач.

• Но он не может заменить сеньор-разработчика. Задачи с высокой степенью неопределённости, требующие принятия взвешенных архитектурных решений и глубокого понимания продукта, по-прежнему остаются за человеком.

Cursor — это не автопилот, это, скорее, второй пилот-помощник. Он отлично справляется с навигацией по проложенному маршруту, но прокладывать маршрут, особенно в условиях шторма, должен опытный капитан. 

Поэтому ответ на главный вопрос: у Cursor нет грейда. Он — персональный ассистент, эффективность которого зависит от того, кто и как им управляет и как ставит задачи.

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf Tech. Присоединяйтесь!