Раньше, когда вы просили Cursor реализовать крупную функцию, у вас было время выпить две чашки кофе, пока он работал. Возможно, это изменится.
Cursor выпустил две функции сегодня, и вместе они интереснее, чем по отдельности.
Параллельные субагенты: «Build in Parallel»
Нажмите «Build in Parallel», и Cursor проанализирует вашу задачу, определит, какие подзадачи независимы, и запустит их все одновременно. Не в очереди. Настоящий параллелизм.
Представьте: вы просите добавить три новых API endpoint, написать соответствующие юнит-тесты и обновить вызовы во фронтенде. Раньше это делалось по одному. Теперь три субагента работают одновременно.
Это особенно хорошо работает для рефакторинга. Когда изменения в модуле A не влияют на модуль B, параллельное выполнение экономит время линейно.
Автоматическое разделение PR: от хаоса к чистой истории Git
Параллельная работа завершена, как теперь сливать? Cursor теперь может идентифицировать логически независимые блоки изменений, предложить план разделения для вашего утверждения, а затем автоматически создать несколько небольших PR.
Это намного цивилизованнее, чем классический PR «изменено 47 файлов, сообщение коммита — update». Каждый PR делает одно дело. Ревьюеры теряют меньше нервных клеток.
Ещё один сигнал: /orchestrate
В тот же день Cursor выпустил навык /orchestrate — он может рекурсивно создавать субагентов для обработки более сложных задач. Внутри компании он использовался для автоматического исследования собственных навыков, снизив потребление токенов на 20% при улучшении оценок. Время холодного старта внутреннего бэкенда сократилось на 80%.
Рекурсивное создание агентов — не новость, но Cursor упаковал это в готовый навык, снизив порог входа.
Моё мнение
Вместе эти функции превращают Cursor из «помощника по написанию кода» в «инженерную команду, которой можно делегировать задачи».
Кто-то хорошо подметил: Claude Code — короткоживущий агент для кодинга с одним асинхронным циклом. Путь Cursor — создание мультизадачной параллельной инженерной среды.
Что важно на практике:
- Изоляция контекста между субагентами — если они мешают друг другу, последовательный режим может быть лучше
- Логика разделения PR — слишком мелкое создаст цунами PR, слишком крупное лишит смысла разделение
- Расход токенов — несколько субагентов работают одновременно, не взорвётся ли использование?
Моё чутьё: маленькие проекты не увидят большой выгоды, но для рефакторинга среднего и крупного масштаба эта функция сэкономит реальное время.
Стоит попробовать «Build in Parallel» перед следующим крупным изменением.
Основные источники: