AI IDE Pilot Plan for 100 Developers

Four controls decide whether security will sign off: who has access, what the policy allows, how data moves and whether anyone measures adoption. Settle them before the pilot starts, because they apply whichever tool you pick.

The owner column matters as much as the controls. A control with no named owner goes unchecked until someone has to answer for it. If nobody owns identity, for example, nobody checks that people who leave lose access.

Security does not own all four. Identity is IT's system of record, and policy is engineering leadership's call about what the team may ship. Adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and it will ask about both.

Data flow is the question that stalls approvals, so answer it before the review meeting. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of the answers come from the vendor's documentation and your own configuration. Ask the vendor for anything the documentation leaves out, and note where each answer came from.

The stack below breaks a rollout into layers. Policy comes first because the other layers carry it out. Identity controls who gets access, workflow moves code from prompt to merge, and measurement shows whether the rollout is working.

Start narrow, and expand only when the pilot earns it.

1. 1Week 1: pick one team, one repo and three realistic tasks.
2. 2Week 2: write the workflow standard from the pilot.
3. 3Week 3: train champions and add policy guardrails.
4. 4Week 4: expand only after quality, cost and review load are visible.

Treat the four weeks as an order, not a deadline. The first two weeks mostly show you what your standard should say. A pilot too broad to watch closely can't teach you that, so it starts with one team and a few real tasks. Pick the team that will tell you when something breaks, even if another team would produce a better-looking result. Put policy and training in place before the rollout grows, because both are harder to add once people have formed their own habits.

Expansion is the step to slow down. After a good pilot, the pressure to widen access can arrive before the evidence does. Before you add teams, answer three questions with numbers: did review load go up or down, what does a developer cost per month, and did quality hold.

Record the same numbers before the pilot starts, so you have a baseline to compare against. Two more weeks of the same pilot cost less than a rollout you have to walk back, so run them if any answer is still a guess.

Cursor ships often, so advice about it can go out of date. The table summarizes Cursor's recent releases, so you can check this page against the current product. For each release's date and sources, see What's new in Cursor 2026.

Because a cohort can carry its own settings. On Cursor Enterprise, Organization Groups gather people from different teams into one group, and Cursor's own examples are Engineering, Contractors and Pilot Users. A group can hold per-user spend limits, model access and agent controls, and the Cursor Router can be configured per group as well. Group settings combine with team settings toward the most permissive result, so the team default stays strict while the pilot group gets wider access.

That makes a staged rollout mechanical. You can give the pilot group a model before the rest of the organization gets it, without loosening anything for people outside the group. Membership can sync from your identity provider through SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition., or admins can manage it in the dashboard, by CSV import or through the Organization API.

Billing Groups are a different object. They attribute spend for reporting and chargeback and carry no settings, so a cohort built as a Billing Group can't hold a model-access rule.

The payoff arrives in the second month, when someone senior asks to add forty people. With an Organization Group, that request is a membership change. With a blanket switch-on, it becomes a new negotiation about what everyone is now allowed to do.

Identity, in the order Cursor documents: SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. first, then SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition., then MDM policies, then roles. The order follows from the dependencies. SCIM 2.0 provisioning is available on Enterprise plans with SSO enabled, so it can't go first. MDM policies then enforce the allowed team IDs on company devices.

Don't defer MDM. Setting the allowed team ID on managed devices stops employees from signing in with personal accounts that might not have Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. enabled. Somewhere between ten developers and a hundred, the odds that at least one person does that stop being theoretical.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. matters for the opposite reason: people who leave. A membership list managed by hand works while you can hold the names in your head. At a hundred names it goes stale quickly, and removing access then depends on someone remembering instead of on the directory.

Set this up before the invites go out, not alongside them. If you retrofit SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. afterwards, you spend the pilot reconciling two membership sources, and the measurement suffers.

Decide first whether the pilot runs on per-seat allowances or on a pool, because the two fail differently. On a Teams plan, each paid seat has its own allowance: a weekly pool on The X SubscriptionThe subscription Cursor is sold through: one plan for Grok, Cursor and X, with Free, Plus, Premium, Super and Ultra tiers, per-seat Teams, a weekly included pool for Cursor models shared with Grok, and third-party models billed at API list price from prepaid credit. Press Enter for the full definition., or a monthly one on legacy seats, where Premium gets five times Standard's at three times the price. Allowances never combine, so one heavy user runs out while teammates still have headroom. Enterprise pooled usage replaces per-seat allowances with one amount committed for the contract period, and that budget is available to whoever needs it.

What happens when included usage runs out depends on the plan, and it is the detail that catches finance. On legacy Teams seats, on-demand usage is on by default, so work continues and bills monthly in arrears, and the first sign of uneven use can be an invoice. On The X SubscriptionThe subscription Cursor is sold through: one plan for Grok, Cursor and X, with Free, Plus, Premium, Super and Ultra tiers, per-seat Teams, a weekly included pool for Cursor models shared with Grok, and third-party models billed at API list price from prepaid credit. Press Enter for the full definition., usage past a seat's weekly pool comes from the team's prepaid balance. It stops when that balance runs out or the team reaches its monthly limit, unless Auto Top-up refills the balance first. Cursor's pooled-usage page doesn't say what happens when an Enterprise pool is used up, so ask before the pilot starts.

Set both limits before rollout. The team-wide limit caps the account, and the per-member limit caps each person, although Cursor's help center lists only the team-wide limit for legacy Teams plans. On Enterprise pooled accounts, a member limit applies to total usage, not only the on-demand part, which makes it a different control from the same setting on a Teams plan. Dynamic Spend Limits move the team cap as headcount changes, which matters in a pilot whose point is that headcount changes.

In two of its three modes, the router sets the price of each request. Cursor Router powers Auto on Teams and Enterprise plans. In Balance and Intelligence, each request bills at the list price of the model it is routed to. Cursor's router docs say both modes use up usage limits faster than Cost, without saying how much faster.

Cost mode keeps the previous Auto routing logic. The router docs and the team pricing page say it bills as a Cursor-model request, but Cursor's router help page says all Auto modes bill at the routed model's list price. Confirm which one applies before you budget on Cost mode.

Check the default on day one, because it differs by plan. The router is on by default for Teams plans, and Cursor's help center says Balance is the default mode for new users. So on Teams, developers who pick Auto can bill at routed rates before anyone has decided they should. On Enterprise, the router stays off until an admin turns it on. On either plan, admins choose which modes members can pick and set the team's default mode.