Enterprise AI Coding Rollout

enterprise AI coding rollout 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.

From your git host, not from Cursor. The admin analytics dashboard reports adoption: AI share of committed code, Agent and Tab edits, messages by mode and model, active users per surface, daily usage, a usage leaderboard, repository insights, and on Enterprise the Conversation InsightsA Cursor analytics view that passively categorises what agents are doing (new features, bug fixes, refactors) so leaders can see where engineering time goes. Press Enter for the full definition. classifier plus Cloud Agent counts for agents created, PRs opened, PRs merged and lines merged. Reviewer comments and rework passes are not in that catalogue. Those come out of pull request data, and somebody has to go and get them.

The adoption half has a shape worth knowing before you quote it in a steering meeting. AI share of committed code is derived from signatures Cursor logs on-device for AI-suggested lines, then matched against later commits by the same author on the same machine. Automated formatters can invalidate those signatures. The attribution does not cover Background Agents or the Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition., and commits have to be scored on the machine where the AI code was written.

Which means the headline number under-reports exactly the surfaces a maturing rollout moves into. A team that shifts work from the in-editor agent to Background Agent and CLI runs can show a falling AI share in the same quarter its agent usage climbs, and if that chart is your adoption story, you will spend the meeting explaining a decline that did not happen.

Pair one number from each side and keep both of them boring. Something from the dashboard for adoption, something from the git host for review cost, both filtered to the pilot repo.

The plumbing is fine for that. Analytics need client 1.5 or later, the user, group and date filters run to 90 days, and every chart exports to CSV, with the Admin API on Enterprise for the version of this that eventually becomes a scheduled report.

No. Alerts email you when a threshold is crossed; spend limits are the control that caps cost. Set alerts in the team dashboard, team-level or member-level, and admins choose whether member-level alerts go to admins, the member, or both.

Read the trigger definition carefully, because it decides when you hear anything at all. Alerts fire on on-demand spend only, and included plan usage does not count toward the threshold. The first email therefore arrives after the allowance is already gone, which is fine as a budget signal and useless as an early warning. Enterprise accounts with pooled usage can set member-level alerts against total spend instead, which is closer to what most people assume they configured.

Then there is the routing question sitting underneath it. On Teams and Enterprise, Auto is powered by Cursor Router, and only Cost mode keeps the bundled Auto pricing that the Auto plus ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. pool is built around. Balance and Intelligence bill per request at the routed model's rate. Cursor puts those at about twice Cost mode on average, and up to two to four times depending on the mode selected.

The default differs by plan, and this is the bit to check on day one rather than in month two. The router is on by default for Teams plans, and off by default on Enterprise, where an admin has to enable it.

So a Teams rollout can be spending at the routed rate without anybody touching the model picker. An Enterprise rollout has the opposite problem, an unmade decision that looks like a working default.

Fewer than the pitch suggests, and later than the contract wants. Cursor's June 2026 Teams pricing gives Standard seats at $32 per seat per month annually or $40 monthly, and Premium seats at $96 annually or $120 monthly for five times the included usage at three times the cost. Cursor positions Premium as the seat for heavy agent users, which is an argument for upgrading a small group rather than every teammate by default.

The reason to buy Premium late is that included usage is split into two pools, first-party Auto plus ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. on one side and third-party API usage on the other, and admins can see usage against each. That split tells you which people are actually exhausting which pool. Guessing it up front means paying for five times the usage of somebody who has not yet changed how they work.

One month of Standard seats is usually enough to sort the team into the two groups. Then upgrade the ones who ran out.

Same order, less ceremony. A small team can run this as one shared workflow, a two-week pilot and a single review rule, and the four control owners collapse onto two people. That is fine as long as the names are written down somewhere, because the failure mode at small scale is not bureaucracy, it is nobody owning the data-flow answer when a customer's security questionnaire arrives. The startup rollout plan and the 10-developer pilot are sized for that.

Somewhere past a hundred or so developers, and I could not tell you exactly where, the pilot itself has to be structured: cohorts rather than volunteers, champion teams, a support route for when something breaks, and measurement split by repo type, because a monolith and a set of services produce different review loads from the same tool. The 100-developer plan walks that version.

Identity is the step that changes most with size. At twenty seats you can hand out access and fix it later. At two thousand you cannot, and the practical order is to settle identity, then map Organizations, teams and groups onto the org chart, then pilot inside that structure, because retrofitting cohorts onto people who already have broad access means taking something away from someone.

There is a pattern from Cursor's own finance team that generalises well past finance. With no embedded engineers, the single engineering partner they took at the outset was security engineering, to get the foundation right before anything got built. That meant Okta permissions, GitHub structure, and credentials for the data and SaaS tools people would actually reach for.

Get the basics consistent across the org, then let people build on top of them. It reads like process for its own sake until you watch the alternative, which is every team inventing its own access story and security auditing all of them afterwards.