Когда работа длится несколько недель, проблема уже не в том, чтобы агент написал очередной файл. Приходится объяснять новым сессиям принятые решения, распределять независимые задачи и собирать результаты обратно. Cursor Projects пытается перенести эту координацию в отдельный проектный контекст.
Что появилось 10 сентября
В анонсе Projects от 10 сентября 2026 Cursor описывает координатора, который планирует и поручает реализацию другим агентам, а затем приносит результат пользователю на проверку. Сам координатор код не пишет. Проект работает в облаке, поддерживает общий контекст между агентами и подписки на события. На дату анонса это beta с постепенным развёртыванием для пользователей.
Общие файлы контекста содержат исследования, артефакты и найденные правила работы. Это развитие облачных субагентов и запуска по событиям, о которых уже были отдельные статьи. Новый вопрос — кто проверяет знания, которыми теперь пользуются следующие исполнители.
Ошибка тоже становится общей
Представим миграцию отправки уведомлений в очередь. Первый агент решил, что все письма проходят через один сервис, и записал это в проектный контекст. Второй изменил сервис, третий подготовил тесты. Если первый пропустил прямую отправку из административного действия, остальные получат согласованную, но неполную картину.
Поэтому общая заметка должна содержать основание: найденные вызовы, проверенный commit и оставшиеся неизвестные. Запись «проверены HTTP-маршруты, административные действия ещё не исследованы» полезнее категоричного «все письма отправляются здесь». Это предлагаемое правило команды, а не заявленная гарантия Projects.
Исследуй все точки отправки уведомлений. Для каждой укажи файл и вызывающий сценарий. Отдельно перечисли область, которую не удалось проверить. Реализацию пока не меняй. Передай карту для проверки человеком.
Как разделить первую большую задачу
Начните с одной функции, которую можно проверить целиком. Для уведомлений это, например, перенос одного типа писем с сохранением адресатов и условий отправки. Не поручайте одновременно менять тексты писем, архитектуру очередей и экран настроек: тогда непонятно, какое решение привело к регрессии.
Координатору нужен результат, а каждому исполнителю — границы файлов и поведения. Один агент исследует точки входа, другой после принятия карты меняет реализацию, отдельный проверяющий ищет потерянные сценарии. Параллельная работа полезна там, где задачи независимы. Два агента, одновременно меняющих один контракт, добавляют работу по согласованию.
Запишите три условия остановки: неизвестно продуктовое правило, отсутствует доступная тестовая среда, требуется необратимое действие. В этих случаях следующий шаг — решение ответственного человека. Длительное выполнение само по себе не доказывает продвижение.
Подписка требует владельца
Projects умеет реагировать на источники событий, например сообщения и расписание. Для первого запуска лучше выбрать один понятный сигнал: ежедневную проверку заранее определённой группы нестабильных тестов. Свободный канал с обсуждениями содержит больше неоднозначности, чем формализованная задача.
Укажите, кто разбирает результат, какой лимит расхода допустим и когда подписка должна прекратить работу. Дубликат сообщения не должен превращаться в несколько конкурирующих исправлений. Проверьте этот сценарий отдельно, прежде чем считать автоматизацию готовой.
Что принять в конце пилота
Результат пилота — одна проверенная функция, понятный журнал решений и полезный контекст для следующей задачи. Оцените время человека на постановку, исправление неверных предположений и проверку общего diff. Если оно растёт быстрее объёма принятой работы, уменьшите число параллельных задач и уточните границы.
Сотни исполнителей из описания продукта не являются целевым показателем команды. Цель — сохранять понимание системы при большем объёме делегирования. Разработчик остаётся участником постановки, проверки и выпуска, даже когда агент продолжает работу после закрытия ноутбука.
