What counted as an adoption trace

The researchers began with repositories from an existing dataset that had at least 10 stars. They excluded forks and required at least 5,000 non-blank, non-comment lines of code, 100 commits, and activity during the previous three months. The study period ran from January 1, 2025 through February 21, 2026.

Their detection method used four kinds of evidence: agent-specific files, authorship or co-authorship markers in commits, recognizable branch names, and pull-request labels. The final set contained 93 file heuristics, 79 author heuristics, 20 branch heuristics, and four label heuristics covering 63 coding agents. The authors released the analysis code and a February 2026 dataset for replication.

The validation work matters. Two authors reviewed random samples of roughly 400 files, commits, and pull requests flagged by the heuristics. After adjudication, the paper reports legitimate false-positive rates between 0.5% and 1%, with about 3% of cases classified as borderline.

They also removed signals that could not support a specific attribution. CONVENTIONS.md, for example, can describe ordinary project conventions even though Aider recommends it. AGENTS.md began with Codex but is now read by many agents. The study records that file under a generic category rather than pretending it proves which tool was used.

Why the estimate is a range

File-level traces appeared in 12.08% of the 128,018 projects. A further 11.51% showed commit-level evidence. After accounting for overlap and uncertainty, the authors estimate total adoption at 22.20%, with a high estimate of 28.66%.

Neither endpoint is a census of all GitHub repositories. The sample deliberately favors established, active projects. It excludes small repositories, inactive work, forks, private code, and agents used without a visible trace. A checked-in guidance file may also remain after a team stops using the tool.

The paper argues that undercounting is more likely overall, but it documents both directions of error. Developers can disable co-author markers, change branch prefixes, remove labels, commit an agent's patch manually, or use cloud agents whose state never enters the repository. In the other direction, one configuration file can indicate experimentation rather than continuing use. A squash merge can also label a combined commit as AI-assisted even when only part of the work came from an agent.

Agent-related workflow artifacts are already common in this selected public sample. The estimate does not reveal how many lines a model wrote or how closely a developer supervised the work.

Adoption is broad, but concentrated among tools

The study found 26,883 adopting projects and 42,060 tool adoptions, or more than 1.6 agents per adopting project. Two thirds used one detected tool. The remaining third used multiple tools: 5,570 projects used two, 2,072 used three, and 1,467 used four or more.

Tool popularity was concentrated. Assuming most generic AGENTS.md usage came from Codex, the top five tools accounted for more than 80% of detected adoption. Claude and Copilot together represented more than half. The paper labels its estimate of roughly 6,000 Codex projects as very rough because the shared guidance-file convention makes attribution uncertain.

Younger projects adopted agents more often. File-level adoption was 26.37% among projects one year old or less, compared with 7.96% among projects older than a decade. Size pointed the other way: larger and more active projects generally showed more adoption. The top pull-request decile reached 25.15%, although the authors note that agent-created pull requests can partly create that association.

Coding agents are not confined to greenfield prototypes, and they have not spread evenly across tools or repositories.

Bigger commits are not proof of more productivity

The paper compared 439,439 AI-assisted commits with millions of human and bot commits in projects where both file-level and commit-level evidence existed. The median AI-assisted commit added 31 lines, compared with 11 for a human commit and four for a bot. The upper quartile for AI-assisted additions reached 114 lines. Median deleted lines were seven for AI-assisted commits and five for human commits.

The difference becomes more pronounced at the edges. Commits adding more than 1,000 lines were almost twice as frequent among AI-assisted commits, while changes touching more than 20 files were 30% more frequent.

Those numbers describe patch size. The researchers did not measure productivity, code quality, reverts, or long-term churn. A larger diff may be a useful feature, broad mechanical work, unnecessary rewriting, or code that disappears next week.

A manually reviewed sample of 790 Claude Code commits adds context. Features made up 35.7% and fixes 29.9%. Documentation accounted for 10.9%, refactoring 9.9%, chores 7.1%, tests 5.4%, and style 1.1%. Sixty-five percent already used a recognizable Conventional Commits prefix; two authors manually classified the rest.

The feature-heavy mix may help explain the larger patches, but it still cannot establish whether agents made teams faster. Commit categories describe intent, not outcomes.

What maintainers can measure now

Repository traces work best as provenance records. Keep the agent and model identity with the run when possible, then record the task, permissions, review path, tests, and final human edits. Longer-term measures can cover accepted changes, review time, escaped defects, reverts, and follow-up churn.

Our AgentArena guide covers a local way to compare configurations against the same repository and judges. The RepoComplianceBench analysis explains why partial instruction following can look cleaner than it is. Both supply evidence that a co-author line cannot provide.

Coding-agent use is visible across a substantial slice of the active open-source sample. The public code and dataset let other researchers test where that visibility comes from and where it disappears. A co-author line can establish provenance. Productivity and code quality require evidence collected after the commit.