Diffusion of innovation and the AI adoption curve in software development
Ask a CIO to describe the AI adoption curve software development follows on their own team, and you'll often get two contradictory answers in the same breath: "adoption is exploding" and "half the team still hasn't installed anything." Both can be true.
The easy explanation is personality: some engineers are curious, others are stubborn. Applying diffusion of innovation AI adoption thinking to engineering teams tells a different story, one about timing and evidence, not temperament.
A 2003 academic review of Everett Rogers' work on how new ideas spread describes innovators as the venturesome minority who try things first, while laggards take far longer than the rest of the population to come around.
That's the real question for a CIO: not "why is this engineer slow," but "where does my team sit on this curve, and what's actually holding the next segment back." The AI adoption curve software development follows gives you language for that question, not a verdict on any one engineer.
Sources: Diffusion of Innovations, by Everett Rogers (1995)
The five adopter groups: from eager testers to reluctant last movers
Rogers grouped adopters into five stages, and the boundaries matter more than the labels. Innovators are roughly the first 2.5% of any population to try something new, according to an academic summary of his research.
No study sorts real engineers into these five groups specifically for Claude, Codex or other AI coding tools. Mapping Rogers' categories onto AI tool adoption here is our own editorial reading of the adoption and sentiment data below, not a direct finding from any single study.
Early adopters follow soon after, watching innovators for proof before they commit. Early and late majority make up the bulk of any team, and laggards, the final group, take noticeably longer than average to adopt anything, including AI coding tools.
One trait explains most of the gap between groups: complexity. Of the factors that shape how fast people adopt a new tool, complexity is the only one that consistently slows adoption down. Everything else nudges people forward; complexity holds them back.
| Adopter group | Typical stance | What moves them to try it | What a leader notices |
|---|---|---|---|
| Innovators | Actively seek out new tools before being asked | Curiosity alone; no proof needed | Someone already using Claude or Codex without a mandate |
| Early adopters | Watch innovators, adopt once they see it work | Visible peer success | Informal how-tos and internal advocates |
| Early majority | Deliberate, wait for practical proof | Evidence the tool fits their actual workflow | Adoption climbs once early adopters share results |
| Late majority | Skeptical, adopt once it feels normal | Peer pressure and lowered perceived risk | Usage rises mostly after policy or clear expectation |
| Laggards | Cautious or resistant, adopt last if at all | Little beyond necessity | Tools sit installed but unused, or never installed |
Sources: Diffusion of Innovations, by Everett Rogers (1995), Diffusion of Innovations - TheoryHub - Academic theories reviews for research and T&L
Why some engineers install Claude or Codex on day one
Innovators and early adopters aren't braver, they're simply less bothered by complexity and less dependent on proof from others. If a tool is easy to try in isolation, on one file or one function, they'll try it.
That matches the broader numbers. Stack Overflow's 2025 Developer Survey, answered by 33,662 developers on this question, found 84% are using or already planning to use AI tools in their development process.
A slim majority, 51% of professional developers, told Stack Overflow they use AI tools every day. That's not fringe behavior anymore. The innovators and early adopters on most teams have already normalized daily use, sanctioned or not.
Contrast that with an engineer on a legacy system with strict change control and a security review for any new tool. Low complexity for one team can be high complexity for another; the tool didn't change, the context did. The contrast between early adopters and laggards on AI tools often comes down to friction and proof, not character.
Sources: Diffusion of Innovations - TheoryHub - Academic theories reviews for research and T&L, AI | 2025 Stack Overflow Developer Survey
What developer surveys show about real AI use
Usage keeps climbing even as trust erodes. Stack Overflow's follow-up analysis, published in December 2025, found adoption reached 80% of developers even as confidence in AI-generated answers slipped. That combination is typical of majority segments: people use a tool without fully trusting it.
Most of that use stays narrow. Nearly 72% of developers told Stack Overflow that full prompt-to-app "vibe coding" isn't part of their professional work; the common pattern is completion, boilerplate and debugging, not letting a model run unsupervised.
DORA's 2025 State of AI-assisted Software Development report, drawing on almost 5,000 technology professionals surveyed in June and July 2025, found AI's effect on delivery isn't automatically positive: it amplifies whatever strengths or weaknesses a team already has.
That framing is a large part of why this year's report matters for understanding why adoption plays out so unevenly across teams, as its foreword author wrote:
Among the same DORA respondents who use AI at work, a large share reported it increased their productivity. That's a self-report, not a measured output, so treat it as a signal worth investigating rather than a verified result.
“I’m so excited by how this year’s research helps us better understand how we can use AI to improve software.”
— Gene Kim, Described on the page as a Researcher, 'Vibe Coder,' and co-author of Vibe Coding, The Phoenix Project, The DevOps Handbook, and Accelerate · Source: https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
DORA also found platform engineering, the practices that make AI tools easier to plug into daily work, had reached 90% adoption among surveyed organizations. Tooling maturity tends to travel with AI adoption, not behind it.
Sources: Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here - Stack Overflow, DORA | Balancing AI tensions: Moving from AI adoption to effective SDLC use, https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
Why engineers don't use AI coding tools yet
The late majority and laggards aren't the problem executives assume they are. McKinsey's global survey of 3,613 employees and 238 executives, fielded in October and November 2024, found employees are broadly more ready for AI than their leaders think; the biggest barrier to scaled adoption is leadership, not employee resistance.
That reframes the conversation. If an engineer hasn't opened Claude or Codex, the default assumption shouldn't be "they don't want to." It's more often "nobody gave them a clear, low-risk reason to start."
Consider another explanation for engineers who wait rather than try tools themselves: many simply don't know whether using an AI tool on production or client code is officially sanctioned, and asking can feel riskier than staying quiet.
The same McKinsey survey found a large minority, 41%, remain apprehensive about AI and will need real support before they adopt it. Picture a 40-person engineering org: that's roughly two full squads waiting for someone to show them it's safe.
Sources: AI in the workplace: A report for 2025 | McKinsey
The trust gap and the hidden verification tax
Trust, not ability, is the biggest lever here. DORA's 2025 survey found 30% of developers report little to no trust in AI-generated code. For engineers who've been burned by a confidently wrong suggestion, that distrust is rational, not defensive.
That distrust likely creates what we'd call a verification tax: every AI suggestion still needs a human to read, test and judge it before it ships. DORA's analysis of Google engineers' comments found AI mainly amplifies whatever strengths or weaknesses a team already has, so it's a reasonable inference that a low-trust team pays that tax in extra double-checking rather than shipping faster.
Self-reported productivity gains tend to run ahead of what controlled measurement finds. A study-design paper on AI-assisted coding notes that developers consistently report large gains while independent measurements tend to show more modest ones, and points out how much existing evidence still rests on self-report rather than objective measurement. That pattern echoes the DORA productivity figures already noted above.
That gap between perception and proof is exactly why the late majority hesitates. They're not being difficult. They're waiting for evidence they trust, which is precisely what Rogers' model predicts they'll do.
Sources: Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here - Stack Overflow, DORA | Balancing AI tensions: Moving from AI adoption to effective SDLC use, Towards Decoding Developer Cognition in the Age of AI Assistants
The barriers are organizational, not personal
If leadership is the biggest barrier to scaled AI adoption, as McKinsey's survey found, then the fix isn't another all-hands demo. It's removing the specific organizational friction holding each segment back.
A survey of roughly 500 organizations on AI governance and risk, fielded between December 2025 and January 2026, found 60% cite knowledge and training gaps as the primary barrier to building trusted AI practices. For a lot of teams, training isn't a nice-to-have, it's the actual blocker.
The same survey found organizations that assign clear ownership for responsible AI practices reach meaningfully higher maturity than those without an accountable owner. Someone has to own AI adoption the way someone owns uptime or security.
Framed as an early adopters vs laggards AI tools problem, this can look personal. It isn't: none of this is about weeding out laggard personalities. It's about checking whether the gap is really skills, trust, workflow friction or culture, because each calls for a different response.
Structured surveys covering usage, skills, trust and leadership support are one way to answer those questions without relying on install counts or anecdotes. AI Adoption Score's AI Adoption Barriers Survey, for instance, is built to uncover the real reasons a team isn't using AI more effectively, rather than guessing at motive.
Sources: AI in the workplace: A report for 2025 | McKinsey, Responsible AI: Overcoming adoption barriers and risks | McKinsey & Company
Move the curve instead of guessing where people stand
You won't move the late majority with a company-wide mandate email. Rogers' model says people in the middle and later segments look to peers they trust, not leadership announcements, before they change behavior.
Start by finding the engineers already using Claude, Codex or another approved tool on their own, and make their workflow visible instead of hidden. That's your fastest, cheapest lever toward the early majority.
Then look at what's actually stalling the rest: is it a skills gap, a trust gap, a workflow that doesn't fit, or a culture where trying new tools feels risky? Each needs a different fix, and none are solved by a single training session.
Where each team sits on the curve shifts as visible peer evidence builds, so the barriers worth fixing this quarter may not be the ones worth fixing next quarter.
That's where AI Adoption Score's maturity levels come in: mapping every person, team and department to one of five levels across skills, usage, culture, impact, vision and governance gives you a repeatable way to see where each group actually stands, instead of relying on install counts.
Stop guessing which segment your engineers are in and start asking them. The AI adoption curve software development follows isn't fixed, it just needs a nudge from evidence your team actually trusts.
Sources: Diffusion of Innovations, by Everett Rogers (1995)
Frequently asked questions
How long does it take an engineering team to move through the adoption curve?
There's no fixed timeline; Rogers' model describes an S-shaped pattern, not a schedule. Movement speeds up once early adopters produce visible results peers trust, and slows again when trust, skills or workflow friction get in the way. Re-checking periodically matters more than picking a target date.
Who should own tracking AI adoption across an engineering org?
Someone specific, not a rotating committee: organizations with clear ownership for responsible AI practices reach meaningfully higher maturity than those without one. In practice, name one accountable person, often a CTO, Head of AI or L&D lead, give them visibility into usage and barrier data across teams, and set a fixed review cadence.
Should we just count tool logins instead of surveying engineers?
Login counts tell you who opened a tool, not whether they trust it, use it well, or why others haven't started. Surveys covering usage, skills, barriers and culture surface the reasons behind the numbers, which is what actually tells you which intervention to choose.
How often should we re-measure where teams sit on the curve?
At least once or twice a year. Rather than just re-checking usage percentages, look for movement in trust scores, which barriers engineers cite most often, and whether early adopters' habits have started showing up among the early majority; those shifts matter more than raw login counts.
Sources: Diffusion of Innovations, by Everett Rogers (1995), Responsible AI: Overcoming adoption barriers and risks | McKinsey & Company
