Современная корпоративная разработка — это всегда про компромиссы. Нужно быстро прототипировать, но при этом не потерять в качестве кода. Хочется держать в голове всю архитектуру — и фронтенд, и бэкенд, и контейнеризацию, и тесты. А по факту время уходит на переключение между десятками вкладок, согласование REST-контрактов и разбор ошибок по логам.

В этой статье мы расскажем, как в проекте нейропрототипа модуля Планирования (PlanningProto) мы использовали Cursor — редактор с ИИ, который встроен прямо в репозиторий.

Зачем Cursor здесь

PlanningProto – это нейропрототип модуля Планирования корпоративной информационной системы. Cursor — редактор с ИИ, который опирается на открытые файлы, правила в .cursor/rules и контекст репозитория. В PlaningProto это ускоряет согласование REST-контрактов между Express и React, правки в backend и frontend за один диалог и разбор проблем по логам и конфигам без перескакивания между десятками вкладок.

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

Режимы чата: Agent, Plan, Debug, Ask

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

Есть практическое правило для режимов:

• доставить код — Agent;

• обдумать до кодинга — Plan;

• разобрать, почему упало — Debug;

• спросить и не рисковать диффом — Ask.

Переключатель режима есть в интерфейсе чата (названия могут слегка отличаться в зависимости от версии Cursor).

Клиент и сервер — как устроено приложение

Понимание архитектуры приложения — это ключ к эффективной работе с Cursor. Если ИИ знает, где клиент, а где сервер, его подсказки становятся точнее. Общая схема и команды запуска описаны в корневом README. Но мы тоже коротко опишем, что за что отвечает:

• Сервер (папка backend/) — программа на Node.js: хранит и отдает данные, работает с базой PostgreSQL. Пароли и строка подключения к базе задаются через файл настроек рядом с кодом (в репозитории  Cursor сложил пример, чтобы можно было скопировать его для себя). Для разработки сервер запускают командой npm run dev из этой папки — после сохранения файлов изменения подхватываются сами, без ручной пересборки каждый раз.

• Клиент (папка frontend/) — интерфейс на React, в режиме разработки он открывается в браузере с порта 8080. Запросы к данным сам уходят на локальный сервер (порт 4000), отдельно прописывать адрес API в браузере обычно не нужно.

Запустить все вместе можно из корня проекта: в двух терминалах — команды «сервер» и «клиент» из README, либо одной командой «поднять оба сразу» — она тоже указана в README и в главном package.json.

В Cursor удобно держать открытыми обе папки: тогда подсказки ИИ учитывают и серверную часть, и экраны планирования. Это особенно полезно, когда нужно одновременно править API и интерфейс.

Figma и визуальный контекст

С архитектурой разобрались, переходим к внешнему виду. Отдельной интеграции Figma API в коде репозитория нет; макеты используются как внешняя спецификация UI.

• Ссылка на фрейм в Figma в чате + короткое описание сценария помогают точнее попасть в нужный экран (например, модалки line planning).

• При настроенном Figma MCP можно дополнительно подтягивать структуру узлов и токены по ссылке на файл.

• Dev Mode в Figma по-прежнему полезен для точных чисел; сложные auto-layout и шрифты все равно проверяются в браузере.

• Скриншоты прямо в чат Cursor: можно вставлять изображения с макета или готового UI. Модель разбирает картинку и может предложить разметку и CSS (сетка, отступы, типографика, состояния), которые вы затем переносите в компоненты проекта и согласуете с уже принятыми паттернами (не как «единственный источник правды», а как ускорение черновика).

Отладка

Когда интерфейс сверстан и запросы пошли, рано или поздно что-то идет не так. И здесь Cursor тоже может помочь, если правильно организовать процесс.

Интерфейс и сервер запускаются отдельно. Если запрос «не доходит» или ответ странный: смотрите вкладку «Сеть» в браузере (адрес страницы — обычно порт 8080) и текст в терминале, где крутится сервер (порт 4000) — там видно ошибки и ответы. В Cursor удобно держать два терминала: один для клиента, один для сервера.

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

Остановка по шагам возможна и в коде сервера, и в коде страниц; обычно это делают из редактора (режим отладки) или из браузера Chrome / Edge, пока открыт локальный адрес приложения.

Иногда экраны планирования ведут себя иначе, чем на бою, из‑за временных переключателей для разработки в настройках клиента. Если что‑то выглядит «отключенным блокировкам» или слишком свободно, попросите разработчика проверить dev‑флаги планирования.

Docker

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

С помощью Cursor в репозитории были подготовлены готовые описания контейнеров (Dockerfile у сервера и у клиента), файл сборки всего стека одной командой (docker-compose.yml в корне проекта), настройка веб-сервера внутри образа клиента и отдельный документ README.Docker.md — там по шагам Cursor расписал, что установить (Docker и Docker Compose), что вызвать в терминале и как проверить, что все поднялось.

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

Что дает один запуск Compose: поднимаются база данных, сервер приложения и собранный интерфейс; они «видят» друг друга по внутренней сети. Сервер дожидается готовности базы, чтобы не падать при старте. Данные базы сохраняются между перезапусками, пока вы явно не удалите том (об этом тоже есть в инструкции).

На что обратить внимание:

• Настройки входа в систему и адрес API для уже собранного интерфейса задаются на этапе сборки образа. Если поменяли «вход для приложения» или адрес сервера — недостаточно просто перезапустить контейнер: нужно пересобрать образ клиента так, как написано в README.Docker.md.

• В репозитории лежит пример файла с локальными дополнениями (docker-compose.override.yml): его копируют под себя, чтобы не заливать пароли в общий репозиторий.

• Если корпоративный вход (WSO2) или VPN мешают контейнеру «достучаться» до внешнего адреса, в README.Docker.md есть раздел Troubleshooting — там простым языком описано, что проверить (доступ из контейнера, режим сети на хосте, подсказка про доступ к API с машины разработчика).

Примеры команд (из корня проекта, как в инструкции):

# Поднять базу, сервер и клиент в фоне (как в README.Docker.md)
docker-compose up -d

# Посмотреть логи, если что-то не открылось в браузере
docker-compose logs -f

Важное уточнение: повседневная разработка по-прежнему удобнее через npm run dev в папках сервера и клиента (быстрее цикл «изменил код — увидел результат»). Docker здесь нужен для ситуации «хочу поднять все как в проде одной кнопкой» или показать стек коллеге без ручной установки PostgreSQL.

Тесты и CI

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

Сервер (backend):

• Основной прогон проверяет API и логику на Jest: он рассчитан на скорость, база данных в таких тестах обычно не настоящая, а подмена, чтобы не требовался запущенный PostgreSQL.

• Отдельно существуют проверки уже с настоящей базой — их не смешивают с обычным прогоном: сначала поднимают тестовый PostgreSQL в Docker, затем запускают интеграционный сценарий (конкретные шаги — у команды backend).

• Для роботов-сборщиков есть Docker-образ «только тесты»: он сам ставит зависимости, гоняет тесты с покрытием кода и формирует отчеты в формате, удобном для Sonar или аналогичной системы.

Клиент (frontend):

• Интерфейс проверяется на Vitest в среде, похожей на браузер: экраны и формы прогоняются автоматически, без ручного обхода каждой кнопки.

• Для контура сборки тоже предусмотрен отдельный Docker-образ: полный прогон и отчеты (в том числе по покрытию) совпадают по смыслу с тем, что разработчик может запустить у себя перед выкладкой.

Запуск из корня и GitLab:

• Из корня проекта одной командой можно запустить тесты и сервера, и клиента параллельно (стандартные npm-скрипты в главном package.json).

• Отдельные тестовые образы backend и frontend как раз и нужны build-агентам: зависимости, прогон, отчеты для Sonar — все внутри контейнера.

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

Итог

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

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

А у вас был опыт использования Cursor или других ИИ в корпоративной разработке?