What Coding-Agent Adoption Evidence Actually Shows
This chapter asks what it means to say that coding agents have been adopted. The answer depends on whether we are counting a project with a guidance file, a commit that names an agent, a developer who returns to the tool, or a change that survives review. Those events sit at different points in the workflow. Learning to separate them lets the reader interpret the striking public-GitHub estimates as evidence of a rapidly spreading capability without treating them as a census of developers or a guarantee of mature use.
The distinction is necessary because coding-agent interaction usually happens between a developer and a tool, while researchers often observe only what reaches a repository. The public record is unusually informative for agents: unlike many IDE completions, they may leave configuration, authorship, branch, or pull-request traces. But a trace is an observation made at one boundary of a larger workflow. It can establish that some detectable relationship exists; it cannot reveal everything that happened before or after it.
What the adoption range measures
The large-scale GitHub study examined 128,018 selected projects and searched for several families of signals. File-level evidence included configuration, rule, or guidance artifacts associated with agents. The researchers also looked at references in .gitignore, which can reveal that a project uses files it deliberately does not commit. Other signals came from commit authorship or co-authorship, branch naming conventions, and pull-request labels. Each family sees a different slice of the workflow.
A guidance file suggests that someone has prepared a repository for an agent or is sharing instructions that an agent can use. An attribution in a commit suggests that an agent participated in a change according to the relevant convention. A branch or pull-request label can expose a workflow in which the agent works through a hosted development process. None of these signals is identical to the others, and a project can exhibit more than one. Combining them is not redundant bookkeeping; it is a response to the fact that coding agents have different ways of interacting with repositories.
The signals also have different timing. A guidance file may appear before the first visible agent-assisted change, as a team prepares for experimentation. A commit marker records an action that reached version control. A pull-request label may identify an interaction that is still under review, while a merged commit indicates that at least some resulting work entered the main branch. Treating these as interchangeable would erase the transition the study is trying to observe. The union of signals is useful for asking whether a project has encountered agentic work; the pattern among signals is more informative for asking how that work is integrated.
From these observations, the study estimated that 22.20% to 28.66% of the sampled projects showed traces of coding-agent adoption by February 21, 2026. The lower figure is the conservative estimate. The higher figure extrapolates from the relationship between file-visible and commit-visible activity to account for projects that may have adopted agents without leaving the particular traces the pipeline could see. The authors present that upper figure as a rough approximation, not as a directly observed count.
The estimation logic illustrates why a range is more honest than a single number. Some projects reveal use through a file but not through a commit. Others reveal a commit or pull-request trace without a committed guidance file. If the analysis counted only the first kind, it would miss workflows that keep configuration private or use an agent whose normal path is a pull request. If it counted every possible hidden project as an adopter, it would overstate what the data directly establish. The conservative estimate stays closer to observed, non-overlapping signals; the higher estimate asks what the observed mismatch might imply if it is representative of unseen use.
That wording changes the claim. “Between 22.20% and 28.66% of selected projects showed detectable traces” is supported. “Between 22.20% and 28.66% of developers use coding agents” is not the same statement. Nor does the range mean that the same share of all GitHub repositories, private companies, or software tasks has integrated an agent. The sample was selected rather than a census of all repositories, and the observation period ended on a specified date in a fast-changing field. The denominator is part of the result.
The time pattern strengthens the interpretation that this was more than a handful of isolated experiments. The cumulative adoption curve accelerated after Claude Code’s initial release in late February 2025, accelerated again around the release of several other agents in the middle of that year, and picked up sharply at the start of 2026. A curve that rises across successive releases and time periods is consistent with category-level diffusion. It still does not tell us whether each newly marked project retained the tool, how intensively it used it, or whether the resulting work was beneficial.
A time series also should not be read as a lifecycle for each individual project. The curve records when detectable evidence first appears across the population. It does not follow every project from experiment to routine use, nor does a later flat period prove abandonment. A project can continue using an agent while leaving no new public marker, and a project can add a marker without using the tool on every subsequent task. Population-level acceleration and project-level persistence are related questions, not substitutes for one another.
The study’s heuristic validation provides a reason to take the signal seriously. The researchers manually checked samples of flagged files, commits, and pull requests, with two authors evaluating each item and adjudicating disagreements. They reported legitimate false-positive rates around 0.5% to 1%, with borderline cases around 3%. That is useful evidence that the selected markers often mean what the researchers think they mean. It is not evidence that the markers capture every use or reveal the full share of an agent’s contribution.
A low false-positive rate answers one question: when the pipeline flags an artifact, how often is that flag plainly wrong? It does not answer the different question of sensitivity: how much real use produces no flag? The study documents several routes to invisibility. Attribution can be disabled. A developer can inspect an agent’s work and commit manually. Guidance can live in a separate dotfiles repository. Some agents work mainly in a cloud environment, and some useful work remains in unmerged branches or pull requests. A project with no visible signal may therefore be a non-user, an invisible user, or a user whose activity has not entered the measured part of the workflow.
The diagram separates evidence channels from the claims they can support. A file, commit, or pull-request marker can contribute to a defensible statement that a project shows detectable adoption. It cannot, by itself, show that the agent worked autonomously, that a developer accepted its suggestions without editing, or that the project has made the tool a routine part of delivery. Hidden activity is not an exotic exception: it is a predictable consequence of optional attribution and of workflows that end outside the measured repository state.
The reverse error is possible too. Once a commit or pull request is flagged, the visible artifact may be larger than the agent’s actual contribution. In a squash merge, multiple changes can be condensed into one commit. If an agent is associated with the pull request but a developer performs some later work, a pipeline that labels the resulting commit as AI-assisted cannot always separate the portions. The same trace can therefore undercount total use at the project level while overstating the agent’s share of one particular change.
This is not a contradiction in the evidence. It is a consequence of observing a many-step process through a few public outputs. At the population level, missing traces can push the adoption estimate downward. At the artifact level, a broad attribution rule can assign too much of a mixed change to the agent. A careful reader must ask which direction of error matters for the claim being made. If the claim concerns category reach, sensitivity matters. If it concerns the size or authorship of one commit, attribution precision matters more.
Breadth is real; intensity remains uneven
The public evidence is most persuasive when read as a map of reach rather than a single adoption score. Coding-agent traces appeared in projects of very different sizes and ages. File-level adoption was higher among larger projects and projects with more contributors, commits, issues, or pull requests. Project age moved in the opposite direction: younger projects were much more likely to show file-level adoption, but even projects more than a decade old had a non-negligible rate. The pattern challenges the simple idea that agents are useful only when a codebase is new and unconstrained.
The relationship is descriptive, not a clean causal story. Active projects offer more opportunities for contributors to encounter an agent and leave a trace. Agent-assisted contributions can also increase the very activity measures used to describe a project, especially pull requests. A higher adoption rate among large or active projects therefore cannot by itself tell us whether scale made agents more useful, agents made activity higher, or both were influenced by another factor.
Project age adds a different kind of signal. Younger projects may have fewer established conventions and more feature work, making it easier to introduce an agent into the workflow. Older projects may have stronger maintenance obligations and more tacit constraints, which can make adoption harder or make it less visible. Yet the presence of adoption even in old projects shows that maturity is a constraint, not a categorical barrier. The data support a gradient, not a divide between projects where agents can and cannot be used.
The organization-level view points in the same direction. The top twenty organizations in the study’s public-project subset had a higher file-level adoption rate than the overall dataset, with substantial variation between organizations. Some well-known organizations were below the overall average, while others were far above it. That variation is important: adoption is not a simple property of organizational prestige or technical sophistication. It reflects local policy, visible examples, project conventions, available tools, and the decisions of individual contributors. Public repositories also reveal only the organization’s open-source surface, not its private internal use.
A higher rate among visible projects belonging to major organizations should also be interpreted carefully. Large organizations may have more repositories, more contributors, and more public discussion of development practices, all of which create more opportunities for a heuristic to detect a trace. In some cases the organization may also be a provider or enthusiastic user of an agent. The result establishes a difference in observed public-project adoption, not the cause of that difference or the rate across internal codebases.
Topic breadth provides another check against a narrow interpretation. Adoption appeared in web and cloud projects, database and automation work, AI-related projects, systems-oriented topics, and many other categories. Some topics were above the average, while foundational machine-learning and deep-learning topics were closer to it than a simple “AI projects adopt agents” story would predict. Very few sufficiently represented topics had near-zero adoption, though niche topics with fewer projects were less precisely measured.
Programming-language results were similarly broad. The study found comparable commit-level adoption across many popular languages and several less common ones. Lower-level languages such as C, C++, and Rust were not isolated from agent use, and languages with smaller communities also showed evidence of utility. The result should not be interpreted as proof that an agent performs equally well in every language. It shows that visible use is not confined to the languages with the largest training and developer ecosystems. The study’s classification relied mainly on file extensions at scale, which introduces its own uncertainty.
Breadth and intensity must then be separated. A project can have a guidance file, a branch label, or one attributed commit and therefore count as an adopter without using an agent for a large share of its work. Among file-visible projects, the study found wide variation in the number and maintenance of guidance files. Commit-level adoption was also distributed across experimental, limited, consistent, and pervasive categories. Larger and more established projects tended to show more evidence of having adopted but a smaller share of commits visibly assisted by agents. In other words, reaching a project and becoming central to its delivery are different transitions.
The guidance pattern makes that distinction concrete. More than half of projects with visible guidance or rule files had only one such file, and more than 85% had five or fewer. A smaller group maintained much larger collections, and projects also differed in how often they changed them. A one-time file can mark an experiment or a stable, sufficient convention; a frequently updated set can reflect active learning, changing tools, or a complex project. File count and change frequency are evidence about the presence and maintenance of guidance, not direct measures of successful use.
Commit intensity has the same ambiguity. A high visible share of AI-assisted commits can mean an agent is deeply integrated into delivery. It can also arise from a small number of post-adoption commits, a project’s preference for agent-authored changes, or a task mix with unusually large automated contributions. A zero visible ratio can mean no use, hidden use, or a project that adopted guidance and then stopped. This is why the study filters and interprets intensity categories cautiously rather than treating them as exact levels of reliance.
This distinction helps explain why the repository evidence is compatible with both rapid diffusion and cautious integration. A team may add guidance while learning how an agent fits its conventions. It may use an agent for a few features or bug fixes while keeping the rest of the workflow conventional. It may use several agents for different tasks, or hide attribution because a developer wants the final commit to represent the team rather than the tool. A project-level adoption flag collapses these cases unless the analysis also considers intensity and the way the evidence was generated.
The findings nevertheless move the burden of argument. It is no longer credible to describe coding agents as relevant only to a small group of enthusiasts or to greenfield prototypes. The evidence shows rapid growth and broad reach across public projects, organizations, topics, and languages. What it does not show is that every marked project has found a reliable division of labor between agent and developer. That question requires observing people and their repeated behavior, not only the artifacts that survive in version control.
The next distinction is consequently human rather than repository-based. A visible project signal can tell us that a tool has crossed some boundary into the codebase. It cannot tell us whether engineers tried it once, returned to it for ordinary tasks, or replaced an earlier way of working. To understand that transition, we need to separate the decision to start from the decision to stay.