How should a Cursor rollout work for a real team?

A Cursor rollout succeeds when it changes the engineering system, not when everybody gets a seat. Licenses create access. They do not create a common way to give context, review generated changes, control data, or decide whether the tool has earned its cost.

I have watched teams buy an AI editor for every developer, celebrate a week of brisk autocomplete, and then discover that each person has built a private operating model. One developer lets the agent run migrations. Another will not let it touch tests. A third keeps architecture instructions in a personal rule that nobody can inspect. Pull requests get bigger, reviewers cannot tell which assumptions came from the agent, and management points at lines generated as proof of progress. That is adoption without control.

Treat the rollout as an engineering change with an owner, a baseline, repository-owned standards, and an explicit review policy. Cursor can then shorten feedback loops without lowering the standard of evidence. If the pilot cannot show that result, adding seats only makes the ambiguity more expensive.

Buy access in stages, not all at once

Start with a small, representative cohort and a paid team plan that matches your administrative needs. Do not buy a seat for every engineer on day one. That popular move feels fair and decisive, but it removes the comparison group, floods support with beginner questions, and turns cancellation into a political event.

Pick four kinds of participant if the team is large enough: a senior engineer who knows the architecture, a mid-level engineer who handles normal feature work, someone who owns tests or reliability, and a skeptical engineer who will report failures instead of protecting the rollout. A tiny company may have two people covering those roles. Keep at least one comparable workstream on the old setup for the pilot period. You need a baseline, not a contest.

Cursor currently separates Teams and Enterprise around administration and procurement needs. Its Teams material describes centralized billing, team privacy controls, an admin dashboard, and detailed usage analytics. It positions self-service Teams for groups up to 25 people, while Enterprise adds needs such as pooled organizational usage, invoice or purchase-order billing, SCIM, a BAA for HIPAA, advanced controls, and dedicated support. Those boundaries can change, so procurement should record the capability it needs rather than hard-code a plan name into policy.

The June 2026 Cursor Teams pricing note lists Standard seats at $40 monthly or $32 per month on an annual plan, and Premium seats at $120 monthly or $96 per month annually. It also says a team can mix seat types, with separate included pools for first-party models and third-party API usage. This matters because averages hide expensive power users. Give a standard seat to the pilot cohort, observe real use, and move only sustained heavy users to a higher allowance.

Before inviting anyone, name one license owner and document four facts: who may approve a seat, when a seat gets removed, whether on-demand spend is enabled, and who receives spend alerts. Cursor says Teams bills active members rather than a block of preallocated seats and charges new members pro rata. That makes joiner and leaver hygiene part of engineering operations, not an annual finance cleanup.

A good expansion gate is boring: the cohort has completed real work for at least two delivery cycles, the review policy has survived one risky change, usage cost is understood by person and model class, and the delivery metrics have not deteriorated. Enthusiasm is not a gate. Neither is the number of prompts sent.

Set privacy boundaries before the first prompt

Decide what code and data may enter Cursor before developers paste their first stack trace. Privacy cannot be an onboarding checkbox delegated to each engineer, because the organization owns the source code, customer data, credentials, and contractual obligations involved.

Cursor's security documentation says AI requests pass through its backend even when a developer supplies a personal API key. It also says code data is sent to Cursor servers to power AI features. Under Privacy Mode, Cursor guarantees that code data is not stored by model providers or used for training, and team membership enforces that mode. That is a useful control, but it does not answer whether your company may send a particular repository or data category to a subprocessor at all.

Run a short data classification review. Identify repositories with customer records, regulated data, proprietary algorithms, production secrets, export restrictions, or client terms that limit third-party processing. For each repository, write one of three decisions: permitted under the approved team configuration, permitted only after named paths are excluded, or prohibited pending security and legal review. Put the decision where engineers can find it during work.

Use .cursorignore to exclude files that should not be indexed or sent as context, but do not present it as a security boundary. Cursor describes this exclusion as a best effort. Secrets still belong in a secret manager, test fixtures should use synthetic data, and generated logs should be scrubbed before they reach any chat. A deny list can reduce accidental context; it cannot repair a repository that stores credentials in plain text.

The security review should also cover extensions and workspace behavior. Cursor's security page says Workspace Trust is disabled by default and extension signature verification differs from VS Code. Teams that inherit a VS Code extension catalog often assume the security posture came with it. It did not. Approve a small extension list, turn on Workspace Trust where it fits your threat model, and test the actual settings on a managed machine.

Write an incident path before the pilot. If a developer sends a secret or restricted snippet, they must know whom to contact, how to preserve enough detail for investigation, and which credential or dataset owner can contain the exposure. Do not punish prompt mistakes into silence. You want a fast report, a rotation or access review, and a policy correction that prevents recurrence.

Security approval should produce a one-page decision record: plan and privacy mode, allowed repositories, excluded paths, approved models if the plan supports model controls, retention assumptions, extension policy, and incident contact. Revisit it when Cursor changes a provider, data mode, or administrative capability. A vendor badge does not freeze the system in place.

Shared rules belong in the repository

Put team instructions in version-controlled project rules, because personal prompts are invisible dependencies. Cursor's rules documentation says project rules live under .cursor/rules, use MDC files, and can be always applied, attached by file pattern, requested by the agent, or invoked manually. It also marks the root .cursorrules format as legacy. That gives a team enough machinery to scope instructions instead of feeding every convention into every request.

Start with rules that prevent expensive ambiguity: how to run tests, where architectural boundaries sit, what generated files must not be edited, how database changes are made, which validation library the codebase uses, and what evidence a pull request must include. Do not copy the whole engineering handbook. Long rules consume context, conflict more often, and become a stale second documentation system.

This is a usable first rule for a TypeScript service:

---
description: Apply when changing HTTP handlers or service methods
globs:
  - "src/api/**/*.ts"
  - "src/services/**/*.ts"
alwaysApply: false
---
- Keep handlers responsible for transport only; put business logic in src/services.
- Validate request bodies with the existing schema in src/schemas. Do not add a second validation library.
- Run npm test -- --runInBand and npm run typecheck before declaring the change complete.
- Do not edit generated files under src/generated.
- In the final response, list changed files, tests run, and any unverified assumption.

The rule names concrete paths, commands, and an output contract. A vague instruction such as "follow best practices" gives the model nothing testable. An absolute instruction such as "never change an API" can also be wrong during a planned version change. Write the narrowest rule that catches a repeated failure.

Review rule changes like code. Require an owner, a pull request, and one example showing the behavior before and after. When a rule tells the agent to run a command, verify that the command works in a clean checkout. When it references a file, make sure the path will survive the next refactor. Delete rules whose decisions moved into linters, tests, generators, or type checks; executable controls beat prose.

Do not claim that one shared rules file covers every Cursor surface. Cursor's documentation says project rules affect Agent and Cmd-K, not Cursor Tab. Its CLI documentation also says the CLI reads AGENTS.md and CLAUDE.md at the repository root alongside .cursor/rules. Decide which surfaces the team supports, test each one, and avoid duplicating contradictory instructions across formats.

For multiple repositories, keep a small canonical rules repository only if someone owns distribution. Cursor's rules documentation notes that built-in sharing across projects is not available and suggests copying or symlinking shared rules. Blind copying creates drift. Pin a version, record the source in a comment, and let each repository override only the parts that genuinely differ.

Review generated changes by blast radius

Apply the same quality bar to AI-assisted code as human-written code, then vary the review depth by blast radius. A blanket rule that every generated line needs special treatment wastes time on formatting changes and still misses a two-line authorization bug. Review the consequence, not the origin story.

Use four review classes. Low-risk work includes comments, isolated tests, and mechanical changes already guarded by automation. Normal product work includes local feature logic behind established interfaces. High-risk work touches authentication, authorization, money, personal data, infrastructure, concurrency, or public APIs. Restricted work includes production credential handling, irreversible data operations, and changes the organization has decided an agent may not perform.

Require every AI-assisted pull request to be understandable without the chat transcript. The description should state the intent, affected boundaries, tests run, assumptions that remain, and whether generated migrations or dependencies are present. Do not require developers to paste their entire prompt history. Prompt logs are noisy, may contain sensitive context, and rarely explain the final design better than a disciplined change description.

Agents may run commands only inside an approval policy that the team can state plainly. Read-only inspection and focused tests are usually easy to permit. Package installation, network calls, destructive database commands, credential access, deployment, and broad file deletion deserve explicit approval or prohibition. Cursor has administrative controls for some agent behavior on higher plans, but a written policy still matters because reviewers need to know what evidence to expect.

The author owns every line at merge. "Cursor wrote it" is not a failure category and cannot be an excuse. The author must be able to explain the changed behavior, reproduce the tests, and defend any new dependency. If they cannot, the change is not ready even when the test suite is green.

Watch for review compression. Once an agent can produce a large patch quickly, developers start submitting changes that exceed a reviewer's attention budget. Set a pull request size guideline and split independent changes. A 1,500-line mixed patch that combines refactoring, dependency updates, and behavior changes is not efficient merely because it took an hour to generate.

One failure pattern deserves explicit rehearsal: the agent changes a schema, updates application code, and generates a migration that rewrites a populated column. Unit tests pass against an empty database. The reviewer sees familiar code and approves. Deployment then locks the table or destroys a value that the rollback cannot reconstruct. The policy should force a high-risk classification, production-shaped migration test, lock assessment, backup or rollback plan, and domain-owner approval before merge.

Run the pilot on ordinary delivery work

Use normal backlog work for the pilot, because toy exercises measure tool familiarity rather than engineering impact. Pick tasks that the team already understands and that span investigation, implementation, tests, and review. Avoid the most politically important launch and avoid a week of trivial typo fixes.

Begin with a written charter. State the pilot cohort, repositories, allowed Cursor features, privacy decision, start and end dates, baseline window, support owner, review classes, cost ceiling, and expansion criteria. Two delivery cycles is usually enough to expose rules and review problems, though a low-volume team may need longer. Do not choose a duration just to make the calendar tidy.

During onboarding, have each participant complete the same real, low-risk task in their own area. Ask them to inspect the plan before edits, constrain context to relevant files, run the documented checks, and submit a normal pull request. The rollout owner observes where the instructions fail. This is not a speed contest; it is a test of whether the operating system works across people.

Hold a 20-minute clinic twice a week during the pilot. Bring one successful interaction and one failure, then extract only reusable lessons. A useful lesson becomes a rule change, a test, a short playbook entry, or a policy clarification. A personal prompting trick stays personal until another engineer reproduces its benefit.

Do not let the vendor's usage dashboard become the pilot report. Cursor analytics can show activity such as active users, tabs accepted, lines of code, requests, model usage, and resource consumption. Those fields answer whether people used the tool and where spend went. They do not answer whether the team shipped a correct change sooner.

Keep a simple issue log with these fields: date, repository, task type, Cursor surface, model, outcome, time saved or lost as estimated by the engineer, review class, defect found before merge, defect found after merge, rule involved, and follow-up owner. Estimates will be rough. Their job is to reveal repeated failure modes, not create a precise return-on-investment decimal.

At the midpoint, remove one source of friction rather than adding training. If developers repeatedly fight missing architecture context, fix the rules or repository documentation. If reviewers receive sprawling patches, tighten task slicing. If spend clusters around a model with no visible delivery gain, change the default. Training cannot compensate for a broken operating choice.

End the pilot with one of three decisions for each team or workflow: expand, continue with a specific correction, or stop. A mixed outcome is normal. Cursor may help a mature TypeScript service with strong tests while adding risk to a poorly documented data pipeline. Licensing by workflow is more rational than demanding ideological consistency across the company.

Measure delivery, not generated activity

Judge the rollout on delivery flow, quality, cost, and developer load. Lines generated, prompts sent, and tabs accepted are adoption telemetry. They are useful diagnostics, but they are terrible executive outcomes because a team can increase all three while shipping slower.

Capture a baseline from the same repositories and comparable work before the pilot. Use medians instead of averages for cycle times, and keep task type visible so one incident or major migration does not distort the story. For a small team, inspect the individual work items rather than pretending the sample supports statistical certainty.

Use repository and delivery-system timestamps for flow metrics. Use incident and issue records for quality. Use Cursor's dashboard export or Admin API for usage and spend if the chosen plan provides them. Join those datasets at the team, repository, and weekly level where possible. Do not build a surveillance table that scores individual engineers by accepted completions.

The causal claim should stay modest. A faster pilot cohort may have easier work, stronger engineers, or extra attention from the rollout owner. Compare matched task types, inspect outliers, and ask whether any concurrent staffing or release change explains the result. The purpose is a management decision under uncertainty, not an academic proof.

Set thresholds before seeing the data. For example: expand if median merge cycle improves by an agreed amount, escaped defects do not rise, high-risk review compliance stays complete, and total tool cost remains below the value of time plausibly saved. The exact threshold depends on salary, margin, release cadence, and risk. Writing it early prevents an enthusiastic sponsor from moving the goalposts.

There is one metric I refuse to use for performance management: AI-generated lines per developer. It rewards verbosity, penalizes careful deletion, invites gaming, and says nothing about customer value. If managers display it beside names, developers will optimize for the chart and hide the difficult work that produces fewer lines.

A useful final report fits on two pages. Page one states the decision, cohort, workflows, cost, delivery movement, and quality movement. Page two lists the few rule and policy changes needed for expansion, plus unresolved risks. Put raw usage exports in an appendix for operators, not in the opening argument.

Control cost without discouraging useful work

Manage Cursor cost as a mix of access and variable model consumption. A cheap seat that triggers uncontrolled on-demand usage is not cheap, while a heavy user's expensive seat may be justified if it removes days from a recurring workflow. Cost needs a denominator tied to delivered work.

Start with team-level alerts below the actual ceiling so the owner has time to investigate. Cursor's June 2026 pricing update says admins can set dollar-threshold alerts and route them through Slack or email. Assign a person to respond. An alert sent to an unattended channel is decoration.

Review spend weekly during the pilot by person, model class, and workflow, but investigate patterns rather than scolding the top user. High usage may indicate a productive agent workflow, repeated failures, an oversized context, or work that should be automated outside the editor. Read a sample of the work and its outcomes before changing allowances.

Create a simple exception rule. The standard allowance covers ordinary work. A developer who reaches it can request temporary on-demand access or a different seat by naming the task, expected duration, and evidence they will bring back. The approval should take minutes, not a procurement cycle. Slow exceptions teach people to use personal accounts, which destroys both cost visibility and privacy enforcement.

Do not force every request onto the cheapest model. Model switching has a labor cost when a weaker model fails repeatedly or produces review-heavy patches. Choose defaults by task class: fast completion for local edits, a stronger reasoning model for bounded complex work, and human-only handling where policy restricts agents. Then test whether the expensive class actually improves the outcome.

Include internal operating time in the cost. The rollout owner, security reviewer, rule maintainers, clinics, and added review all consume hours. Some of that cost falls after the pilot as standards settle; some becomes permanent. A return calculation that counts developer minutes saved but ignores reviewer time is fiction.

Cancel unused seats promptly and keep departure handling in the same checklist as repository and identity access. For contractors, set an end date when granting access. Quarterly seat cleanup is too slow for short engagements and too easy to forget.

The economic decision should be made per workflow. Keep Cursor where it lowers total delivery cost at an acceptable risk. Change rules or training where the potential is clear but execution is poor. Remove it where usage stays ceremonial or review cost consumes the gain. Software does not deserve a permanent budget because the team once announced a transformation.

Make the standard survive its sponsor

Assign durable ownership before expanding the rollout. One person owns licensing and spend, one owns security decisions, repository maintainers own local rules, and engineering leadership owns the review policy and outcome metrics. In a small company, one person may hold several roles, but the responsibilities still need names.

Store the charter, policy, and decision record beside existing engineering documentation. Store project rules with the code they govern. Add rule review to normal repository ownership, not a separate AI committee that meets after standards have already drifted. The closer a control sits to the work, the more likely it stays accurate.

Run a monthly review for the first quarter after expansion. Examine cost exceptions, incidents, escaped defects involving generated changes, stale rules, unsupported repositories, and workflows where the delivery gain disappeared. After the system settles, move to a quarterly review plus event-driven checks for major plan, model, provider, or policy changes.

New hires need the review policy and a supervised change, not a tour of clever prompts. Give them the repository rules, show how work is classified, and ask them to explain an AI-assisted patch before it merges. This teaches accountability and reveals whether the documentation can stand without the original champion in the room.

This is also where an external Team & AI Audit can earn its fee: it should connect seats, rules, review effort, delivery data, and payroll economics rather than grade the team on tool enthusiasm. The stated offer is a five-business-day, $5,000 audit with at least $50,000 a year in identified savings or the fee is waived. That is a sensible bar only when the evidence comes from the engineering system, not a projection based on generated lines.

Cursor will keep changing its plans, models, and controls. Your policy should name required capabilities and risk decisions so it can absorb those changes without a rewrite. Keep evidence close to the code, give reviewers authority to stop unsafe work, and expand only where delivery data supports the expense.

The first action is not purchasing seats. Write the expansion gate and review classes, select the pilot work, and record the baseline. If leadership cannot agree on those three things, the team is not ready to learn anything from a rollout.