Individual results from Claude Code are well documented. Anthropic surveyed 132 of its own engineers and researchers and found that 27 percent of Claude-assisted work consisted of tasks that would not have been done at all without the tool, such as refactors and internal dashboards that were previously deprioritized. A separate seven-month observational study of Claude Code sessions showed the share of sessions spent debugging fell by nearly half as usage shifted toward end-to-end agentic work like deploying code and analyzing data.
Those individual gains often fail to appear in quarterly delivery metrics, and the reason is structural rather than statistical. When code generation accelerates, the constraint moves downstream to code review and validation. More pull requests enter the pipeline, review queues lengthen, and deployment frequency stays flat even though each engineer is producing more. If you only measure delivery outcomes, the gains are invisible. If you only measure individual sentiment, the gains are unverifiable. Accurate measurement has to connect three layers at once: who is using Claude Code, what portion of work it touches, and what that coverage is worth in hours and dollars.
Before you pick metrics, check what data exists. There are two main sources.
Anthropic's analytics dashboard. On Claude for Teams and Enterprise, admins and owners can see lines of code accepted, suggestion accept rate, daily active users and sessions. With the Claude GitHub app installed, contribution metrics add merged pull requests that contain Claude Code-assisted code, the share of all merged PRs that includes it, and PRs per user. Anthropic calls these contribution metrics conservative: they count only lines and PRs where it has high confidence in Claude Code's involvement, they are in public beta, and they are not available to organizations with Zero Data Retention (Claude Code docs: analytics).
The Claude Admin API, through Worklytics. Worklytics pulls a daily usage summary per person from the Claude Admin API. It captures coding sessions, input and output tokens, lines added and removed, commits and pull requests attributed to Claude Code, edit and write actions split into accepted and rejected, models used, and estimated cost. Personal identifiers are pseudonymized (hashed with SHA-256) before analysis, and results are shown only for groups above a minimum size, typically 5 to 8 people. Worklytics puts Claude Code next to your other coding assistants and your GitHub, calendar and collaboration data, so you can compare groups instead of reading one vendor console. The setup is covered in the guide to tracking Claude Code usage.
Productivity gains are a comparison, and a comparison needs a starting point. The most common failure in Claude Code measurement is jumping straight to output metrics without recording what adoption and work patterns looked like before rollout, which leaves any later improvement unattributable. A three-stage model prevents this. Adoption answers what percentage of the team uses Claude Code daily, weekly, or monthly. Proficiency answers what percentage of engineering work is being aided by AI. Leverage answers whether the team is completing more in a day than it did without the tool. Each stage depends on the one before it: leverage claims collapse under scrutiny if you cannot show which cohort adopted the tool and how deeply it penetrated their work.
Worklytics structures its AI adoption measurement around this exact sequence, building each stage from metadata in the tools engineering teams already use rather than from surveys, so the baseline exists on day one instead of being reconstructed from memory.
Seat counts overstate adoption and understate value. The metrics that actually describe Claude Code usage are weekly active users, percentage of the engineering workforce active, days per week of use, uses per active day, and the trend across a rolling window of at least 12 to 14 weeks. The trend matters as much as the level, because agentic coding tools follow a habit curve: usage that grows week over week signals workflow integration, while flat usage at any level signals a tool that never left the experimentation phase.
Claude typically presents a specialist profile in this data. In the example tool portfolio view below, Claude reaches 15 percent of the workforce at 2.1 days per week, yet posted 4.2 uses per active day and grew 22 percent over 14 weeks, the fastest growth of any tool in the portfolio. Cursor showed the same shape at 6 percent of the workforce and 6.8 uses per active day. Broad assistants like Copilot inverted the pattern, reaching more people at lower intensity. This distinction changes decisions. A specialist tool is evaluated on depth and growth within its user base, not on organization-wide penetration, and enablement budget goes toward expanding the specialist cohort rather than nudging light users.
Claude-specific dashboards break that intensity down one level further, by surface. Claude.ai is conversational assistance, Claude Code is agentic delegation, and the two represent different maturity stages rather than interchangeable interfaces. The crossover moment in the trend below, where Claude Code active share among engineers climbs past conversational use, is the signal that a team is shifting from asking AI questions to handing AI tasks. That shift matters for measurement because productivity gains concentrate almost entirely in the delegation population, so tracking Claude usage as a single undifferentiated number dilutes exactly the cohort you are trying to measure.
Active users by Claude surface over time: Claude Code adoption accelerating past conversational use is the delegation signal that precedes measurable delivery gains.
Collecting this data does not require reading code or prompts. Worklytics works from usage metadata in the Claude Admin API, following a privacy-first architecture that reports at group level. For the setup details, see the Worklytics guides to tracking Claude Code usage and measuring Cursor utilization across an engineering organization.
Averaging productivity across everyone with a license dilutes the signal until it disappears. If 40 engineers use Claude Code four or more days a week and 160 opened it twice last month, an org-wide average will show almost nothing, and skeptics will conclude the tool does not work. Plotting frequency against intensity, days per week on one axis and uses per active day on the other, splits the population into power users, habit starters, occasional deep users, and dabblers. Productivity gains should be measured within the power-user cohort against a matched cohort of non-users doing comparable work, because that is the only comparison where the treatment is real.
The quadrant also reveals where the next gains come from. Habit starters who use Claude Code frequently but shallowly respond to workflow training, such as multi-step agentic patterns. Occasional deep users respond to habit triggers, such as integrating Claude Code into CI or code review. Dabblers may simply hold seats that should be reallocated at renewal.
Usage counts become productivity claims only when they are mapped to the work being displaced. Worklytics classifies AI activity into work categories such as coding, research, analysis, summarization, drafting and email, so you can see which kinds of work each tool touches. Turning that into hours saved takes one more step: a time-saved assumption per category, set by your own team and checked against delivery and calendar data. Categories differ sharply in value. In the example chart below, code generation returns 4.2 hours per active user per week and email authoring under one hour. Treat numbers like these as a starting assumption to test, not a benchmark.
This is also why engineering-focused tools like Claude Code can justify their cost with a smaller user base than a general assistant: the work they accelerate is expensive. The free AI ROI calculator lets you model the math with your own headcount and cost inputs before you instrument anything.
Claude Code pricing scales with token use, so spend grows with exactly the usage you are trying to encourage. That makes cost per hour saved the honest efficiency metric, not total spend. Worklytics captures Claude Code's tokens and estimated cost per person per day from the Admin API, so cost per active user and cost per group sit next to adoption and output. Plotting monthly cost against estimated monthly value per tool surfaces both kinds of outliers: tools with modest cost and strong measured value, and tools with large license commitments but weak weekly active use, which become right-sizing conversations at renewal.
Before computing cost per hour saved, look at where the spend actually sits. Department-level cost stacked by surface, as in the illustrative view below, typically shows engineering carrying the majority of Claude spend, almost entirely from Claude Code, with engineering near 58 percent of the total in this example. That concentration is expected rather than alarming: agentic sessions are token-intensive by design, and the ROI case is strongest exactly where spend is highest. The same view also identifies the opposite case. Functions whose usage is primarily conversational carry low cost per active user, and for them the right response is adoption enablement, not cost optimization.
This reconciliation is also what converts measurement into budget authority. Finance approves more Claude Code spend when the request arrives as cost per saved engineering hour with a trend line, not as a sentiment survey. Worklytics reports cost and usage together inside its engineering effectiveness reporting, and you can apply your own hours-saved assumptions on top.
Hours-saved models are estimates, so the final proof has to come from delivery data. The cleanest test compares merged pull requests per engineer per month across usage groups doing comparable work. In the example cohort view below, engineers with heavy Claude Code use merge a median of 6.86 PRs to production per month against 4.67 for low AI use peers, with heavy Cursor users at 5.54. Anthropic reports a similar direction inside its own engineering team: a 67% increase in merged pull requests per engineer per day after Claude Code was adopted (Anthropic). Read the distribution as well as the median. If the whole group shifts right, the gain is broad. If a few outliers pull the median up, the tool is amplifying existing top performers rather than raising the floor, and the enablement plan should differ.
Producing this view requires joining AI usage groups with source control activity, which is where spreadsheet attempts usually stall. Worklytics compares high-use and low-use groups on output measures such as merged pull requests from GitHub in its Workplace Insights Dashboards. Teams that want to run their own analysis can export the usage data to a warehouse through DataStream and join it with GitHub or Jira records. The full list of supported sources is on the integrations page.
More merged code is only a productivity gain if it stays merged. Generation speed can outrun review capacity and test coverage, and when that happens the failure shows up as longer PR review cycles and a rising revert rate in the months after rollout. In the example below, PRs reverted per month among Claude Code users climb from a pre-rollout range of about 5 to 8 toward 15 to 18 within a year. Left unchecked, that pattern quietly refunds the hours the tool saved, because every reverted PR costs generation, review and fix time. The answer is not less AI but explicit guardrails: revert rate, review cycle length and change failure signals tracked on the same dashboard as adoption.
This pairing also keeps the measurement credible with engineering leadership. A report that shows PR volume up and says nothing about quality invites the suspicion that the gains are cosmetic. Worklytics reports pull request cycle time and reviewer cycle time from GitHub, plus Claude Code's accepted and rejected edit actions, next to adoption in its engineering effectiveness reporting. Revert counts come from your own source control or incident data.
Internal trend lines answer whether you are improving, but not whether you are competitive. Fifteen percent workforce adoption of Claude Code might be a leading position in one industry and a lagging one in another, and without external reference points, leadership debates the number instead of acting on it. Percentile benchmarking resolves this by placing metrics like total AI adoption, weekly usage, unique agents utilized, and function-level adoption on a distribution of peer organizations. An organization sitting at the 40th percentile on total adoption but the 85th on AI use in its sales organization knows precisely where its next intervention belongs, which is a sharper conclusion than any internal dashboard can produce alone.
Worklytics peer benchmarking, available in beta, places adoption and usage metrics against peer organizations, so Claude Code results are read against the market rather than only against last quarter.
Hours saved are only a gain if they are reinvested in valuable work rather than absorbed by fragmentation. The downstream risk of faster code generation is a heavier review and coordination load, which can quietly consume the time the tool created. Fragmented time (hours of the workday broken into pieces too short for focused work, a standard Worklytics metric) is a useful early-warning signal here. In the example below, individual contributors with heavy AI use averaged 2.3 daily hours of fragmented time against 2.9 hours for low-use peers, and executives showed the same gap at 2.6 against 3.1 hours. The direction matters: when heavy Claude Code users show rising fragmentation instead, it usually means review queues and coordination overhead are eating the surplus, and the fix is process capacity rather than more AI.
A defensible answer to whether Claude Code is paying off comes from one connected chain: baseline, adoption and intensity, cohort comparison, hours saved by task category, cost per outcome, delivery-level validation with quality guardrails, and peer benchmark check on the result. Worklytics runs that chain on metadata from the tools your teams already use, with first metrics typically available within a week of connecting. Book a demo to see the AI adoption dashboard against your own Claude Code deployment.
Partly. Anthropic's contribution metrics show which merged pull requests contain Claude Code-assisted lines, and Worklytics captures Claude Code sessions, commits and pull requests per person per day, so output can be tied to Claude Code use rather than to AI use in general. Hours saved is still an estimate: apply a time-saved assumption per task category and validate it by comparing high-use and low-use groups doing comparable work.
Anthropic's analytics dashboard shows daily active users, sessions, lines accepted and suggestion accept rate for Claude for Teams and Enterprise. To see adoption by team, role or department, and next to Cursor, GitHub Copilot and other tools, use a cross-tool platform such as Worklytics, which pulls Claude Code data from the Claude Admin API and reports it at group level.
No. Sessions, tokens, lines added, accepted and rejected edits, commits and pull requests are all usage metadata. Worklytics pseudonymizes personal identifiers before analysis and shows results only for groups above a minimum size, typically 5 to 8 people.
Four to eight weeks of data before rollout is usually enough to see stable patterns in delivery cadence and focus time. If Claude Code is already deployed, compare heavy users with non-users doing comparable work instead. Expect meaningful trend data after about 30 days and group-level output comparisons after a full quarter.
Usually not. The bottleneck has often moved to code review and validation, so individual output rose while team throughput stayed flat. Track pull request review time and queue length next to Claude Code usage to see whether the fix is review capacity, quality gates or workflow changes.
