Cursor Projects: persistent coordinator across feature, migration and gardening

Cursor Projects: persistent coordinator across feature, migration and gardening

Primary source: Alexi Robbins and Fredrika Lindh, “Introducing Projects,” Cursor, September 10, 2026. In this product/company account, a human directs a coordinator that delegates to separate coding agents. Shared files accumulate architecture, research, testing instructions and preferences across workspaces. A coordinator can watch Slack and PR events, handle CI and respond during and after shipping; for features, authors describe research → plan → parallel implementation/tests → local trying → monitoring logs/bug reports. They say they used it for migrations over hundreds of PRs, ongoing design-system work and shipping Projects itself.

Conditional review: In migrations the human initially reviews each PR closely, then relaxes review after repeated fixes hold. In design-system gardening an engineer earlier corrected fixes, then coordinator starts adding lint rules when mistakes repeat; projected 20–100 touched PRs/day is explicitly a forecast, not shipped outcome. Vendor reports new users merge 30% more PRs and heavy Projects users six times as many, without randomization or accounting for user/task selection, repair, spend or business outcomes.

Limits: No auditable one-feature plan revision, reviewer decision record, customer follow-up or maintenance and incident outcomes. Persistent coordination is an architectural answer to repeated context reconstruction, not yet proof of better full-lifecycle unit economics. See ticket-driven contrasting approach, planning question, feature-to-outcome question.