You have 1 article left to read this month before you need to 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 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 from Microsoft researchers Emerson Murphy-Hill, Jenna Butler, and Alexandra Savelieva, who tracked adoption of GitHub’s Copilot CLI and Anthropic’s 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 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 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 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 found workflow compatibility to be the only significant direct predictor of intention to use 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 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 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 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.