Buying Licenses Is Not an AI Adoption Strategy

Somewhere in your last board deck is a slide that says your engineering org has adopted AI. What it probably means is that you bought seats.

I've now been inside enough engineering organizations to see the pattern clearly. The company buys Copilot, Cursor, or Claude Code for everyone. Six months later, the CTO gets asked what the spend is producing. The honest answer, more often than not: a handful of engineers use it constantly, a larger group opens it occasionally, and a meaningful chunk of licenses have never been activated.

That's not adoption. That's procurement.

The gap nobody budgets for

Rolling out an AI coding tool looks deceptively like rolling out any other developer tool. You did fine with GitHub, with Datadog, with Slack. Why would this be different?

Because those tools replaced a workflow that already existed. Source control, monitoring, chat — engineers knew what job the tool was for. AI coding tools ask engineers to change how they work, not just where they click. An engineer who has spent fifteen years building the muscle of writing code by hand is being asked to delegate, review, and orchestrate instead. Some make that shift naturally. Most don't, not without help.

The result is a bimodal distribution I see almost everywhere: a few power users getting real leverage, and a long tail of engineers whose usage rounds to zero. The average looks fine. The median tells the truth.

What license counts hide

If you're reporting seat counts or even weekly active users to your board, you're measuring the wrong layer. A seat that gets opened once a week to autocomplete a unit test is not the same as a seat that's delegating migrations and refactors. Both count as "active."

The questions that actually matter are harder: Which workflows have engineers actually changed? Where is AI-generated code getting stuck in review? Are your senior engineers using these tools differently than your juniors, and what does that tell you? Is cycle time moving, or just lines of code?

None of that shows up in the vendor's usage dashboard. Vendors have every incentive to report numbers that make renewal easy.

What a real strategy looks like

Teams that get past the bimodal distribution tend to do a few unglamorous things. They pick specific workflows to change — code review prep, test coverage, legacy refactoring — instead of telling engineers to "use AI more." They identify their power users and put them to work teaching, rather than letting the gap between enthusiasts and everyone else widen. And they measure workflow integration, not activity: what percentage of PRs involved AI assistance, what happened to review time, where engineers report friction.

That last part matters most. If you can't describe your AI adoption in terms of changed workflows and delivery metrics, you don't have an adoption problem you can manage. You have a spend you can't defend.

The pressure to show ROI on AI tooling is only going up this year. The teams that will handle that pressure well aren't the ones with the most licenses. They're the ones who treated adoption as a program — with an owner, a baseline, and a number that moves.

If you're not sure where your team actually sits on that curve, that's the first thing worth finding out. It's exactly what our AI readiness assessment is built to answer.