The Diffusion of AI Innovation: 18 Engineering Personas on the Adoption Curve

The way engineers adopt AI has less to do with how capable the models become and more to do with how much control, trust and identity each developer is willing to hand over.

Beyond the Binary of "Pro-AI" and "Anti-AI"

Walk into any engineering organisation today and ask how the team uses AI.

On paper, the answer usually sounds uniform. Everyone has access to the same coding assistants, the same chat interfaces and the same internal guidelines.

Look closer at the pull requests, Slack channels and sprint ceremonies, and a completely different picture emerges.

In 1962, Everett Rogers introduced the Diffusion of Innovations curve, grouping how people adopt new technology into five segments: Innovators, Early Adopters, the Early Majority, the Late Majority and Laggards.

When we map software engineers onto that curve today, the axis is not simply about who clicked "Install" first.

It is about how much agency we delegate to machines.

Over the past few months, while testing different coding agents and watching how teams work around them, I started cataloguing the distinct patterns of behaviour that show up across engineering teams.

They fall into 18 personas across six groups, ordered from the most AI-reliant to the least. Similar habits naturally pair up as two sides of the same coin.

1. The Delegators (Innovators, ~2.5%)

At the far left of the curve sit the engineers who have already crossed the threshold from assisted coding to delegated execution. AI does most of the heavy lifting here. Where they differ is in how openly they talk about it.

• 1a. The Ghostwriter: Has AI do all of his work and never mentions it once. The tickets close on time, the architecture docs read suspiciously like a polished textbook and the commit history is immaculate, yet the word "prompt" never crosses his lips.
• 1b. The Autopilot: Never actually around. His agents handle his work, his PRs and his standup updates. While the rest of the team debates implementation details, his digital proxies are already responding to review comments and rebasing branches.
• 2. The Disclaimer: Adds "AI helped with this" to every single thing he shares. Whether it is a 400-line migration script or a three-sentence Slack reply, he treats every output like a regulated financial disclosure.

The tension inside this group is fascinating. It reveals that we still do not have a shared cultural norm for authorship when an agent writes the code.

2. The Experimenters (Early Adopters, ~13.5%)

The Experimenters treat the AI ecosystem as a live laboratory. They are always trying new tools, new agent frameworks and new hardware setups, often running several in parallel just to see where the boundaries break.

Nowhere is the divide clearer than in how they handle credentials and account access.

• 3a. The YOLO Agent Tester: Tries every new personal agent and hands each one his credentials without a second thought. OAuth tokens, inbox access, terminal permissions: if an agent asks for it to get the job done, he clicks "Allow".
• 3b. The Burner Account Architect: Would never give an agent his own credentials, so he sets up new accounts just for the agents to play with. Dedicated email addresses, isolated sandboxes and scoped tokens keep his real digital identity behind a blast wall.
• 4. The Tool Hopper: Switches AI coding tools every week and never finishes setting one up. Monday is Cursor, Wednesday is Windsurf, Friday is a terminal-based agentic workflow, and none of them ever get past the default configuration.
• 5. The Garage Datacenter: Obsessed with local inference. Runs models on a GPU rig at home and complains about VRAM. Cloud APIs are for casuals; he wants quantised weights running on his own silicon, even if it heats the spare room.

Between 3a and 3b lies one of the most important architectural questions in software today:

How do we give agents enough access to be genuinely useful while keeping their permissions clearly bounded?

The Burner Account Architect isn't being paranoid. He is manually building the delegated trust layer that our operating systems and identity providers haven't finished shipping yet.

3. The Optimisers (Early Majority, ~34%)

Once a technology crosses the chasm into the Early Majority, the focus shifts from novelty to efficiency. The Optimisers are less interested in autonomous stunts and much more focused on squeezing repeatable value out of the models in daily production work.

• 6. The Prompt Whisperer: Thinks his prompt library is worth more than the codebase. He maintains version-controlled system instructions, reusable markdown templates and carefully tuned rules files that he guards like proprietary algorithms.
• 7. The Token Accountant: Tracks AI spend per PR and optimises context windows for fun. He knows the exact cost difference between models, prunes unnecessary files from context before every query and treats token efficiency like memory management in the 1990s.

In many ways, the Token Accountant is the spiritual successor to the performance engineer profiling memory allocations in Instruments. The resource constraint has simply moved from RAM to the context window.

4. The Broadcasters (Late Majority: The Hype Wing, ~34%)

Not everyone on the adoption curve is writing code with AI all day. As AI becomes the dominant industry narrative, a large contingent engages with it primarily as a spectator sport or an organisational talking point.

They love talking about AI much more than actually using it.

• 8a. The Launch Event Correspondent: Posts the keynote video for every new model, the day it drops. Within four minutes of a livestream ending, the link is in the team channel with a fire emoji.
• 8b. The Late Adopter Evangelist: Loves every new AI breakthrough and shares it three weeks after everyone else. He discovers a feature the Experimenters broke a month ago and announces it like a dispatch from the future.
• 9. The Benchmark Lawyer: Wins every argument by quoting leaderboard scores. Ask him which model handles a refactor better and he will recite SWE-bench and MMLU percentages rather than opening an editor.
• 10. The Town Hall Regular: Gets the mic at every all-hands and asks the same thing each time:

"So what's our AI strategy?"

Every large company has at least one Town Hall Regular. The question is rarely bad, but it highlights the gap between executive slide decks and the messy reality of shipping software.

5. The Skeptics (Late Majority: The Guardrails Wing)

Sharing the Late Majority segment with the Broadcasters are the Skeptics. Unlike the Broadcasters, they actually read the code that lands in the repository. They use AI in small, controlled doses, and they watch its output like a hawk.

• 11a. The Quiet Skeptic: Uses AI in moderation and silently judges the Ghostwriter. He will use an LLM to generate a regex or boilerplate test, read every line twice and quietly raise an eyebrow when a colleague submits a 2,000-line PR in twenty minutes.
• 11b. The Review Bouncer: Spots AI-generated code instantly and rejects it on sight. Hallucinated helper methods, unnecessary comments explaining obvious loops and over-engineered abstractions do not make it past his pull request reviews.

Here is the uncomfortable truth for the Delegators:

Every healthy engineering team needs a Review Bouncer.

When code generation becomes virtually free, code review becomes the primary bottleneck for system integrity. Without someone enforcing architectural standards at the gate, velocity quickly turns into technical debt.

6. The Holdouts (Laggards, ~16%)

At the far right of the curve are the engineers who have opted out altogether. Their reasons range from principled security stances to lasting battle scars.

• 12a. The Resistance: Hates AI and is obsessed with privacy. Every prompt is a data leak waiting to happen. Proprietary code, customer data and internal architecture stay strictly on local disk, far away from any third-party inference endpoint.
• 12b. The 2024 Survivor: Tried AI once in 2024, saw it hallucinate, and has held the grudge ever since. He asked an early model to write a library call two years ago, watched it invent a non-existent API and decided the entire paradigm was a party trick.
• 13. The Bystander: Doesn't use AI and doesn't care whether anyone else does. He opens his editor, writes his code, ships his tickets and goes home. The hype cycle simply passes around him.

It is easy to dismiss the Holdouts, but 12a and 12b exist for rational reasons. Early models did hallucinate confidently, and enterprise data privacy is a genuine concern when third-party providers are involved.

Where Does the Curve Go Next?

The most interesting thing about this distribution is that nobody stays in one persona forever.

An engineer might be a Burner Account Architect when testing a new personal agent over the weekend, a Token Accountant when optimising an enterprise LLM pipeline on Monday morning and a Review Bouncer when reviewing a teammate's pull request on Tuesday afternoon.

As models improve and delegated authorisation matures, the curve will inevitably shift.

The 2024 Survivor will eventually run out of excuses as tool-use and verification loops close the hallucination gap. The YOLO Agent Tester will eventually hit a security incident that turns him into a Burner Account Architect. And the Ghostwriter and the Review Bouncer will have to find a truce around what "production-ready" means when humans and agents co-author the codebase.

There is one conclusion I keep returning to.

The maturity of an engineering team won't be measured by how many people sit on the far left of this curve.

It will be measured by whether the Experimenters, the Optimisers and the Skeptics can learn from each other before the Autopilot merges to main.