How to Measure AI Coding Agents: Claude Code, Copilot and Cursor (2026 Guide)

To measure AI coding agents, count the work that actually merged, not the suggestions that were offered. Attribute each pull request and commit to an agent using the signals agents leave in Git (co-author trailers, bot accounts, branch prefixes), then track AI share of merged work, merge rate and time to merge per agent, and how much review load the agents create for your team.

Most engineering teams now use more than one AI tool. One engineer runs Claude Code in the terminal, another lives in Cursor, the organization pays for GitHub Copilot, and someone is trying OpenAI Codex or Devin on the backlog. Leadership asks a simple question: how much of what we ship is written by AI, and is it working? Measuring AI code assistants and agents turns out to be harder than it sounds, because each vendor only reports on its own tool, and none of them report on what reached production.

This guide is written for engineering managers and CTOs who want a vendor-neutral answer. It covers what each vendor dashboard can and can't tell you, how to attribute code to an agent from Git data, the metrics worth tracking, the mistakes to avoid, and a setup you can run manually or automate.

Why "How Much Code Does AI Write?" Is Hard to Answer

Every major AI coding tool ships some kind of admin analytics. The problem is that each one sees only its own slice of the work, and what it sees is activity inside the tool rather than code that shipped.

• Claude Code usage analytics. Anthropic gives administrators a Claude Code analytics dashboard with usage figures such as active users, sessions, lines of code accepted and spend. It is useful for seat planning and cost control. It does not know which of those lines survived review and merged.
• Copilot metrics dashboard and API. GitHub reports Copilot adoption metrics for an organization: active and engaged users, suggestions shown and accepted, and chat usage, broken down by editor and language. Again, this is usage. It doesn't cover Claude Code or Cursor, and it isn't a count of merged pull requests.
• Cursor analytics dashboard. Cursor's team admin view reports usage per member, such as requests and accepted AI edits. Same limitation: it measures what happened in the editor.

Add the autonomous agents that open pull requests on their own (GitHub's Copilot coding agent, Devin, Google Jules, OpenAI Codex) and you have four or five dashboards, each with its own definitions, none of which answer the question leadership actually asked: how much AI-generated code is in production, and what is it doing to our delivery?

There is one place where all of that work ends up in the same format: your Git history. Every agent, whatever the vendor, eventually produces commits and pull requests. That is where outcome measurement has to start.

Usage Metrics vs Outcome Metrics

It helps to separate two families of numbers. Both are legitimate. They answer different questions and belong to different conversations.

Copilot adoption metrics tell you whether a license is being used. They don't tell you whether the pull requests it helped produce were merged, how long they took, or whether a human looked at them. A team can have high acceptance rates and a growing pile of AI-assisted pull requests that nobody has time to review. Only outcome metrics expose that.

If you already track engineering metrics such as cycle time and review time, outcome metrics for AI agents are the same numbers, split by who (or what) wrote the change.

How to Attribute Code to an Agent from Git Data

AI code attribution means deciding, for each commit and pull request, whether an agent wrote it and which one. You can't do that by inspecting the code: once it's formatted and reviewed, model output and human output look the same. You can do it from the metadata agents leave behind.

1. Co-authored-by trailers

A commit trailer is a Key: value line at the end of a commit message. Claude Code adds a co-author trailer to the commits it creates by default:

feat(billing): retry failed webhook deliveries

Co-Authored-By: Claude <noreply@anthropic.com>

Recent versions may put the model name in the trailer (for example "Claude Opus"), so match on the noreply@anthropic.com address rather than the name. GitHub renders these trailers as co-authors, and they are easy to search for. They are the strongest signal you have, because they are attached to the commit itself and survive rebases and merges.

2. "Generated with" footers

Some tools also add a footer to the pull request description or commit message, such as "Generated with Claude Code". When a commit is squash-merged and the trailer is lost, the pull request description often still carries the footer.

3. Agent bot accounts

Autonomous agents usually open pull requests under their own identity rather than a person's. The Copilot coding agent, Devin, Google Jules and OpenAI Codex each act through a bot or app account, so the pull request author identifies the agent directly. This is the cleanest signal for fully agent-written work.

4. Agent branch prefixes

Several agents name their branches with a fixed prefix, such as copilot/, cursor/ or codex/. A branch prefix is a useful supporting signal, especially combined with a bot author, but on its own it's weaker than a trailer because anyone can create a branch with any name.

5. From commits to pull requests

Pull requests are the unit most teams care about. A practical rule: treat a pull request as agent-written when it was opened by an agent account, or when most of its commits carry an agent signal. A human pull request with one AI-assisted commit out of ten is still a human pull request.

Why this gives you a floor, not an estimate

Git-based attribution only counts work that carries a signal. If an engineer pastes code from a chat window, strips the trailer, or uses an editor that doesn't add one, that work is counted as human. So the AI code share you measure is a lower bound: the real share is at least this high. That's a feature. A floor is honest and repeatable, and its trend over time is meaningful even if the absolute number is conservative.

Resist the urge to "improve" coverage with name heuristics. Matching on a branch called claude/ or a commit author named Claude, Devin or Jules will misattribute real people with those names, and some engineers name branches after themselves. A false positive is worse than a miss, because it erodes trust in the whole number. When in doubt, count it as human.

The Metrics That Matter

Once every pull request and commit is labelled, a small set of metrics covers what managers need to know. Calculate them per agent and per repository, over rolling windows such as 7, 30 and 90 days.

Why review coverage deserves the most attention

Agents can open pull requests far faster than people can review them. The bottleneck moves from writing code to reading it. Two numbers make that visible: how many agent pull requests are waiting on a human right now, and what share of merged agent pull requests had a human review at all. If the first is growing and the second is slipping, AI generated code in production is outrunning your review process, whatever the usage dashboards say.

How these connect to DORA

Agent metrics don't replace DORA metrics; they explain them. If deployment frequency rises while change failure rate also rises, the AI share trend and review coverage tell you whether agents are part of the story. Read them together.

Pitfalls to Avoid

Counting suggestions instead of shipped work

"Lines accepted" and "suggestions accepted" measure interaction with a tool. Accepted code is often edited, rewritten or deleted before it merges, and some never leaves a local branch. Use these numbers for adoption, and use merged pull requests for impact.

Ignoring pull request size

AI makes it cheap to produce large changes, and large changes are expensive to review. Jellyfish found that AI-assisted pull requests are about 18% larger than other pull requests. When you compare time to merge between agents and humans, keep size in mind: slower reviews on bigger pull requests may be a size problem rather than a quality problem, and the fix may be asking agents for smaller changes.

Per-person AI leaderboards

Ranking engineers by AI usage or AI share creates two bad incentives at once: some people tag everything as AI to look modern, others strip trailers to avoid scrutiny. Either way, your data stops meaning anything. Keep these metrics at the team and repository level, the same principle that applies to developer productivity metrics in general.

Mixing providers and definitions

Adding Copilot's "acceptance rate" to Cursor's "AI lines" to Claude Code's "lines accepted" produces a number with no meaning, because each vendor defines its metrics differently. If you need one figure across tools, compute it from one source with one definition: merged work in Git.

Treating the number as a target

"Get AI share to 50%" is a target that can be hit by lowering the bar for review. AI share is context. Merge rate, review coverage and change failure rate tell you whether that context is healthy.

Step-by-Step Setup

You can get a first answer this week without buying anything. Here is the manual approach, followed by the automated one.

Option A: the manual approach

1. Agree on the signals. Ask everyone to keep the co-author trailers their tools add, and to leave agent branch names as the agents create them. Write it into your contribution guide, and consider a pull request template with an "AI-assisted" checkbox for tools that leave no trace.
2. Label agent pull requests. Add an ai-agent label (or one per agent) to pull requests opened by bot accounts or carrying agent trailers. A small CI job or webhook can apply it automatically.
3. Avoid losing trailers on squash merge. If you squash-merge, make sure the squash commit message keeps the co-author lines. The default squash message usually carries the original commit messages, trailers included, but an edited message can drop them.
4. Query the history. Count commits with an agent trailer against all commits on the default branch:

# Commits on main in the last 30 days with a Claude co-author trailer
git log main --since="30 days ago" -i --grep="Co-authored-by: Claude" --oneline | wc -l

# All commits on main in the same window
git log main --since="30 days ago" --oneline | wc -l

For pull requests on GitHub, the gh CLI can list merged pull requests whose branch uses an agent prefix:

gh pr list --state merged --limit 500 \
  --json number,headRefName,createdAt,mergedAt \
  --jq '.[] | select(.headRefName | startswith("copilot/") or startswith("cursor/") or startswith("codex/"))'

5. Put it in a weekly report. Track AI share, merge rate and median time to merge per agent in a spreadsheet, and review it with the team once a month.

This works for one or two repositories on one provider. It gets painful when you have many repositories, more than one Git provider, or agents that each leave a different kind of signal.

Option B: with Gitmore

Gitmore's AI agent ledger does the attribution and the maths for you:

• It labels pull requests and commits written by Claude Code, GitHub Copilot, Cursor, OpenAI Codex, Devin, Google Jules, Aider and Windsurf, across GitHub, GitLab (including self-hosted) and Bitbucket Cloud.
• It shows AI share, merge rates and time to merge per agent for the last 7, 30 or 90 days, per repository.
• Alerts tell you when agent pull requests are waiting on a human and when AI share spikes.
• The same data is available in Gitmore reports and through Gitmore's remote MCP server (the agent_ledger tool), so you can ask for it from an AI assistant.
• Detection is conservative: no signal means human. Gitmore never reads your source code; it works from metadata only.

The ledger is included on every plan, including Free. See pricing for what each plan adds.

Frequently Asked Questions