Cursor Projects: агент-координатор для больших задач
Cursor представил Projects 10 сентября 2026 года. Что меняется в работе с агентами, кому полезна бета и с какой задачи начать: пример брифа и критерии приёмки.
10 сентября 2026 года Cursor анонсировал Projects — режим для задач, которые продолжаются дольше одного чата. Пользователь общается с координатором, а тот распределяет работу между агентами. На момент анонса началось постепенное открытие беты. Источник: Cursor.
Для тех, кто делает сайты и приложения с ИИ, здесь интересен рабочий вопрос: как поручить инструменту целую функцию и всё ещё понимать, что именно он сделал? Разберём новость и предложим первый эксперимент. Это анализ анонса и пример постановки задачи; собственный запуск беты в этом материале не заявляется.
Что объявил Cursor
В Projects координатор планирует и делегирует задачи; код пишут агенты-исполнители. Работа идёт на облачной машине и может продолжаться при закрытом ноутбуке. Для проверок на компьютере пользователя предусмотрен локальный агент.
Общий контекст проекта хранит исследования, артефакты и сведения о работе с кодом. Ещё заявлены подписки на события: например, изменения PR или сообщения Slack, а также выполнение по расписанию. Открывать Projects предлагается из левой панели. Доступ разворачивается постепенно, поэтому наличие функции нужно проверить в своём аккаунте. Описание возможностей и статуса беты.
Команда Cursor выделяет три направления применения: разработку функций, миграции и постоянное сопровождение кода. Эти примеры помогают понять замысел продукта, но сами по себе не доказывают пользу для любого проекта. Подробный анонс.
Что это меняет в работе с ИИ
Мой вывод: при таком процессе ценность хорошего задания растёт. Если задача сформулирована расплывчато, несколько исполнителей могут быстро сделать несовместимые части. Например, один понимает «избранное» как локальный список в браузере, другой — как данные аккаунта на сервере. Оба решения выглядят правдоподобно, а вместе не дают ожидаемого продукта.
Поэтому перед запуском стоит определить четыре вещи: для кого функция, какое поведение требуется, что сейчас входит в объём работы и как проверить готовность. Это обычная продуктовая работа, которая становится особенно заметна при делегировании агентам.
Мой взгляд. Я бы оценивал такую новинку по тому, сколько времени проходит от понятного брифа до принятой функции. Количество запущенных агентов интересно технически, но пользователю сайта нужен работающий сценарий.
Вместо контроля каждого действия полезно назначить точки проверки: согласованный план, работающий небольшой фрагмент, итоговый результат. Это предложенный порядок пилота, а не требование интерфейса Cursor. Начни с него и посмотри, где тебе действительно требуется вмешательство.
Первый эксперимент: избранные статьи в блоге
Представим блог, в котором читатель хочет сохранять материалы на потом. Для первой версии ограничимся одним браузером: без регистрации, синхронизации устройств и внешней базы. Объём достаточно небольшой для проверки целиком, но включает несколько связанных частей: кнопку, хранение, список и пустое состояние.
Вот готовое задание для проекта:
Добавь в блог избранные статьи для одного браузера.
Поведение:
1. На странице статьи есть кнопка «Сохранить».
2. Повторное нажатие удаляет статью из избранного.
3. Выбор сохраняется после перезагрузки страницы.
4. Отдельная страница показывает сохранённые статьи.
5. Для пустого списка есть объяснение и ссылка на все материалы.
Границы:
Без регистрации, сервера и синхронизации между устройствами.
Не менять адреса существующих статей, SEO-метаданные и тексты.
Не подключать новые зависимости без объяснения необходимости.
Сначала изучи проект и предложи план со списком затронутых файлов.
Дождись моего согласования плана перед реализацией.
После реализации проверь обычный сценарий, повторное нажатие,
перезагрузку и недоступность хранилища браузера.
Покажи изменения и фактические результаты проверок.
Публикацию на рабочий сайт не выполняй.План нужно прочитать по смыслу. Если в нём появилась регистрация, это расширение объёма. Если нет проверки сохранения после перезагрузки, потерялось обязательное поведение. Если предлагается менять URL статей, попроси объяснить связь с задачей.
Не дроби работу на десятки агентов заранее. Сначала посмотри, какие части действительно можно делать независимо. Кнопка и список должны договориться об одном формате данных; два параллельных решения без этой договорённости создадут дополнительную работу при объединении.
Как принять результат и оценить пользу
Открой собранную версию как читатель. Сохрани статью, обнови страницу, открой список и удали сохранение. Проверь пустое состояние. Затем посмотри, что происходит, если статья из списка больше не существует. Для этого учебного сценария достаточно понятной обработки отсутствующего материала; не нужно заодно проектировать новую систему контента.
| Что проверяем | Признак готовности |
|---|---|
| Добавление | Одна статья появляется в списке один раз |
| Повторное нажатие | Состояние кнопки и списка согласовано |
| Перезагрузка | Выбор восстановлен в том же браузере |
| Пустой список | Читателю понятно, что делать дальше |
| Ошибка хранилища | Страница продолжает работать без ложного сообщения об успехе |
| Область изменений | Адреса и содержимое существующих статей сохранены |
Запиши время на постановку задачи, ожидание, проверку и исправления. Отдельно отметь число итераций, принятый результат и доступные сведения о расходе. Сравнивать полезно с похожей задачей, которую ты уже выполнял, а не с воображаемым сроком «разработчик делал бы месяц».
Если процесс оказался неудобным, определи причину. Возможно, не хватило контекста проекта, постановка была слишком широкой или больше времени заняла приёмка. Это разные выводы и разные следующие шаги. Для повторяемой проверки пригодится подход из первого eval.
Что пока не стоит обещать
В анонсе Cursor приводит показатели роста числа слитых PR у пользователей Projects. Это данные самого поставщика, а число PR не равно качеству продукта или экономии конкретной команды. Переносить такие показатели в обещание «теперь любой сайт делается в несколько раз быстрее» нельзя. Заявление компании.
Для собственного пилота отдельно выясни доступность функции, условия своего тарифа и ограничения расхода. Здесь не приводится фиксированная цена Projects: из прочитанного анонса нельзя вывести стоимость произвольной длительной задачи.
Общий контекст тоже нужно проверять. Если инструкция запуска устарела, её повторное использование не помогает. После изменения архитектуры проси актуализировать сведения о проекте и показывать, какими файлами подтверждается новый порядок работы.
С чего начать после этой новости
Выбери небольшую функцию, которая требует нескольких связанных изменений, и используй бриф выше как образец. Сначала сформулируй собственные критерии готовности. Затем проверь доступ к бете и проведи один ограниченный эксперимент.
Если пока хочется освоить базу, в блоге есть короткий маршрут:
- Cursor Rules: правила проекта — как записать постоянные требования к работе.
- Подключение MCP к Cursor — как дать инструменту доступ и проверить реальное чтение.
- Контроль цикла ИИ-агента — где нужны проверки и условия остановки.
- Все руководства по Cursor — остальные практические материалы.
Эти навыки пригодятся и при работе с одним агентом, и при делегировании целого проекта.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗