7 мая Cursor выкатил 3.3 - релиз, который для разработчика-одиночки выглядит как мелкий апдейт, а для команд из 5+ человек ломает существующий workflow в хорошую сторону. Главное: параллельные агенты на одном плане, автоматический split изменений в отдельные PR и встроенный PR-review.
Эти три фичи - не косметика. Они меняют то, как вы дробите задачу на подзадачи, и сколько времени уходит между "идеей" и "merged in main".
Workflow в Cursor 3.2 и его границы
В Cursor 3 (вышел в марте) основной workflow выглядел так: вы пишете план → агент идёт по плану шаг за шагом → выкатывает один большой набор изменений → вы делаете PR.
Узкие места этого процесса всегда были одни и те же:
- Агент тупит на независимых задачах последовательно, хотя они могли бы идти параллельно.
- Финальный набор изменений часто слишком большой для одного PR - ревьюверу страшно, мерджит долго.
- Сам PR-review приходилось делать в GitHub, переключая контекст из Cursor.
В 3.3 все три узких места закрыты в одном релизе.
Главные обновления Cursor 3.3
Build in Parallel from plans
Главная фича. Когда у вас есть план из нескольких задач, теперь можно нажать "Build in Parallel". Cursor сам определяет, какие задачи независимы, и запускает их одновременно через async subagent'ы. Зависимые шаги остаются последовательными.
В описании всё звучит просто, но за этим стоит реальное ускорение для крупных рефакторингов. Если вам нужно одновременно: переписать 5 компонентов под новый API, обновить тесты к ним и поправить документацию - раньше это была последовательная работа агента на 30-40 минут. Теперь параллельные subagent'ы могут закрыть это за 10-15 при наличии пула, конечно.
Пул агентов и токены кушаются параллельно. Если у вас платный план с лимитами, запуск 5 субагентов одновременно проедает токены в 5 раз быстрее. Не факт, что итоговый объём токенов одинаков с последовательным запуском - модель меньше "помнит" контекст соседних задач и может начать их с нуля.
| Возможность | Cursor 3.2 | Cursor 3.3 |
|---|---|---|
| Build in Parallel из плана | - | есть |
| Split changes в отдельные PR | - | есть, с backup snapshot |
| PR review внутри IDE | - | Reviews / Commits / Changes |
| Pinned skills как quick-actions | - | есть |
| Subagent model overrides | общая модель | per-subagent + general names (`opus`) |
| Security Reviewer / Vulnerability Scanner | - | beta для Teams и Enterprise |
Split changes into PRs
Quick action в чате, который берёт текущие незакоммиченные изменения, анализирует их через chat context и предлагает план разбиения на независимые PR. По умолчанию делает PR независимыми, если только не находит зависимости.
Создаёт backup snapshot перед split - возврат всегда есть. Это важная деталь: автоматический split опасная операция, и backup убирает страх "а вдруг сломается".
На практике это закрывает классическую проблему "пятница вечер, у вас в working dir 12 файлов, надо разъехаться по PR, делал бы час". Теперь - минут 10 на согласование плана и вычитку.
PR review прямо в Cursor 3
Появились три новые вкладки:
- Reviews - inline-треды и top-level комментарии, всё что обычно смотрите на GitHub.
- Commits - фокусированный взгляд на историю коммитов в PR.
- Changes - навигация по большому PR с деревом файлов и picker'ом изменений.
Видна reviewer status, pending review banners, quick-action pills для следующих шагов.
Это не революция (всё это было на GitHub), но снижает context-switching. Если вы работаете в Cursor 8 часов в день, открывать ещё одну вкладку GitHub каждые 15 минут - ощутимый расход внимания. Перенос review внутрь IDE экономит этот ресурс.
Pin skills как quick-action pills
Маленькая, но удобная штука: ваши часто используемые skills можно закрепить как pill-кнопки. Раньше каждый раз приходилось выбирать из меню.
Если у вас, например, есть skill "сгенерируй migration по схеме" или "создай тест по описанию" - теперь это в один клик.
Subagent configuration
Появилось управление поведением Explore subagent'ов из настроек:
- Выбрать конкретную модель для них.
- Унаследовать модель от родительского агента.
- Полностью отключить Explore subagents.
Плюс поддержка обобщённых имён моделей: model: opus означает "всегда использовать новейший Opus". Это снимает необходимость менять конфиг при каждом релизе модели.
Кому имеет смысл апгрейд
Команда из 3-10 разработчиков. Build in Parallel и split PRs дают самый явный выигрыш именно тут: рефакторинги быстрее, ревью меньше "пугает", merge cycle короче. Если такой команде нужен внешний подрядчик на конкретный модуль - посмотри наши работы, там есть похожие проекты.
Long-running рефакторинги. Когда задача - "переехать на новый API в 30 файлах" или "переписать стилевую систему". Раньше это была работа на день, теперь возможно к вечеру вместо к концу недели. По описанию релиза в Cursor blog, эту фичу разрабатывали именно под этот сценарий.
Code review-heavy культура. Если у вас в команде ревью занимает часы и часто застревает - вкладки PR review в Cursor могут разморозить процесс, особенно для тех, кто и так живёт в IDE. Хороший внешний референс по тому, как мерить ROI таких изменений - Pragmatic Engineer, Gergely Orosz регулярно разбирает velocity и dev-tools метрики.
Подводные камни параллельных агентов
Параллельные агенты любят токены. Один последовательный запуск с большим контекстом часто дешевле, чем 5 параллельных, у каждого свой context window. Считайте бюджет, особенно если используете Claude Opus.
Split PRs - это эвристика. Cursor определяет логические слайсы по chat context. Если вы делали изменения хаотично, без чёткой структуры в комментариях и сообщениях агенту, split может предложить странную нарезку. Не ленитесь, проверяйте предложенный план перед apply.
Auto-разделение зависимостей не идеально. Если вы изменили utils.ts и потом два компонента, которые от него зависят - теоретически это три PR, практически могут получиться три PR с конфликтами при мердже первого. Backup snapshot спасает, но психологически после двух-трёх неудачных split'ов команды откатываются на ручной режим.
Auto-update Cursor для команд: 1 июня меняется система model controls, существующие blocklist'ы нужно мигрировать. Если вы Enterprise admin - это в backlog на эту неделю.
Куда движется Cursor и стек разработки
Cursor явно идёт к идее IDE как платформы для команд, а не для одного разработчика. Marketplace плагинов, Security Review beta, гранулярные admin-controls - всё это про команды от 20+ человек, не про индивидуальных пользователей.
Для российской аудитории есть отдельный нюанс: Cursor доступен из РФ, но оплата подписки требует зарубежную карту. Это не закрывает использование, но добавляет шаг в admin'е. У некоторых наших знакомых команд по этой причине стоит JetBrains AI или Codeium - стоит проверить, насколько 3.3 в Cursor оправдывает миграцию обратно.
Мы бы советовали: попробуй Build in Parallel на одном крупном рефакторинге в ближайшие две недели. Если эффект прозвучит - переключаться имеет смысл. Если ровно тот же темп с большим расходом токенов - оставайся на текущем стеке, жди 3.4.
Если у тебя проект, где такой апгрейд имеет смысл, но времени самим разбираться нет - мы поможем встроить новые фичи Cursor в команду или сделать миграцию. Также про услуги и как мы работаем - для контекста.
В @digitalimpulschannel дублируем такие разборы с короткой выжимкой и ссылкой на полный текст. Подпишись, чтобы не пропустить следующий релиз.
- Build in Parallel ускоряет крупные рефакторинги в 2-3 раза, но проедает токены в 3-5 раз.
- Split changes в PR удобен для команды, дефолтно даёт независимые PR с backup-снапшотом.
- PR review внутри IDE снижает context switching, особенно для тех, кто и так живёт в Cursor.
- Subagent overrides позволяют запускать тяжёлый Opus только там, где он нужен, экономя бюджет.
- Из РФ Cursor работает, но оплата требует зарубежной карты - заложи отдельный шаг в admin'е.