“One person directing thousands of AI agents to take on large-scale development” — put that in a headline and my first reaction is marketing fluff.
But take apart Cursor’s Projects, released September 10, and there’s real substance in there. And the substance isn’t in the “thousands” number.
What it actually changes: you stop managing agents. You only manage tasks.
First, the pain: for the past year, the exhausting part wasn’t writing code — it was managing agents
If you started using Cursor, Claude Code, or similar tools last year, you’ve probably gone through the same phase:
At first it’s great — one agent helps you edit one file. Then you open two, three, letting them handle different modules. Then you realize the most draining action in your day isn’t writing code — it’s switching between agent windows, copy-pasting context, and checking whether they’ve gone off track.
That’s the real bottleneck of AI coding over the past year — not that models aren’t smart enough, but that human attention bandwidth isn’t enough.
Once the number of agents goes up, management cost scales exponentially: context has to be fed repeatedly, task boundaries have to be re-explained, and every finished job has to be verified one by one. You’re nominally “directing,” but in practice you’re doing grunt work.
Cursor’s approach this time is blunt: add a Coordinator, let it manage the subagents, and you only talk to the coordinator.
The three pillars: cloud-resident, shared context, proactive triggering
The official architecture has three parts. I’ll rank them by “which one is actually worth money.”
1. Shared system context (the most valuable piece)
Each Project maintains a set of continuously synced files where agents deposit research findings, their understanding of the codebase, and your preferences.
This is the core. Because the biggest pitfall of multi-agent setups is context loss — what agent A figured out, agent B knows nothing about, and you have to explain it all over again.
With shared context, the coordinator gets better and better at understanding your project over time. This isn’t “smarter” — it’s not having to re-explain. What you save is dozens of copy-pastes a day.
2. Cloud by default, local testing on demand
Each Project runs on its own cloud machine, and closing your laptop doesn’t interrupt it.
This solves the compute problem: a local machine can’t handle dozens or hundreds of agents running in parallel, but the cloud can. When local testing is needed, the coordinator spins up local agents automatically.
For indie developers, the practical meaning is: you can clock off, and the task won’t stop.
3. Smart subscriptions: it comes to you
The coordinator can monitor Slack channels, run on a schedule, track all PRs, and act on its own when it detects a signal — no need for you to call out every time.
For example, a PR gets flagged in review, CI breaks, an anomaly shows up in the logs — it can pick it up and handle it itself.
This is the dividing line between “tool” and “colleague.” The first two are efficiency gains; this one changes how you work.
Three real-world scenarios, and which one you can use right now
The official material gives three categories, but they’re at different maturity levels. I’ll rank them by “would I dare use this now”:
| Scenario | What it does | My take |
|---|---|---|
| Feature development | Research → build context → coordinator makes a plan → subagents implement and test in parallel → monitor logs and fix bugs after launch | Good for mid-sized features with clear boundaries |
| Large-scale code migration | Hundreds of PRs advanced step by step, heavy human review early, autonomous once the approach matures | Most worth trying, migration is inherently grunt work |
| “Gardening” maintenance | Code quality monitoring, regression testing, e.g. auto-extracting design system components and generating rules | Big long-term value, but you need to build context first |
Large-scale migration is the most practical scenario right now. Framework upgrades, style replacements — these jobs are “easy to start, brutally hard to finish.” You get halfway through hundreds of files and you’re already numb. Handing this to a coordinator, watching it closely early on, then letting it roll once the approach works — that’s where the payoff is clearest.
“Gardening” maintenance sounds vague, but it’s actually the most profitable long term: it doesn’t need you to issue commands each time, it just watches code quality on its own. The catch is that shared context has to be built up first, or it won’t understand your conventions.
How to read the official numbers: 30% and 6x — don’t let the latter go to your head
Cursor says it tested internally for several months, used on hundreds of PRs for migrations and feature releases. The numbers:
- New users merged 30% more PRs
- Users who mainly rely on Projects merged 6x as many PRs
These two numbers need to be read separately.
30% is “an ordinary person gets some use out of it.” That number is actually more credible, and closer to most people’s real experience.
6x is a specific group — “users who mainly rely on Projects.” Note that qualifier: not everyone, but people who moved their entire workflow onto Projects. And this is vendor self-reported data with no disclosed sample methodology.
My reading: 6x isn’t the number you’ll get — it’s the upper-bound reference for “after you fully switch your workflow.” If you just occasionally spin up a Project to try it, you’ll most likely land in the 30% bucket, or lower — because you still have to spend time learning how to use it.
Don’t take 6x to your boss.
Should you adopt it now: three types of people can jump in, two should wait
Can jump in:
- Teams doing a big migration. Hundreds of PRs, Projects pays off most directly, and migration tasks have clear boundaries and room for error.
- Indie developers / small teams. You never had the manpower for coordination anyway. Cloud-resident plus proactive triggering is basically a free “person on duty.”
- People already heavy Cursor users. Your context and habits are already in there, so migration cost is lowest.
Better to wait:
- People with small codebases and fragmented tasks. Starting a Project and building context has a cost. If all your tasks are “change a button color,” you don’t need it.
- Teams with extremely strict code review requirements. In beta, the volume of early human review won’t be small. Don’t expect full automation from day one.
One more practical issue: this is beta. The official line is it’s rolling out gradually to all users starting today — “gradually” means you might not have it yet.
One-line summary
Projects isn’t selling “thousands of agents” — it’s selling shared context + proactive triggering. The former means you don’t re-explain; the latter means you don’t re-issue commands. Solve those two, and people genuinely go from “managing agents” back to “managing tasks.”
As for “one person doing a team’s work,” it’s too early to conclude. But the direction is right: competition in AI coding has shifted from “whose model is stronger” to “who can save more of a human’s attention.”
In your current AI coding workflow, what’s the most draining step? Feeding context, or verifying results? Tell me in the comments — I want to see if we’re all stuck in the same place.