On July 1, 2026, Emerson Murphy-Hill, Jenna Butler, and Alexandra Savelieva posted a paper studying Microsoft's early-2026 rollout of Claude Code and GitHub Copilot CLI. The headline number is hard to ignore: adopters merged roughly 24% more pull requests than they would have otherwise, across a four-month window.
That does not mean every engineer should get an agent tomorrow and be left alone with a budget meter. The useful part of the study is more subtle. First use spread through social networks. Retention tracked coding activity more than demographics. Token spend can reach millions of dollars a year if adoption is misunderstood.
Here is the checklist I would use if I were rolling out CLI agents to a real engineering org.
1. Treat adoption as social infrastructure
The study says first use spread mainly through social networks, not through a top-down memo. That matches what I see in practice. An agent becomes normal when a respected engineer shows a diff, the commands they ran, and the review comments that caught the rough edges.
I would seed a rollout with a small group of visible builders. Pick people who already write tests, review carefully, and explain their workflow without turning it into theater. The first goal is not maximum seat activation. It is credible examples that other engineers can copy.
2. Measure merged work, but do not worship it
Merged pull requests are a clean proxy because they are observable. They are also incomplete. A PR can be tiny, risky, low-value, or mostly cleanup. The Microsoft paper is careful about that distinction, and rollout owners should be too.
A better dashboard pairs output with friction:
| Signal | Why it matters |
|---|---|
| Merged PRs | Shows throughput movement |
| Review cycles | Catches low-quality agent output |
| Revert rate | Finds hidden damage |
| CI failures per PR | Exposes sloppy automation |
| Active agent cost | Keeps enthusiasm tied to budget |
The agent should improve the system, not just inflate one counter.
3. Put the agent where engineers already work
CLI agents won because they sit in the workflow. Anthropic's Claude Code docs describe a tool that can read project instructions, use project memory, run repeatable skills, work from the terminal, continue across surfaces, and participate in CI or chat workflows. GitHub's Copilot CLI docs frame the same basic direction from the GitHub side: agent sessions, custom instructions, rollbacks, remote control, cloud and local sandboxing, and eventually more autonomous task handling.
That is the real shift. The model is not just answering questions. It is becoming an execution surface for software work.
If the rollout requires engineers to leave the terminal, paste huge context blocks, or manually reconstruct state every session, it will become a novelty. If it lives beside git, pnpm, gh, and the test runner, it has a chance.
4. Start with narrow jobs, then widen permissions
GitHub's autopilot docs are blunt about the tradeoff. Autopilot mode can keep working until the task is complete, blocked, interrupted, or hits a continuation limit. It is useful for well-defined tasks like tests, refactors, CI failures, and batch work. It is weaker for ambiguous product judgment.
That is exactly how I would stage permissions:
- Read-only exploration.
- Local edits behind explicit approval.
- Test and lint execution.
- Limited autonomous continuation.
- Broader permissions only for trusted repos and task shapes.
The mistake is treating autonomy as a binary. It is a dial, and most teams should turn it slowly.
5. Budget in tokens, not vibes
The Microsoft paper calls out the obvious but uncomfortable enterprise problem: at scale, token spend can run into millions annually. That means agent adoption needs FinOps discipline from day one.
I would track sessions as a first-class event stream, not as an afterthought. Something this simple is enough to start:
type AgentSession = {
tool: 'claude-code' | 'copilot-cli' | 'codex' | 'other';
repo: string;
taskType: 'test' | 'refactor' | 'bugfix' | 'feature' | 'review';
startedAt: string;
mergedPr?: string;
estimatedCredits: number;
humanReviewMinutes: number;
reverted: boolean;
};
The important part is connecting spend to task shape and downstream result. Otherwise the budget conversation arrives late, and it arrives angry.
6. Assume your measurement is undercounting
A separate June 2026 arXiv census looked across more than 180 million repositories and found that single-signal detection misses a lot of agent activity. Bot-account lookup recovered only 28,154 Claude Code commits in one snapshot, while multi-method detection found 850,157. That is a 30x recall gap.
This matters inside companies too. If you only count obvious bot commits, you will miss developers using local agents under their own identity. If you only count config files like CLAUDE.md or AGENTS.md, you will miss active use that never leaves a durable setup file.
Instrumentation should respect that agent work is messy. It can appear in commits, PRs, local sessions, config files, CI logs, and review comments.
7. Roll out with review culture, not agent worship
My strongest opinion: CLI agents amplify the engineering culture they land in. A team with clear tasks, fast tests, small PRs, and serious review gets more leverage. A team with vague tickets and weak ownership gets faster ambiguity.
The practical rollout motion is boring, which is why it works:
- Publish local instructions per repo.
- Create examples for three recurring tasks.
- Track cost and review outcomes.
- Rotate demos through real engineers, not vendor decks.
- Keep permissions scoped until the failure modes are known.
The point is not to prove that agents are magic. The point is to make the useful path repeatable and the risky path visible.
The next phase of coding-agent adoption will not be decided by which launch post has the strongest benchmark table. It will be decided by which teams turn agent use into a disciplined engineering loop: observable, reviewable, budgeted, and boring enough to survive after the novelty fades.