When Coding Agents Become Part of the Work
This series examines coding agents: software that uses a large language model in a repeated loop with tools to pursue a development task. The question is not simply whether these systems can generate code. It is when a tool that someone tries once becomes part of how software is actually planned, changed, reviewed, and shipped. That distinction gives the reader a way to judge the growing evidence without confusing excitement, activity, and value.
The distinction matters because agentic tools alter the scale and timing of assistance. A completion assistant usually offers a line or a block while a developer remains inside the edit loop. A coding agent can inspect a repository, change several files, run a build or test, react to the result, and sometimes commit the change or open a pull request. The developer may still supervise every sensitive action, or may allow the agent to work asynchronously for a while. In either case, the relevant unit is closer to a task or change set than to a line of code.
That shift creates a practical puzzle. A first use can be easy to record, especially when a tool leaves a configuration file or an attribution in version control. A durable workflow is harder to define. It requires a reason to return, enough project context to make delegation useful, feedback that can expose mistakes, and a human process that can own the resulting change. This series follows that transition from the agent’s operating loop to adoption evidence, human behavior, work outcomes, and the limits of what current measurements can establish.
A coding agent works on a task, not just a line
A coding agent begins with a goal, not necessarily with a precisely located edit. The model proposes an action; a harness interprets the proposal and invokes an available tool; the result—files found, compiler output, test failures, or another environmental response—goes back into the next interaction. The loop continues until the agent decides that the task is complete or the developer intervenes.
This sequence is important because software work is full of information that is not present in the initial request. A change may depend on an unfamiliar module, a project convention, an interface used elsewhere, or a test whose failure reveals a mistaken assumption. An agent with repository tools can gather some of that context as it works. It can search rather than wait for a person to identify every relevant file, and it can use builds and tests as feedback rather than treating its first answer as final.
The loop does not make the agent an independent owner of the software. The harness determines which tools exist and whether actions require approval. A developer can approve a sensitive command, interrupt the process, correct the task, or inspect the change before it enters the project’s normal review path. More autonomy changes the timing of human attention: the person may spend less time producing each small edit and more time specifying the goal, supplying local knowledge, interpreting failures, and deciding whether the result should be accepted.
Project guidance becomes part of this interface. Rules and guidance files can record conventions, architecture, commands, testing instructions, and other knowledge that would otherwise have to be rediscovered in each interaction. They are not magic instructions that guarantee a correct result. They are a way of moving some context into the agent’s working environment. If that context is missing, stale, or too general, the agent may produce a plausible change that conflicts with the project’s unwritten expectations.
The result is a different control problem from autocomplete. The question is no longer only whether a proposed line looks reasonable. It is whether a system has enough context to pursue the task, enough feedback to detect a wrong direction, and enough human oversight to decide what the repository should retain. A trial may demonstrate that the loop can complete one task. A workflow requires that these control points continue to work across recurring tasks.
The transition therefore has more than one state. A tool can be technically capable before it is socially trusted, and socially popular before it is integrated into review and delivery. Keeping those distinctions visible will matter when we turn to the evidence.
Two views of the shift: projects and people
The supplied studies make the transition visible from two different vantage points. The first mines public GitHub projects for traces left by coding agents. The second follows engineers inside Microsoft using telemetry and pull-request data. One view shows how widely the category has reached across projects; the other shows how first use and continued use differ inside an organization. Neither should be treated as a complete census, but together they make “this is only a novelty” difficult to sustain as a general description.
In the GitHub study, researchers examined 128,018 selected projects and looked for several kinds of evidence: agent configuration or guidance files, references to ignored files, authorship or co-authorship in commits, branch conventions, and pull-request labels. They estimated that between 22.20% and 28.66% of those projects showed traces of coding-agent adoption by February 21, 2026. The lower figure is a conservative combination of the observed file- and commit-level signals. The higher figure extrapolates from the portion of file-visible projects whose commit activity was not visible, so it is explicitly a rough approximation.
The timing is as important as the percentage. The cumulative curve accelerated after the initial release of Claude Code in early 2025, moved faster again around the release of several agents in the middle of that year, and picked up at the start of 2026. Adoption was not restricted to tiny, new projects. It was visible in large organizations, mature codebases, many topics, and both common and less common programming languages. That breadth is evidence that coding agents had entered a range of real development contexts, not that every adopting project had made them central to delivery.
The Microsoft study supplies the missing human dimension. During an early-2026 rollout, it separated an engineer’s first opening of Copilot CLI from sustained early use. That distinction revealed different patterns. Visible use by professional peers and managers was strongly associated with the odds of trying the tool. Prior use of IDE Copilot also made a trial more likely. But the same prior IDE users were slightly less likely to retain the command-line tool, while existing pull-request activity was associated with both trying and staying. The result is a useful warning against treating familiarity, activation, or access as a synonym for habit.
The two studies answer different questions. Repository mining can show that an organization or project has left a detectable mark, and at scale it can reveal the spread of a category. Enterprise telemetry can connect activity to an eligible population and distinguish a first event from a later pattern. The public record is broader but partial; the enterprise record is more direct for its setting but limited to one company, one rollout, and one early period. Their numbers should illuminate one another, not be added together.
This two-lens view also changes the meaning of “real.” A project may contain guidance for an agent but show little attributable commit activity. A developer may use an agent extensively but commit manually after reviewing the result. A team may try a tool because a manager or peer has made it visible, then abandon it because the tool does not fit the work. Real workflow is not one observable mark. It is a relationship among repeated use, local context, task opportunities, feedback, and accepted changes.
The claim we can—and cannot—make
The evidence supports a restrained but consequential conclusion: coding agents are moving rapidly from experimental products toward ordinary software-work infrastructure in at least some settings. The transition is visible in the growth of project traces, in the spread across project types, and in enterprise patterns where use persists beyond a first encounter. It is also visible in the kind of work agents can touch: larger change sets, features, bug fixes, documentation, tests, and parallel streams of activity.
That conclusion is narrower than saying that agents improve software. A repository trace tells us that a detectable configuration, attribution, branch, or label exists. It does not tell us how much of the change the agent produced, how closely a developer supervised it, whether the work would have happened otherwise, or whether the result remains healthy months later. The GitHub researchers validated their detection heuristics and found few legitimate false positives in sampled artifacts, but they also documented many ways for use to remain invisible. Absence of a trace is not evidence of absence.
Merged pull requests are similarly informative and limited. The Microsoft study found a substantial association between agent use and merged-PR throughput, including a persistent pattern during its roughly four-month observation window. That is evidence that agentic command-line tools can coincide with movement in a concrete delivery metric. It is not a complete account of delivered value. A merged PR can be small or large, useful or redundant, easy or expensive to maintain. Larger agent-assisted changes may represent ambitious work made feasible, or they may carry more churn and review burden.
The unresolved quality question is therefore not a ritual disclaimer placed after the interesting results. It is part of the subject. If a tool makes code cheap to produce, a team may attempt more features, prototypes, refactorings, and tests. That can be valuable. It can also increase the amount of code that must be understood, reviewed, tested, and maintained. The supplied studies do not settle that trade-off: they call for better measures of defects, complexity, reversals, durability, cost, and long-term maintenance.
The most useful practical judgment is consequently conditional. Coding agents have become part of a real workflow when people return to them for recurring work, can provide enough project-specific context, receive meaningful feedback, and integrate the resulting changes into human-owned review and delivery. Adoption statistics can show that the possibility is widespread. They cannot by themselves show that the conditions are present in a particular team.
That is the question this series will keep in view: not whether an agent can produce an impressive first result, but how the loop, the people around it, and the repository processes together determine whether the result becomes dependable work.