Everyone is quoting a percentage right now. Thirty percent of our code is AI-written. Half. Ninety. Almost nobody says where the number came from, because for the most part it came from a survey or a feeling.
The strange thing is that the real number is sitting in your git history already, and almost nobody looks.
Coding agents sign their work. Not as a side effect their authors deliberately built attribution into the commit record. Claude Code appends a co-author line pointing at noreply@anthropic.com. Cursor signs as cursoragent@cursor.com. Jules shows up as google-labs-jules[bot]. Devin leaves a session link. Copilot's coding agent opens the pull request under its own bot account. Every one of those survives in metadata you can read without touching a single line of source code.
So you can just count them. This is the whole measurement, run against the repo I'm writing from:
git log --since="90 days ago" --format='%(trailers:key=Co-authored-by,valueonly)' | grep -ci anthropic
Five of the last fifteen commits. A third, measured rather than guessed, in about two seconds.
I ended up building this properly, which mostly means I hit the sharp edges first. Three of them are worth knowing about.
The first will break any version you write today. Most teams squash-merge, and when they do, the agent's trailers do not stay on the pull request they land on the squashed commit on your default branch. If you attribute PRs by reading the PR title and body, which is the natural thing to do when you're working from an API, you will classify a large share of agent work as human and never notice you did. You have to follow the merge commit and read the trailers there.
The second is that a careless pattern eats real people. Searching for "claude" matches a developer named Claude. Searching for "cursor" matches a commit message about cursor position. Searching for "aider" matches the word raider. Every rule has to be anchored to the part that is genuinely machine-generated the trailer key, the bot suffix, the noreply address. For the same reason I threw out the convenient branch prefixes claude/ and devin/, because plenty of developers prefix branches with their own first name, and turning a person into a robot is a worse mistake than missing a few agent branches.
The third is the one that actually matters, and it's a decision rather than a technique. When a commit carries no signal at all, you can treat it as human, or you can start inferring from style and message shape and diff size. I went with: no signal means human, always.
That makes every number a floor. The true AI share of your repository is somewhere above what I report, never below. Rebased commits, hand-squashed history, hooks that strip trailers, agents that don't sign — all of it is invisible to me, and I'd rather under-count it than guess.
This looks like giving up accuracy and it's the opposite. A floor is something you can defend. "At least a third of our merged work is agent-authored" survives someone pushing back on it in a planning meeting. An estimate doesn't survive the first person who asks how you got it.
What I didn't expect is that the percentage turns out to be the least interesting thing you get. Once authorship is a real field in your data, the useful questions are comparative. Do agent pull requests get merged at the same rate as human ones, or do they quietly pile up and get closed? Do they sit longer in review? In most repos I've looked at they do, and that gap says more about how a team has adapted than any headline percentage. Where is agent work actually concentrated? Usually tests and glue code, and almost never the part people were anxious about.
None of that is a productivity score, and I'd be careful with anyone who tries to turn it into one. It's a description of a workflow that changed underneath all of us without anyone getting a chance to measure the before.
If you want the number for a repo you haven't cloned, there's a free scanner that runs the same attribution over any public GitHub repository without an account. It's part of Gitmore, which does this continuously across GitHub, GitLab and Bitbucket, but the scan is public and the command above needs nothing from me at all.
Run it on a codebase you know well. If the number comes back lower than you expected, the interesting part is working out which signal got lost.
Top comments (0)