You bought the seats. You announced the rollout. A few engineers are visibly faster now.
Everyone else is still writing code the way they were six months ago.
This is the most common outcome of an AI coding tool rollout, and it is rarely discussed honestly. The tool works. The rollout did not.
What actually happened
Buying licenses removes one barrier: cost. It does nothing about the other barrier, which is bigger: knowing how to use the tool well enough that it is faster than not using it.
For an engineer who already experiments with new tools on their own time, that second barrier barely exists. They tried it, hit a few rough edges, adjusted their habits, and kept going. Three months later they are visibly faster.
For most of the team, that barrier is real. They tried it once on a task where it did not help, decided it was overhyped, and went back to what they know works. Nobody followed up. Nobody showed them a better use case. The tool sits in their toolbar, mostly unused.
Why this matters more than it looks like it does
A few fast engineers feel like progress. Leadership sees usage numbers, a couple of visible wins, maybe a Slack message about a bug fixed in minutes instead of an hour.
But team output is not set by your fastest people. It is set by the gap between your fastest and slowest, because code review, planning, and delivery all depend on the whole team moving together.
If three engineers ship twice as fast and the rest ship the same as before, your team's overall velocity barely moves. Worse, the fast engineers start generating more code for the same reviewers to read, so review load goes up without a matching drop in cycle time.
The signals that adoption is uneven
You do not need a dashboard to see this. A few honest questions will surface it:
- Can you name the same three or four people every time someone mentions using AI well?
- Do PRs from certain engineers look different in size or shape than everyone else's?
- When you ask the team how they use Claude Code or Copilot, do most answers sound vague ("I use it sometimes") compared to a specific few who describe an actual workflow?
- Has anyone on the team ever shown another engineer how they use the tool, or has it stayed private?
If most answers point to the same small group, adoption is concentrated, not distributed.
What actually spreads adoption
Uneven adoption is not a motivation problem. It is a workflow problem. Engineers do not need to be convinced AI is useful. They need a specific, repeatable way to use it that fits how the team already works.
That means:
- picking one or two concrete workflows the whole team will use the tool for, not "use it however you want"
- setting a shared standard for what a good AI-assisted PR looks like
- having someone whose job includes noticing who has not adopted the workflow yet, and why
- treating the first month as a rollout with a plan, not a license purchase with an announcement
None of this requires more tooling. It requires someone treating adoption as a real project instead of assuming it will happen on its own once the tool is available.
What good looks like
A team with real adoption does not look like everyone using AI the same amount. It looks like the team having a shared answer to "how do we use this," with enough consistency that a new hire could learn the pattern from any engineer, not just the two or three who figured it out first.
If your team bought the tools months ago and the gap between your early adopters and everyone else has not closed, that gap will not close by itself. Book a call if you want help figuring out why adoption stalled and what would actually spread it. If I'm not the right person, I'll say so.