Who wrote this?

In one minute Most figures for "how much of our code is AI-written" come from surveys, and your repository already holds better evidence. In our study, projects built with agents credited an agent on a median 41% of their commits in their first six months, yet many other projects used agents without leaving that trace. Label each change as agent, human-attested or unknown, report your label coverage, and keep one record per merged change for the day someone asks.

The number everyone quotes is a guess

Ask a room of engineering leaders what share of their code an agent wrote. You will hear confident numbers. Ask where each one came from and the room goes quiet.

The public figures share that weakness. A widely covered 2026 developer survey put AI at 42% of committed code.¹ That is what developers believe, in their own words. Google's CEO said in 2024 that more than a quarter of new code at Google is AI-written and then reviewed by engineers.² That is a company statement, with no method attached. One code review vendor compared AI and human pull requests by reading co-author lines in the commits, and noted that some of its "human" pull requests may have been AI-written too.³

None of these is wrong to publish. They are the wrong input for decisions about your own code. When an incident review, an auditor or your board asks which code an agent wrote, a survey answer will not hold up. Evidence from your repository will.

The evidence is already in your repository

Coding agents leave marks, and most teams never read them. Three kinds are worth knowing.

Commit trailers are short "key: value" lines at the end of a commit message. Many agents add one by default, such as a Co-authored-by: line naming the agent, or a footer like "Generated with Claude Code". Some agents commit under their own bot account, which is a mark too.

Agent config files are the instructions a team writes for its agents: AGENTS.md, CLAUDE.md, .cursorrules, .github/copilot-instructions.md. The day one of these lands in a repository is a good estimate of when agent use began.

Edit capture is opt-in. A small hook records which lines an agent wrote at the moment it writes them. Done carefully, it stores fingerprints of lines and never prompts or code.

Where these marks exist, they are strong. In our study of 200+ popular open-source repositories, 52 projects started from April 2025 carried agent trailers on at least a quarter of their commits, and their median agent share in the first six months was 41% of commits.⁴ Projects started in 2021 and 2022 sat at 0%. Config files tell the same story: 43 of the 52 agent-built projects added one within 60 days of their first commit, against 1 of 40 older projects.⁴

Trailers alone miss a lot, though. We looked at 79 young projects where fewer than 5% of commits carried an agent trailer, and 34 of them still added an agent config file in their first 60 days.⁵ The team was using agents, and the commit history mostly left that out. Expect the same in your repository, and treat a share built on trailers alone as a floor.

Figure 3.1

Three answers, and "unknown" is one of them

Every commit can get one of three labels:

• Agent, when a trailer, a bot account or a captured edit ties the commit to an agent.
• Human-attested, when the commit carries an explicit authorship record that names only people. The author's own tooling writes it at commit time, as a git authorship note or an agent trace file, so the author is the one attesting.
• Unknown, when neither kind of evidence exists.

Most of the value sits in the third label. A commit with no agent marker could be human work. It could just as easily be agent work from a tool that adds no trailer, or a squash merge that dropped the trailer on the way in. Count unknown as human and your agent share looks low and precise, while being wrong in a way nobody can see.

So keep unknown as its own label, and report two numbers together. Label coverage is the share of commits you could label either way. The agent share is then measured over those labelled commits only. Human-attested records are still rare, so most labelled commits carry agent markers, and the share describes the traceable part of your history. A share stated with its label coverage can be defended in any meeting. When label coverage is very low, report the count and leave the share out, because a share computed from a tenth of your commits invites a bad decision.

An illustration: the audit committee asks a director how much of the payments service an agent wrote. One answer is "about a third, we think." A better one is "at least 40% of the changes we can trace, and we can trace 62% of all changes. We have started tagging new work, so the untraced part shrinks every month." The second answer admits a gap and still gives the committee something to act on.

The unit an auditor cares about: one change

Labels on single commits are good for trends. Most real questions arrive in a different shape. People ask about a pull request, or about "the change that broke checkout on Tuesday".

A Change Record is one merged change described in full: the pull request or merge, the commits inside it, the files it touched, its author, and the agent, human-attested or unknown label for the whole change, with its label coverage. It can be built from git history alone, so it also covers changes made before anyone thought to keep records. Built this way, the file list matched the code host's own list on 97.9% to 100% of recent merged pull requests in six open-source repositories.⁶

Auditors and compliance tools want records in a shared format. in-toto is an open standard for signed statements about which steps produced a piece of software and who or what performed them.⁷ A Change Record exported as an in-toto statement can sit beside the build evidence your security team already keeps. Chapter 7 covers what auditors ask for.

The record earns its keep at four moments:

1. In an incident review, start from the change that shipped, see its files and see whether an agent wrote it. That tells you whose prompts, rules or config to look at next.
2. In a compliance review, change management controls ask who made each change. An "unknown" with its label coverage is a truthful answer you can improve over time. Who approved the change usually comes from your code host's review records.
3. In planning, if agent-written changes in one service keep drawing follow-up fixes, that is where to add a reviewer or a test requirement. Without labels, every change looks the same.
4. For tracking the rollout, a monthly count of agent changes per service, with label coverage, shows where adoption is growing and whether your tagging is catching up.

Do this on Monday

1. Count the commits in your largest repository from the last 90 days that name an agent as co-author, and compare that with your total. The appendix has a ready command.
2. Find the date each repository first added an agent config file, with the case-insensitive command in the appendix.
3. Turn on co-author trailers in your agents' settings, and add one line to your agent config files asking for a Co-authored-by trailer on every commit.

How Repowise does this Repowise turns each merged pull request into a Change Record with its commits, files, author and provenance, labelled agent, human-attested or unknown and printed with its label coverage. repowise changes show exports any record as an in-toto statement for your audit store. Optional hooks for Claude Code, Codex and Cursor record which lines an agent wrote as it writes them, storing line hashes only, never prompts or code, so label coverage climbs from the day you switch them on.

Sources