How to Measure AI Developer Productivity

Decide what a fair test looks like before you run the benchmark. If you decide afterwards, the numbers will favor the tool you already prefer.

Fix the task mix before you see any results. If you choose which tasks count after the test has run, you will pick the ones that agree with what you already thought, without noticing. Without a written plan, a benchmark is an anecdote with a chart attached. Write down the stack, the task types and the sample size before the first run.

Every benchmark has limits. Naming them is what makes the rest of the report credible, so state plainly what the result does not cover.

• Sample size, repo type and task mix.
• Models, tool versions and seat cost used.
• Review time added by AI-generated changes.
• Where the result should not be generalized.

Put each limit next to the result it qualifies, not in a footnote. A result shown without its sample size invites readers to apply it to their own repo.

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.

Two analytics signals, read together, tell you who is getting value and where adoption is stalling: request volume and acceptance rate of committed code. Plot them as a quadrant.

The ROI ladder

Proving value is a phased climb. Don't jump to dollars on day one.

Don't reuse the engineering yardstick. Lines of code and PR count measure code authoring, so they undercount roles whose value is reach and depth rather than volume. For those roles, measure how much more of the work now gets the full treatment.

In a Cursor webinar on security work, a Cursor security engineer described the gain as coverage. Agents that don't tire let a security team review every change in depth instead of a sample, so practices that were out of reach, such as threat-modeling every change, become workable. He put his own gain at roughly 5x on older models and 7.5 to 10x now, and said he ramps into an unfamiliar system in hours instead of a week. Treat that multiplier as self-reported, and track the coverage it buys.

He puts it plainly: "I've never met a security team where every single PR at the company is reviewed in security depth." The metric that matters is the share of changes that now get that depth, not the time any one review takes.

A Cursor webinar on technical support made the same point for support teams: their return doesn't show up in lines of code or PRs. The speaker's closing advice was to give support engineers access, bring vendor integration points such as MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers into Cursor, and work with the team to find the pain points worth automating.

Most of the adoption numbers, but not the prompts. On Teams and Enterprise plans, Cursor's team dashboard reports AI share of committed code, agent edits, Tab completions and active users across Agent, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition., cloud and the CLI.

Enterprise adds four more sources. Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. shows, line by line, whether code came from Tab, from Agent or from a person, once a team admin turns it on. The AI Code Tracking API, in alpha, returns per-commit AI usage to your own tools, and the Analytics API pulls the same numbers into your reporting stack, so nobody has to screenshot a dashboard.

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., on by default for Enterprise, sorts work into categories such as new features, bug fixes and refactors without anyone labeling it. It also rates how complex the tasks given to agents are and how specific the prompts are.

None of these sources holds the prompt. Audit logs stop at administrative actions and hold no agent responses or generated code, so a record of what you asked for and what came back is something you instrument yourself. The documented route is hooks: a hook can fire on each submitted prompt and on each code edit the agent makes, then send the event to an endpoint you run. Cursor advises logging metadata rather than full content.

Decide early whether you want that record at all. It shows where people are struggling, but it is also a log of how your colleagues think. A metadata-only version is easier to explain to the team it describes.

Your own trend, on a handful of task types you ship again and again. Don't compare against a public benchmark or the published research. The research is still worth knowing. A University of Chicago study of tens of thousands of Cursor users found that organizations merged 39% more pull requests after Agent became Cursor's default mode. It measured that against a baseline group of organizations that weren't using Cursor.

You can't reproduce that inside one company. You have one team, one quarter and no control group, while every other variable in the company moves at the same time. A before-and-after measure of four repeated task types is a much weaker claim than a study with a baseline group behind it, but it is a claim you can defend in a room.

Carry one finding from that study into your method. More-experienced developers were more likely to accept agent-generated code. The study also found that they plan before coding more often, and Cursor's write-up suggests they may use rules or manage context better. Either way, an acceptance-rate comparison across a mixed-seniority team measures seniority as much as tooling, and a league table built on it reads a seniority mix as a skill gap.

Read acceptance rate per cohort, or compare each person with their own last quarter. Don't rank people against each other on it.

AI share of committed code gets promoted to the target, mostly because it is the easiest number to screenshot. It tells you who authored the lines and little else. An agent can author a large fraction of a codebase that never made a customer's life better, and the share can keep climbing in a quarter when nothing ships.

Put a second number beside it that is hard to game and costs nothing to collect: how long code survives before it has to change, sometimes called code half-lifeHow long code survives in the codebase before it has to change; a maintainability signal that counters 'more lines means more value'. Press Enter for the full definition.. Code rewritten within days suggests the first pass missed the problem, whoever or whatever wrote it.

No single number belongs in a leadership deck without a counterweight next to it, and the counterweight should be one you would find awkward to present. If the pair moves in opposite directions two quarters running, that suggests the share is tracking the tool's output, not the team's.