AI-coding agents spread through peer pressure, not mandates

A Microsoft study found that AI-coding agent adoption among engineers spreads primarily through peer influence rather than mandates, with an engineer's odds of trying Copilot CLI rising 216% if more than a quarter of their skip-level peers used it. The research highlights that first use is socially driven while sustained use depends on workflow fit, warning that making adoption a metric can breed impression management and learned helplessness.

You have 1 article left to read this month before you need to register /register a free LeadDev.com account. Estimated reading time: 3 minutes Key takeaways: AI adoption spreads through peers, not mandates . If more than a quarter of an engineer’s skip-level peers used Copilot CLI, their odds of trying it rose 216%.- Trying and sticking are driven by different forces . First use is social; sustained use depends on workflow fit. Make adoption a metric and it becomes impression management. Leaders choose what peer adoption signals . When Microsoft rolled out command-line AI-coding agents https://leaddev.com/ai/best-ai-coding-assistants to tens of thousands of its engineers in early 2026, the biggest predictor of whether someone tried them wasn’t a mandate from the top, a training course, or a polished internal demo. It was whether the people around them had already done so. That’s the headline finding of a new paper https://arxiv.org/abs/2607.01418 from Microsoft researchers Emerson Murphy-Hill, Jenna Butler, and Alexandra Savelieva, who tracked adoption of GitHub’s Copilot https://leaddev.com/software-quality/github-copilot-make-commits CLI and Anthropic’s Claude Code https://leaddev.com/ai/why-microsoft-engineers-are-using-claude-code across the company. First use, they found, spread primarily through social networks. If more than a quarter of an engineer’s reviewer peers had used Copilot CLI in the previous fortnight, their odds of trying it rose by 54%. If more than a quarter of their skip-level peers had, the odds jumped by 216%. A direct manager’s use lifted them by 82%. The principle behind it is the seeing-doing effect: engineers watch colleagues find value from using a tool and update their own behavior accordingly. It also demonstrates how AI-coding adoption https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026 has become a culture problem rather than a tooling one. Your inbox, upgraded. Receive weekly engineering insights to level up your leadership approach. The wisdom of the crowd? “You could feel like, ‘wow, everyone around me is adopting https://leaddev.com/ai/ai-adoption-has-to-be-driven-from-the-top this tool, that’s really exciting – this is a safe place to learn,’” says Cat Hicks, a psychologist and author of The Psychology of Software Teams . “And there’s another version of adoption, right? That’s like, ‘wow, if I don’t do this, I’m going to look like a fool, and my boss is going to come down on me.’” The trouble is that, in the short term, the adoption metrics https://leaddev.com/ai/the-8-software-engineering-metrics-ai-broke from those two different environments look identical, Hicks notes. Push too hard and you breed what she calls “learned helplessness” – the sense among developers that their experience of the tool will never matter. The fact that the skip-level effect outweighed the influence of immediate peers is itself telling. It suggests engineers are reading adoption as a signal about what the wider organization values, which makes it all the easier for enthusiasm to transform into something more like an obligation. The distinction leaders should hold onto is between trying a tool and sticking with it. “Trying is social; staying is about fit,” says Daniel Russo, associate professor of software engineering at Aalborg University, whose own research https://doi.org/10.1145/3652154 found workflow compatibility to be the only significant direct predictor of intention to use generative AI https://leaddev.com/technical-direction/learning-to-trust-generative-ai tools. Similar data in the Microsoft study shows that while a manager’s visible use raised the odds of an engineer trying Copilot CLI by 82%, retention was far weaker. Compassion not compulsion Russo’s solution to that is blunt: “create pull, never push.” The moment adoption itself becomes a metric for token leaderboards https://leaddev.com/reporting/is-microsofts-engthrive-framework-immune-to-goodharts-law or usage KPIs, the whole thing risks becoming an impression-management exercise. Michaela Greiler, a software engineering researcher and code review specialist, warns of what she calls “code review surrender” – AI engineers waving through AI-generated pull requests https://leaddev.com/ai/as-ai-helps-us-write-more-code-whos-catching-the-bugs with a cursory check because the old paradigms no longer scale. “We value the production more over the verification and the understanding,” she says, “and then we also have an imbalance.” More like this So how should leaders https://leaddev.com/the-engineering-leadership-report-2026/ harness the social pressure the paper documents without weaponizing it? Hicks suggests threading a needle: create a shared norm and a shared experiment for the org, then signal that you, as a leader, are open to being corrected. Model the behavior, make the failures visible as well as the wins, and evaluate outcomes rather than usage. The seeing-doing effect is real, but whether developers see permission to experiment or pressure to perform is, in the end, a choice their managers make for them.