AI IDE Pilot Plan for 100 Developers

AI IDE pilot for 100 developers is a governance question before it is a tooling one. Four controls decide whether security can sign off: who has access, what the policy allows, how data moves, and whether anyone is measuring adoption. The table assigns each an owner.

The owners column matters more than the controls themselves, which I realise is a slightly odd thing to say about a governance table. But a control with nobody's name against it is a control nobody checks, and it fails at exactly the moment someone has to answer for it. The usual mistake is assuming security owns all four. They don't. Identity is IT's system of record, policy is an engineering-leadership call about what the team is allowed to ship, and adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and they will ask about both.

Data flow is the one that stalls approvals, so answer it before the meeting rather than during it. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of that comes straight from the vendor's documentation and your own configuration. It's dull work, but it turns a vague objection into a specific one, and specific objections are the kind you can actually close.

A rollout works when it starts narrow and earns its expansion. One team, one repo and a few real tasks in week one, with policy and training in place before anyone scales it wider.

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.

Four weeks is a shape, not a rule. The dates matter much less than the order, and the reason to start with a single team is that those first two weeks are mostly you finding out what your standard should even say. You can't write that from a pilot too broad to watch properly. Pick the team that will tell you when something doesn't work, rather than the team most likely to hand you a good result.

Expansion is where this usually goes wrong. Not because anyone's careless, either — the pilot went well, someone senior noticed, and now there's pressure. That's a hard thing to say no to. Before you add teams, though, check that you can answer three things with numbers instead of impressions: did review load go up or down, what does a developer actually cost per month, did quality hold. If any of those is a shrug, another fortnight of the same pilot beats a rollout you have to walk back.

Cursor ships often, so here is the current state of the surfaces this page touches. Each row links to the source where you can confirm the detail.

Because the cohort is the thing that carries settings. Organization Groups gather people from different teams into one group, and Cursor's own examples for them are Engineering, Contractors and Pilot Users. Each group can hold per-user spend limits, model access and agent and model-routing controls, and group settings combine with team settings permissively, so the team default stays strict while the pilot group gets the wider access.

That is what makes a staged rollout mechanical instead of aspirational. You can give a pilot group early access to a new model before a wide rollout without loosening anything for the other ninety developers, and membership can come 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 be driven through the Organization API rather than maintained by hand.

Billing Groups are a different object. They attribute spend for reporting and chargeback, and that is all they do, so a cohort built as a Billing Group will not carry a single model-access rule with it.

Calling the cohort a settings container is accurate and undersells it. 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, and with a blanket switch-on it becomes a fresh negotiation about what everyone is now allowed to do.

Identity, in Cursor's documented order: 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 sequence is not a matter of taste. SCIM 2.0 provisioning is available on Enterprise plans with SSO enabled, so it cannot go first, and the MDM controls exist to enforce decisions the earlier layers have already made.

MDM is the layer that tends to get deferred. Setting the allowed team ID on managed devices stops employees 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, and the odds of at least one person doing that stop being theoretical somewhere between ten developers and a hundred.

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. earns its place for the opposite reason: leavers. A hand-managed membership list is fine while you can hold the names in your head, and a hundred of them goes stale inside a month, at which point access removal depends on somebody remembering rather than on the directory.

Do this before the invites go out, not alongside them. 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 and you spend the pilot reconciling two membership sources, and the measurement is what loses.

Decide first whether the pilot runs on per-seat allocations or on a pool, because the two fail differently. On a Teams plan a Standard seat gets one allocation and a Premium seat gets five times that at three times the price, and those allocations never combine: one heavy user goes on-demand while teammates still have headroom. Enterprise pooled usage puts the budget in one place, drawn in the order requests arrive with no per-member reservation.

The detail that catches finance is what happens when the pool runs out. On-demand usage does not gate access, it continues and bills in arrears, so the first signal that consumption was uneven can be an invoice.

Set both limits before rollout. Team-wide caps the account, per-member caps the individual, and on pooled accounts a member limit applies to total usage rather than only the on-demand part, which is a genuinely different control from the Teams-plan version of the same setting. Dynamic Spend Limits move the team cap as headcount changes, which matters when a pilot's whole point is that headcount changes.

Then check the routing mode, which sits underneath all of it. Auto is router-powered on Teams and Enterprise plans. Cost mode keeps the previous Auto routing logic and its bundled pricing; Balance and Intelligence bill per request at the routed model's rate, which Cursor puts at roughly twice Cost mode on average and up to two to four times depending on the mode.

The router is on by default for Teams plans, so a hundred developers can be spending at the routed rate without anyone having touched a model picker.