Why Engineers Try Coding Agents—and Keep Using Them

Coding-agent adoption has two human stages that are easy to collapse: the first decision to open a tool and the later decision to make it part of ordinary work. This chapter focuses on that difference in Microsoft’s early-2026 Copilot CLI rollout. It gives the reader a behavioral way to judge whether a rollout is creating a durable practice, rather than treating every activation as evidence that engineers have changed how they work.

The distinction matters because the conditions for curiosity are not necessarily the conditions for repetition. A peer may make a tool visible enough to try, while the tool’s fit with a person’s tasks determines whether they return. Someone familiar with AI assistance may be willing to experiment but still prefer an existing workflow. Someone with a steady stream of pull-request work may have more opportunities to discover a useful role for an agent. The enterprise evidence makes these differences visible by modeling first use and retention separately.

First use is an event; retention is a pattern

The Microsoft adoption study began with a deliberately defined population: software engineers who could have tried Copilot CLI at the rollout cutoff. Engineers who already had access to Claude Code through a different managed path were excluded, as were other cases that would have made the adoption decision less uniform. The study then watched activity from January 5 through April 29, 2026. That design does not describe every developer at Microsoft, but it gives the initial-use question a meaningful denominator: people who were eligible to make the same basic choice.

Initial use was an engineer’s first recorded opening of Copilot CLI during the post-rollout period. Each eligible engineer contributed observations only while they had not yet used the tool; after the first activity, they left the “at risk of first use” population. Retention was a different outcome, defined among adopters as activity on at least five of the fourteen days beginning with first use. The threshold approximated use on roughly half of working days during the first two weeks, separating “tried and stayed” from “tried and abandoned” for the purposes of this study.

That threshold is an operational definition, not a universal law of habit formation. A developer who uses an agent intensely for one specialized task might be valuable without meeting it. Another developer might meet the threshold during an enthusiastic experiment and later stop. The strength of the definition is comparative: it prevents an initial opening and a sustained early pattern from being counted as the same event. Any judgment about a rollout should preserve that separation, even if it chooses a different retention window.

The distinction also affects the data structure. Initial use is observed while an engineer remains eligible and has not yet appeared in the activity logs, so the set of people who could still adopt becomes smaller each week. Retention is measured only after the first event, among people who have already crossed that boundary. A factor can therefore be associated with entering the population without being associated with remaining in it. Treating the two outcomes as one adoption rate would hide exactly the point at which a rollout is succeeding or losing momentum.

stateDiagram-v2 state "Eligible engineer" as E state "First use" as F state "Early retained use" as R state "Trial without retention" as X [*] --> E E --> F: First activity; peer visibility and prior IDE use raise entry odds F --> R: At least 5 of 14 days; prior PR cadence helps persistence F --> X: Fewer than 5 of 14 days; prior IDE use has a lower retention association