Cursor как инструмент онбординга: опыт стажёра в MTS Web Services

Родион, стажёр фронтенд-разработчик MTS Web Services, столкнулся с типичной проблемой при выходе на новое место: проект существует несколько лет, в нём накопились «исторические особенности», а первая задача — создать новый виджет — требовала понять, где вообще лежат нужные файлы. На поиск ушёл час. Именно это и стало поводом попробовать Cursor.

Cursor — редактор кода на базе VS Code с встроенным ИИ-ассистентом. В отличие от плагинов вроде GitHub Copilot, он не просто дописывает строки, а работает с проектом целиком: при открытии индексирует кодовую базу, разбивая файлы на смысловые фрагменты — функции, классы, экспорты — и превращая их в векторные представления. Когда разработчик задаёт вопрос, редактор ищет релевантные куски по этим индексам и отправляет их в модель вместе с промптом. Под капотом работают ChatGPT, Claude, Deepseek и Grok. Все предлагаемые правки отображаются как патч — зелёным то, что добавится, красным то, что удалится — и применяются только после явного согласия пользователя.

Первый промпт Родиона был намеренно простым: он объяснил, что стажёр, работает два дня, не может разобраться с архитектурой, и попросил показать, где лежат файлы и папки, связанные с виджетами. Cursor не написал ни строчки кода, но дал структурированное объяснение: какой файл за что отвечает, куда добавляются компоненты, где хранятся типы. То, что не удалось найти за час, стало понятно за несколько минут.

По ходу работы выработались четыре правила составления промптов. Первое — давать контекст: вместо «исправь эту функцию» писать, что функция отвечает за авторизацию и падает при пустом токене, и что нужна понятная ошибка. Без контекста редактор добавит формальную проверку, которая технически верна, но не соответствует тому, как обрабатываются ошибки в остальных частях проекта. Второе — указывать границы: «меняй только этот компонент и не трогай остальные», иначе Cursor может затронуть смежные модули. Третье — передавать стек и соглашения явно: React + TypeScript, стейт через Zustand, стили CSS Modules, линтер ESLint с правилами airbnb. Четвёртое — просить объяснение в двух предложениях, чтобы понимать логику предложенного решения, а не просто принимать патч.

Одно из наблюдений касается ограничений инструмента. На функции в 80 строк без комментариев Cursor за 30 секунд объяснил логику трансформации и предупредил, что функция используется ещё в трёх местах. Но когда тот же приём применили к модулю с нетривиальной асинхронной логикой, ответ был связным и уверенным, однако часть деталей оказалась неточной. Это выяснилось только на ревью у сеньора. Чем сложнее код, тем выше вероятность галлюцинации — это системное свойство LLM, а не специфика Cursor.

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

Чтобы не объяснять стек и соглашения в каждом новом диалоге, правила проекта можно зафиксировать в папке .cursor/rules/ в корне репозитория. Файлы с расширением .mdc работают как системный промпт и читаются автоматически при каждом запросе. Создаются через «Cmd+Shift+P → New Cursor Rule». Это особенно полезно в командной работе: один раз описанные соглашения применяются ко всем диалогам всех участников проекта, у которых открыт тот же репозиторий.

Опыт показывает практическую нишу ИИ-редакторов: не замена разработчика, а снижение когнитивной нагрузки при входе в незнакомый проект. Cursor не заменяет ревью и не устраняет необходимость понимать код — но сокращает время от «не знаю, где искать» до «могу начать работать».