Cursor shipped Projects on September 10, 2026, and the detail worth stopping on isn't the rebrand. It's that the coordinator agent inside a Cursor Project decides when to start work without a person prompting that specific run, including when a PR merges. A Project is a persistent workspace that holds context over "months of work" (per Cursor's Projects changelog), and its coordinator doesn't write code itself; it plans the work and delegates it to implementation subagents, up to "thousands" running in parallel (per Cursor's Projects announcement). That handoff, from a human deciding what happens next to an agent deciding when to act, is the actual news.
What Cursor Projects actually is
Forget the chat window most developers already associate with Cursor. A Project runs on its own computer in the cloud, so closing your laptop doesn't stop it. When something needs to run on the developer's own machine, a local test suite, say, the coordinator spins up a local agent and hands control back once it's done.
Everything the coordinator and its subagents learn gets written to a set of shared context files that sync across every cloud and local machine touched by that Project. Research notes, codebase observations, stated preferences, they accumulate in one place instead of dying at the end of a chat session. That's the mechanism that lets a Project hold "months of work" without resetting every time someone opens a new tab.
What the coordinator can do without being asked
A chat-based coding assistant waits. You open it, you ask it something, it answers. A Project's coordinator doesn't need that opening move. Cursor built it to run on subscriptions: it can watch a Slack channel and delegate when a new message lands (Cursor's own example is a bug-report channel), run on a fixed schedule, or follow every open pull request, fixing CI and acting when PRs open or merge (per Cursor's list of subscription triggers).
That last mode is worth reading twice. Cursor's own phrase, "acting when they open or merge," names a PR merging as one of the events that can set the coordinator's next move in motion, not something the coordinator does to the PR. Cursor doesn't say the coordinator performs the merge. A merge, like a Slack message landing in a watched channel or a scheduled run firing, is a trigger, not an action the coordinator takes.
What Cursor claims about the results, and how much weight that claim can carry
Cursor says new users who adopt Projects merge 30% more pull requests, and users who primarily rely on Projects merge six times as many (per Cursor's reported figures). Those are the numbers most launch coverage will lead with.
Worth naming plainly what they are: Cursor's own aggregate self-report, published on its own blog, drawn from users who opted into a new beta feature, with no methodology, sample size, control group, or disclosed baseline for what counts as a "new user." Self-selection alone can explain a gap this size without any causal claim about the tool. Teams that adopt a beta automation feature early are already automation-forward and already merging faster than average, so comparing their after number to their own before number, with no control group, tells you very little about what Projects itself caused.
There's a second problem underneath the first: a merged PR isn't the same thing as a correct one. Cursor's numbers say nothing about review depth, rework, or defect rate, the same gap we flagged in DX's "time to 10th pull request" metric, a shipping-velocity proxy, in how AI-assisted ramp time gets measured, and where vendor claims fall short. That piece, along with what the research on AI-assisted developer speed actually shows, already covers how much faster AI makes developers. Don't treat "30% more PRs merged" as an independent finding about developer output; it's a vendor's own number about a new feature it sells.
The real question: what stays gated when a human isn't choosing when work starts
Here's the actual shift. A coordinator that plans, delegates to thousands of subagents, and can start or continue work on a PR event, a CI event, a schedule, or a Slack message, without a person prompting that specific run, moves the decision about when something happens from a person to the system itself. For a lot of teams, review capacity was already the constraint before Projects existed. Automating the part that wasn't the constraint doesn't remove a bottleneck; it lengthens the queue in front of it.
Cursor's own examples show what that shift looks like, and none of them describe a coordinator that skips review. In a migration example, a team reviews each PR closely early on, reviews less as the fixes hold up, and the coordinator "keeps working through the migration on its own" (per Cursor's migration example). Its changelog puts the same pattern from the other side: the coordinator "brings the finished work back to you to check."
That's a real pattern, worth taking seriously without inflating it. The coordinator initiates and continues work unprompted; a human still checks the result, at a cadence Cursor's own examples show dropping as trust builds. This tracks with a shift already underway: the senior engineer's job has shifted from writing code to reviewing and architecting it. A coordinator that decides when work starts raises the stakes on that shift, because how often a human checks in is now a policy a team sets deliberately, one Cursor's examples show can loosen over time. Automating initiation doesn't fix the productivity problems that predate any AI tool; a team whose real constraint was context switching just moves that constraint closer to production.
What to require before turning this on
Four things, in order of how often teams skip them.
Branch protection with required human approval on every repo path the coordinator can touch, configured independently of whatever permissions Cursor's own product offers. Don't treat a vendor's default settings as your control; set your own and verify it holds.
An audit trail per merge: which subagent acted, which trigger fired it (Slack message, schedule, CI event, PR opening), what changed, and who, if anyone, reviewed it. If you can't answer those questions for a merge from six weeks ago, you don't have a review gate. You have a hope.
A defined scope for unprompted action. Decide up front which repos and which signal types are allowed to trigger a merge versus just a draft PR sitting in review. "The coordinator can act on CI and PR events" is a capability description, not a policy. Write the policy yourself.
A named owner for what happens when a change the coordinator started without being prompted causes an incident. "The coordinator did it" is not an incident owner. Someone signed off on letting it act unprompted in that repo, and that person is accountable when it goes wrong, the same way a manager stays accountable for a junior engineer's mistakes, not the tooling.
None of this is a reason to skip Projects. It's a reason to treat "should we turn this on" as a policy decision made before adoption, not written up after an incident. Teams whose review process was already thin before a coordinator could start work unprompted will find that thinness faster now.
FAQ
What is the coordinator agent in Cursor Projects?
A coordinator is the planning layer of a Cursor Project. It doesn't write code itself; it plans the work and delegates implementation to other agents, up to thousands of subagents working in parallel, according to Cursor's September 10, 2026 announcement.
Does Cursor's coordinator agent act on pull requests without a person prompting it?
Yes. Cursor says the coordinator can "follow all your PRs, fixing CI and acting when they open or merge," without a person prompting that specific run. What Cursor doesn't document is the coordinator performing the merge itself; its examples describe a human checking in less often as its work holds up, not a human removed from the decision. Whether a merge happens without someone's sign-off comes down to the branch protection a team sets, not a capability Cursor claims.
Are Cursor's 30% and six-times PR numbers a reliable productivity measurement?
No. Both figures are Cursor's own self-reported aggregate statistics, published on its blog with no disclosed methodology, sample size, or control group, drawn from users who self-selected into a new beta feature. They describe what Cursor says happened among its own early adopters, not an independently verified result, and "PRs merged" says nothing about code quality.
What should a team put in place before letting an AI coordinator start work unprompted?
At minimum: branch protection with required human approval on any repo the coordinator can touch, an audit trail linking every merge to its trigger and any reviewer, an explicit list of which signal types (schedule, Slack, CI, PR events) can trigger action, and a named owner for incidents an unprompted action causes.