Проблема: прототипирование в корпорации — это ад
Ты приходишь с идеей нового модуля. Три недели согласований, ещё две — на написание спецификации, и только потом — первый коммит. К моменту, когда код попадает в ревью, бизнес уже передумал. Знакомо?
Корпоративное прототипирование — это не про скорость, а про бюрократию. А ещё про страх сломать легаси, про 500 правил линтинга и про «а давайте сначала нарисуем архитектуру в Confluence». В результате MVP превращается в макет, который никто не видит месяц.
Но есть инструмент, который ломает этот паттерн. Cursor — не просто AI-редактор, а полноценный агентный помощник, умеющий думать, писать и исправлять код. С релизом Cursor 3.0 и agent-first подхода (про это я уже писал в статье Cursor 3.0 и agent-first подход) прототипирование корпоративных модулей перестало быть фантастикой.
В этом гайде я покажу, как использовать четыре режима — Plan, Agent, Debug, Ask — чтобы за день собрать рабочий прототип, который не стыдно показать архитектору.
Четыре кита Cursor: когда что использовать
| Режим | Зачем | Когда юзать |
|---|---|---|
| Plan | Спроектировать архитектуру, разбить на задачи | Перед тем как писать код |
| Agent | Написать код, создать файлы, выполнить команды | Основная генерация |
| Debug | Автоматически чинить ошибки, запускать тесты | Когда что-то сломалось |
| Ask | Ответы на вопросы, поиск в документации | Если не знаешь, как подойти к задаче |
В старой парадигме ты переключался между ними вручную. Сейчас Cursor 3.0 сам умеет вызывать нужный режим по контексту. Но чтобы выжать максимум, лучше понимать, что под капотом.
Plan: архитектура до того, как ИИ улетит в галлюцинации
Самая частая ошибка при прототипировании — сразу кинуться в Agent и сказать «напиши микросервис авторизации на Go». ИИ напишет. Но там будет всё — и Redis, и PostgreSQL, и три вида JWT, хотя нужен был всего-лишь заглушка для демки.
План нужен, чтобы:
- Зафиксировать границы прототипа (что НЕ делаем).
- Разбить на атомарные шаги (каждый шаг — это промпт для Agent).
- Проверить консистентность с корпоративным стайлгайдом.
Вот как я настраиваю Plan в Cursor:
# Открой Cursor, нажми Cmd+Shift+I (или Ctrl+Shift+I на Windows),
# выбери режим Plan в правом нижнем углу.
# Или просто напиши в чате: "Переключись в режим Plan"Промпт для планирования модуля:
Ты — senior developer. Спроектируй прототип модуля «Управление ролями и доступами».
Контекст:
- Фреймворк: Spring Boot 3.4
- База: PostgreSQL (используем Flyway для миграций)
- UI не нужен, только REST API
- Должно быть 3 endpoint: создать роль, назначить пользователю, проверить доступ
- Прототип должен быть готов за 4 часа
Ограничения:
- Не используй Keycloak — слишком тяжелый для прототипа
- Не пиши тесты (их добавим позже)
- Используй in-memory кэш (Caffeine), не Redis
Выдай пошаговый план: какие файлы создать, в каком порядке, какие зависимости добавить в pom.xml.Cursor в режиме Plan выдаст структуру, а не код. Ты можешь поправить, дополнить, и только потом передать план в Agent. Кстати, если хочешь, чтобы Plan учитывал твои корпоративные стандарты — прочитай статью Как использовать Cursor для быстрого онбординга в новый проект, там я подробно разбираю .cursor/rules.
Agent: генерация кода с контролем контекста
Режим Agent — это тот самый «робот-программист», который создаёт файлы, запускает терминал, устанавливает зависимости. Но без присмотра он способен начудить.
Важно: На больших кодовых базах Agent может потерять контекст и начать галлюцинировать — придумывать несуществующие методы или библиотеки. Об этом я писал в статье Контекст или галлюцинации: 3 работающих способа заставить LLM не врать.
Моя тактика: короткие итерации. Не давай Agent'у писать 50 файлов за раз. Дай один шаг из плана — пусть создаст контроллер, потом сервис, потом репозиторий. Каждый шаг проверяй.
Пример промпта для Agent после того, как Plan готов:
Режим: Agent
Создай REST контроллер RoleController на основе плана:
- Эндпоинты: POST /roles, POST /roles/{userId}/assign, GET /roles/{userId}/check/{permission}
- Используй DTO RoleRequest и RoleResponse
- Контроллер должен быть аннотирован @RestController и @RequestMapping("/api/v1/roles")
- Не добавляй валидацию — только заглушкиAgent создаст файл, а ты можешь сразу попросить Debug запустить сборку и проверить, что компилируется.
Debug: когда ИИ сам себя чинит
Самое приятное в Cursor — режим Debug. Он не просто подсвечивает ошибки, а анализирует их и предлагает фикс. Причём может сам применить изменения.
Допустим, в сгенерированном коде опечатка в имени бина. Ты выделяешь проблему, нажимаешь Cmd+Shift+D — Cursor смотрит стектрейс, ищет похожие паттерны в проекте, чинит. Без лишнего диалога.
Ещё круче: Debug умеет запускать тесты и смотреть coverage. Если прототип покрыт тестами (а в корпорации это обязательно), Debug подсветит упавшие тесты и предложит правки.
Но будь осторожен: иногда Debug «лечит» не причину, а симптом. Например, меняет импорт, когда на самом деле не хватает зависимости. Поэтому всегда проверяй diff перед применением.
Ask: твой энциклопедический словарь
Режим Ask — самый недооценённый. Многие используют его как обычный чат, но он умеет больше: индексировать документацию, ходить в веб, читать файлы из проекта.
Когда я прототипирую модуль, Ask помогает быстро разобраться с незнакомыми технологиями. Например, нужно добавить Spring Cloud Config — спрашиваю:
Режим: Ask
Как в Spring Boot 3.4 подключить внешний конфиг-сервер?
Покажи минимальную конфигурацию bootstrap.yml и зависимости для Gradle.
Учти, что мы используем Spring Cloud 2024.0.x.Ask сканирует документацию (через твой .cursor/rules или веб-поиск) и выдаёт структурированный ответ. Можно сразу попросить скопировать ответ в Agent — и Agent создаст нужные файлы.
Ещё одна фишка: Ask понимает контекст открытого файла. Если ты выделишь кусок кода и спросишь «Зачем здесь synchronized?» — он объяснит, глядя на весь класс.
Собираем всё вместе: прототип модуля за полдня
Давай на реальном примере. Условный enterprise-проект: нужно быстро сделать прототип сервиса уведомлений (email + Telegram). Требование — завтра показать заказчику.
1 Plan — 15 минут
Открываешь Cursor, выбираешь Plan. Кидаешь контекст: стек (Java 21, Spring WebFlux, MongoDB), какие каналы поддерживаем, какие данные храним. Просишь разбить на независимые модули: общий интерфейс, адаптеры каналов, REST API. Plan выдает 5 шагов.
2 Agent — 2 часа
По очереди выполняешь шаги. Первый шаг: «Создай интерфейс NotificationSender с методом send(NotificationRequest)». Второй: «Реализуй EmailSender через JavaMailSender». Третий: «TelegramSender через библиотеку telegrambots». Каждый раз после генерации запускаешь mvn compile через терминал.
3 Debug — 30 минут
Компиляция падает на третьем шаге — не хватает конфигурации для Telegram Bot API. Debug находит ошибку, предлагает добавить application.yml с токеном. Применяешь изменение, вуаля — собирается.
4 Ask — 30 минут
Нужно добавить логирование и health-check. Вместо того чтобы лезть в Google, пишешь в Ask: «Как в WebFlux добавить endpoint /actuator/health для кастомного индикатора уведомлений?». Ask даёт код — вставляешь в проект. Готово.
Итог: за 3-4 часа у тебя работает прототип с двумя каналами отправки, REST API и health-check. Без Cursor это заняло бы минимум дня два.
Настройка .cursor/rules под корпоративные стандарты
Чтобы все режимы работали как часы, нужно правильно настроить .cursor/rules. Это файлы-инструкции, которые Cursor читает перед генерацией. Без них Agent может использовать SNAPSHOT-версии библиотек, нарушать code style или игнорировать архитектурные принципы.
Вот минимальный набор правил для корпоративного прототипа:
# .cursor/rules/enterprise-standards.md
- Все REST эндпоинты должны иметь префикс /api/v{version}
- Используем только LTS версии библиотек (Spring Boot 3.4, Java 21)
- Код должен быть покрыт комментариями в формате JavaDoc
- Запрещено использование System.out.println — используй SLF4J
- Все публичные методы должны быть аннотированы @LogExecution (наша кастомная аннотация)
- Игнорируй папку target/ и node_modules/Подробнее про .cursor/rules — в моём гайде по онбордингу. Там описано, как подключить правила из Confluence или Git.
Типичные ошибки и как их избежать
Ошибка #1: Agent делает слишком много за один промпт. Если дать задачу «сделай весь модуль» — получишь 20 файлов с неконсистентными зависимостями. Решение: декомпозируй с помощью Plan и давай шаги по 1-2 файла.
Ошибка #2: Игнорировать контекст проекта. Cursor по умолчанию видит открытые файлы, но если не подключить rules, он не знает про ваш корпоративный фреймворк. Решение: создай .cursor/rules и укажи ссылки на документацию.
Ошибка #3: Не использовать Plan. Разработчики сразу лезут в Agent, получают кашу. Решение: хотя бы 10 минут на Plan — сэкономит 2 часа на переделках.
Ещё одна боль — расход токенов. В режиме Agent каждый вызов стоит денег. Если вы работаете в команде и бюджет ограничен, почитайте статью Как я сократил счёт за Cursor в 10 раз: MCP-серверы на страже бюджета. Там я описываю, как использовать локальные MCP-серверы для частых операций — например, для генерации однотипных DTO.
Что дальше: от прототипа к production с Agentic Engineering
Cursor 3.0 — это первый шаг к тому, что Андрей Карпати называет Agentic Engineering. Когда AI не просто помогает писать код, а берёт на себя оркестрацию: сам собирает контекст, планирует, тестирует. Я уже вижу, как в ближайшие полгода режимы Plan и Debug сольются в один автономный пайплайн. Статья Software 3.0: Как перейти от Vibe Coding к Agentic Engineering хорошо объясняет эту эволюцию.
Но пока этого не случилось — учись использовать четыре режима как швейцарский нож. Plan, Agent, Debug, Ask. В правильной последовательности. Они превращают корпоративное прототипирование из мучительного квеста в почти удовольствие.
И последнее. Никогда не позволяй Agent'у коммитить в master без ревью. Даже если прототип идеален — коллеги обидятся. Или не обидятся, но code review — это сакральный ритуал.
