AI IDE Pilot Plan for 10 Developers

AI IDE pilot for 10 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.

Less than the approval process usually assumes, because Cursor bills per active user rather than pre-purchased seats. A Standard seat lists at $40 monthly, or $32 per seat per month on an annual plan, and new members are charged pro-rata for the remainder of the cycle. Ten of those is a figure you can say out loud in one sentence, which changes who needs to sign it off.

Whoever runs the pilot does not have to burn a licence to do it. An Unpaid Admin manages billing and security settings without consuming a seat, so the ten seats can all go to people writing code.

Stopping has a shape too, and it is worth knowing before you promise finance a clean exit. If a removed member consumed any credits their seat stays occupied until the billing period ends, and removal permanently deletes that person's Memories and Cloud Agent data.

So the exit is cheap, just not instant, and anything a pilot developer wanted to keep out of their agent history has to leave Cursor first.

There is a whole identity stack you can skip at this size, too. 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. provisioning needs Enterprise with SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. enabled, and across ten named people a hand-managed membership list is genuinely fine. The trap, I think, is treating the full identity build as a precondition. It is the control that starts mattering at a hundred developers, and at ten it is mainly a reason the pilot begins a month later than it needed to.

Pick three that differ in shape, not three that differ in difficulty. Cursor documents Plan Mode as earning its time on complex features with several valid approaches, work that spans many files, unclear requirements and architectural calls; for quick changes you have done many times, it says going straight to Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. is fine. A pilot whose three tasks are all small and familiar therefore tests the one path that needed the least evaluation.

The other constraint is the repo, and this is where a two-week pilot quietly loses its result. Point the cohort at code with no tests and you can still watch the agent work, but you cannot close the loop on whether the change was correct, so every conversation about quality becomes a conversation about impressions.

One of the three should be a task somebody on the team already knows how to do by hand.

That gives you the only comparison a group this small can actually make: same work, two methods, one person who can tell you where the agent's version was better and where it was merely faster.

They can tell you whether the workflow produced diffs a reviewer was willing to read, which task types suited it, and which parts of the shared prompt and the review checklist the team kept using once nobody was watching. They cannot give you a defect rate. Ten people over two weeks is not a sample that separates a real quality change from a normal fortnight.

Which is worth saying because the temptation is to reach for an outside number instead. The University of Chicago study that reported roughly 39% more merged pull requests after Agent became the default looked at about 1,000 organisations. Cite it as context if you like. It is not a target your ten people are being measured against, and treating it as one is how a decent pilot gets written up as a disappointment.

For the numbers you can pull, the team dashboard filters by user, group and date across up to 90 days and exports CSV, and it reports AI share of committed code alongside Agent and Tab activity. Read those as a description of behaviour rather than a scoreboard. Active-user counts in particular hide depth, since somebody who opens the agent once a week counts exactly the same as somebody who rebuilt their working day around it.