AIREITERCursor’s coordinator-and-subagent design is genuinely useful for large codebase migrations—but not as an unattended rewrite button. The architecture helps most when work can be split into bounded, testable slices; it becomes risky when agents share contracts, files, or undocumented business rules. The “Projects” label is also worth treating carefully: current official material is centered on subagents, async execution, cloud agents, and long-running coding rather than a single, consistently documented Projects product page.
What Cursor Projects beta actually gives migration teams
Cursor’s current subagent documentation describes a parent Agent delegating specialized tasks into separate context windows. A subagent returns a result to its parent, can run in the foreground or background, and can be configured with its own tools, model, and write permissions.
That is the useful architectural unit for a migration: one coordinator maintains scope and decisions, while specialists explore the repository, implement bounded changes, run tests, or review the result. Cursor also documents cloud subagents with their own virtual machine, branch, and repository clone, which is materially safer than letting several agents edit one checkout.
The beta caveat matters. A February 2026 Cursor release discussion announced asynchronous and nested subagents, but users reported unreliable background triggering; a Cursor staff reply said an is_background: true issue was expected to be fixed in Cursor 2.6. Treat availability and behavior as version-dependent, not as a guaranteed control plane.
The migration workflow that benefits from coordination
A coordinator is valuable when it owns the sequence, not when it tries to write every line. For a framework or language migration, use the following division of labor:
| Role | Useful output | Why it belongs in a separate context |
|---|---|---|
| Repository explorer | Dependency map, entry points, generated-code boundaries | Search output can overwhelm the main thread |
| Migration planner | Ordered work packages and invariants | Planning needs a whole-repository view |
| Implementer | Changes in one module, service, or worktree | Narrow scope reduces unrelated edits |
| Test agent | New and existing checks for one slice | Test logs are verbose and independently actionable |
| Reviewer | Regression, security, and convention findings | A fresh context is less invested in the implementation |
| Coordinator | Contract checks, conflict decisions, next wave | One place must reconcile incompatible outputs |
Cursor’s long-running coding report describes a similar planners-workers-judge structure. In its Solid-to-React experiment, Cursor reports more than three weeks of work and approximately 266,000 additions plus 193,000 deletions, while noting that careful review was still required. That is evidence the architecture can sustain a large effort, not evidence that a migration is production-safe by default.
Where the architecture helps in large codebases
1. Inventory and dependency mapping
Large migrations fail early when the team misses a call site, build script, generated file, or deployment assumption. A dedicated explorer can search those surfaces while the coordinator turns findings into a migration ledger.
This is stronger than asking one agent to “migrate the repository” because the output is inspectable: affected packages, dependency edges, public interfaces, test coverage, and unresolved assumptions. Cursor’s modernization guidance recommends Plan Mode, .cursor/plans/, and migration rules such as .cursor/rules/migration.mdc.
2. Repeated, bounded transformations
Subagents are a good fit for changes such as updating deprecated API calls, converting contained modules, or migrating services with stable interfaces. The safe boundary is not simply a folder name. It is a slice with:
- A named owner and file scope.
- A written input/output contract.
- A build and test command.
- A branch or isolated worktree.
- A clear definition of done.
Cursor’s documentation warns that several subagents sharing the default checkout can overwrite one another. Isolated worktrees or cloud branches keep changes separate until the coordinator or human merges them.
3. Maintenance queues and background verification
Maintenance work often has natural parallelism: investigate flaky tests, inspect dependency warnings, update documentation, and review a pull request can proceed independently. Background execution keeps the parent responsive, while cloud agents can continue on their own virtual machines.
For review, Cursor’s Agent Review documentation provides Quick and Deep modes. Deep review is slower and higher cost, and Cursor recommends it for complex logic, security-sensitive code, and large refactors. The Source Control workflow compares the full local change set with the main branch, rather than only the newest edit.
That makes the architecture useful for maintenance, but the review must remain a gate. A passing child-agent report is not equivalent to a passing integration test or an approved pull request.
Where coordinator-and-subagent workflows break
Cross-cutting contracts reduce safe parallelism
Frontend, backend, database, and service changes cannot always be parallelized just because they live in different directories. A schema change can invalidate an API; an API change can invalidate generated clients; a shared utility can make two apparently independent edits collide.
A Cursor forum feature request for a “Monorepo Execution Plan” describes the missing discipline well: scoped workers should receive global requirements, API contracts, and schema changes, then a coordinator should validate routes, types, and schemas before integration. That post is a request, not proof that every part of this workflow is turnkey today.
For migrations, freeze contracts before spawning implementation agents. If a contract must change, create a compatibility phase or make that change the coordinator’s next serialized decision.
Context isolation is also context loss
Subagents begin with a clean context; they do not automatically inherit the parent conversation. The coordinator must pass the relevant rules, target patterns, constraints, and artifacts explicitly. A short summary can omit the exact edge case that matters six hours later.
Use durable artifacts instead of conversational memory:
migration-plan.mdfor scope and sequencing.migration-ledger.csvfor package status and exceptions.contracts/for API and schema snapshots.decisions.mdfor rejected alternatives.- A test report attached to every implementation branch.
This also addresses stale decisions. A persistent coordinator can preserve history, but history is not automatically truth. Re-validate assumptions after dependency upgrades, schema changes, or a newly discovered legacy behavior.
More agents can mean more cost and interference
Cursor’s documentation estimates that five parallel subagents use roughly five times the tokens of comparable single-agent work. The same documentation says model selection can fall back when an administrator blocks a model, the plan does not support it, or a legacy plan requires Max Mode. Do not budget from the parent model alone.
Real-user feedback shows why this needs an explicit control loop:
“too few and messages are queued forever, too many and they start interfering with each other” — @siggelabor, X
A Reddit discussion reports users seeing subagents consume unexpected model usage and relying on .cursorrules to discourage delegation, while noting that the rule was not guaranteed. Cap concurrency, assign cheaper models to exploration, reserve stronger models for planning and review, and inspect usage before expanding the next wave.
Passing tests does not prove a migration happened
The SWE Refactor Bench preprint is a useful warning for any Cursor Projects review. Across 520 runs involving 20 whole-repository migration tasks, only 28 runs—5.4%—passed migration audit, fixed behavioral tests, and adversarial verification. The paper also found that language rewrites averaged 5.6/100, compared with 31.4/100 for build-toolchain rewrites.
The lesson is methodological: a migration needs separate gates for replacement and preservation. Check that the old stack is absent from source and build closure; then compare behavior; then use independent verification to find hidden differences. “CI is green” is one signal, not the verdict.
A safer way to use Cursor for a migration
- Baseline the old system. Record build commands, public interfaces, representative outputs, performance-sensitive paths, and known exceptions before changing code.
- Ask a read-only explorer to map the repository. Include packages, generated artifacts, configuration, deployment scripts, and test gaps.
- Create a migration plan and ledger. Split by behavior and ownership, not only by directory.
- Pilot one contained slice. Use a migrated reference implementation to establish naming, error handling, compatibility, and test conventions.
- Spawn bounded implementers in isolated branches. Put the exact contract and forbidden paths in each prompt.
- Run local validation per slice. Require type checks, unit tests, integration tests, build output, and a diff summary before reporting success.
- Run an independent review. Use a fresh reviewer, and choose Deep Agent Review for high-risk or cross-cutting changes.
- Integrate in waves. The coordinator reconciles contracts; a human approves merges involving data, authentication, infrastructure, or public APIs.
- Re-run differential checks. Compare the migrated system with the baseline on representative inputs and failure paths.
- Stop when evidence worsens. More parallelism is not progress if queues, conflicts, retries, or review findings increase.
Cursor Projects beta verdict by workload
| Workload | Fit | Recommendation |
|---|---|---|
| Repetitive changes across independent modules | High | Use parallel implementers with isolated branches and shared rules |
| Dependency or framework upgrade | Medium-high | Plan first, pilot one module, then expand in waves |
| Large language rewrite with weak tests | Medium-low | Use agents for inventory and slices; keep behavior validation human-led |
| Cross-service schema and API migration | Medium | Serialize contract decisions and parallelize only implementation after the contract is stable |
| Ongoing test, PR, and dependency maintenance | High | Use background/cloud agents with concurrency and cost caps |
| One-off formatting or changelog work | Low | Use a command or skill; a subagent adds unnecessary overhead |
| Deterministic bulk rename with strong tests | Medium | Prefer scripts and CI when the transformation is mechanical and easily reversible |
My judgment: Cursor’s coordinator-and-subagent architecture is worth piloting for large migrations when the repository has testable boundaries and the team can enforce branch isolation. For a poorly documented system with weak behavioral coverage, use the coordinator as an inventory and verification manager, not as an autonomous implementer.
Cursor Projects beta FAQ
Is Cursor Projects beta the same as Cursor subagents?
Cursor’s official documentation is organized around subagents, async execution, cloud agents, and multi-agent coding; “Projects” is a beta label whose scope may vary by version and account.
Can Cursor subagents run in parallel?
Yes, but independent tasks still need explicit scopes, contracts, and isolated worktrees to avoid conflicts.
Can a subagent spawn another subagent?
Cursor documents nested subagents. Use nesting sparingly because deeper trees increase coordination, token, and verification overhead.
Will agents keep working after I close my laptop?
Cloud subagents can continue on their own virtual machines; Cursor notes that local MCP configuration is not automatically reused in the cloud.
Can I force a particular model for each subagent?
Cursor supports inherited or specific models, but administrator, plan, and legacy-plan rules can trigger fallback, so verify actual usage.
How do I stop subagents from spawning?
Use task instructions and repository rules, then verify behavior for your plan and version; user reports suggest these controls are not always guaranteed.
The decision to make before enabling a swarm
Run a one-week pilot on one migration slice. Adopt only if escaped regressions do not increase and the time saved exceeds coordinator rework, reviewer time, and model-usage overhead. If not, use scripts, CI, or a single agent for that class of change.