What Are AI Code Share?

What it means

AI code share answers a simple question: of the work that actually shipped, how much did an AI agent write? It can be counted at different levels: the share of merged pull requests opened by or substantially written by an agent, the share of commits with an AI attribution signal, or the share of changed lines in those commits. PR-level share is the easiest to explain to non-engineers; line-level share is the most detailed but the noisiest. The metric is measured from evidence the tools leave in Git. Common signals include Co-authored-by trailers added by agents (Claude Code, for example, adds a Co-Authored-By line naming Claude), footers such as 'Generated with Claude Code' in commit messages or PR descriptions, commits and PRs authored by an agent's bot account (cloud agents like GitHub Copilot's coding agent or Devin open PRs under their own identity), and branch-name prefixes that agents use by default, such as copilot/ or codex/. Because many tools, especially inline autocomplete, leave no trace at all, any Git-based measurement is a floor rather than an exact count: it tells you the minimum share that was AI-written, not the true share. Some teams publish an estimate on top of the floor using editor telemetry or surveys, and it is important to label which number is which. AI code share is also different from AI usage. Usage metrics (seats, suggestions accepted, prompts sent) describe how much developers interact with AI tools. AI code share is an outcome metric: it only counts work that was merged and shipped.

Why AI Code Share matter

Most engineering teams now use several AI coding tools, and leaders are asked by boards, clients, and their own engineers how much of the product those tools actually build. Usage dashboards from each vendor cannot answer that, because they measure activity in the editor, not what reached production, and each vendor counts differently. AI code share gives one vendor-neutral number based on shipped work. It also matters for review and quality: agent-written PRs often need a different review approach, and knowing which PRs came from an agent lets teams check whether those PRs wait longer for review, get reverted more often, or merge without a human reviewer. For agencies and contractors, it is increasingly part of what clients want disclosed. And for compliance or licensing questions, an attribution trail in Git is more defensible than a vendor's usage report.

How to measure

1) Pick the unit: merged PRs is the most readable; commits or lines give more detail. 2) Define the time window and only count merged or default-branch work, so abandoned experiments do not inflate the number. 3) Scan commit messages for Co-authored-by trailers naming known agents (git log --format='%H %(trailers:key=Co-authored-by)' lists them), and for agent footers such as 'Generated with Claude Code'. 4) Check PR and commit authors against known agent bot accounts. 5) Check head branch names for default agent prefixes. 6) Treat anything with no signal as human-written. This keeps the measurement conservative and avoids false positives, but means the result is a floor. 7) Report the floor separately from any estimate, and show the trend over time rather than a single snapshot. Gitmore's AI agent ledger applies this kind of conservative detection across GitHub, GitLab, and Bitbucket for agents including Claude Code, Copilot, Cursor, Codex, Devin, Jules, Aider, and Windsurf.

Real-world example