Your Best Coder Will Be Your Lowest AI Adopter

The strongest pure coder I’ve onboarded to Claude Code is the lowest-usage adopter. Plan paid. Tool installed. Paired session done. I still haven’t found the move that lands it in his daily workflow. That broke an assumption I’d been carrying without examining: capability tracks conviction, smart technical people see the value faster.

His skepticism doesn’t come from ignorance; it comes from understanding the tool. We screen-shared while he drove the tool against his own real code. The skepticism that survived that session is principled, and it points at a layer of adoption I didn’t have a name for.

The convenience floor isn’t the conviction floor

Most onboarding playbooks I’ve seen, including the one I had in my head, assume non-adoption is a friction problem. The install is annoying, the plan costs money, the docs are rough, the first prompt is intimidating. Remove friction, get usage. That model works for plenty of people. It worked for several others in this same enablement portfolio.

It does nothing for a skilled skeptic.

When you pay for someone’s plan and they still don’t use it, the gap isn’t access. When you walk them through a working session and they engage and still don’t use it, the gap isn’t comprehension. There’s a third floor above those two. The conviction floor is where the user has to actually believe the tool’s output is worth integrating into their workflow, on its merits, on their terms. You can’t demo your way through it. The demo already happened.

Principled objections

When I listened instead of pitching, the resistance sorted into distinct categories. None were “this is too hard.” All were substantive technical positions a thoughtful person can hold.

Regurgitation: the claim that LLMs aren’t reasoning, just pattern-matching across training data and reshuffling existing code. Closely related is a philosophical position, that whatever the model is doing isn’t cognition at all. And then there’s security: what does the tool read, what does it send, what does it execute, on whose authority.

The first two are real, but I’ve decided not to argue them directly. Adoption doesn’t require resolving the question of machine thought. The cognition debate is a tar pit. And re-running a demo doesn’t address regurgitation, because the objection isn’t about whether output appears. The output a strong coder has already seen is consistent with sophisticated pattern-matching, and pattern-matching has a known failure mode: it is most confident exactly where the training data is thin, so it fails silently on the novel cases that matter most. More output of the same shape doesn’t engage that concern.

Security is the only one with concrete remediation paths. So security is where I’m starting.

Why security is the place to start

You can sandbox. You can permission tool access. You can configure for no egress on sensitive code, review every suggestion before it lands, and talk specifically about what the tool is allowed to do.

Two things happen when you engage security first. One, you might actually win it, because the legitimate concerns are well-defined and addressable, and a strong coder will respect a real answer. Two, you’ve signaled that you take their objections seriously instead of pattern-matching them to “Luddite” and pushing harder on convenience. That signal alone changes the conversation from posture-debate to integration-design. Winning one, with respect, is a different posture than losing all three with insistence.

What I’d do differently

Capability and conviction are independent axes. Skill doesn’t predispose someone to AI adoption. If anything, depth makes the skepticism harder to dismiss, because it can be defended. The phrase “smart people will see the value” was doing a lot of unexamined work in my model, and it’s gone now.

I’d stop assuming a paid plan plus a working install equals adoption. The boxes were the wrong checklist. And I’d identify why before throwing more convenience at someone, capacity, fit, and conviction are different blockers requiring different moves. My instinct was to schedule another demo, find a flashier use case, re-pitch. Wrong move. I was applying a convenience-fit answer to a conviction problem.

The only move that works: listen for the objection in front of you, and answer that one instead of the one you came prepared to beat.

dxdev LESSON · paste into your AI coding agent
LESSON: The Conviction Floor: Skilled Skeptics Need Different Moves
SOURCE: dxdev.com/blog/skilled-skeptic
WHAT HAPPENED: A technically strong team member was onboarded to an AI coding tool with a paid plan, a working install, and a live paired session. They engaged, understood the output, and still did not adopt. The assumed path (remove friction, get usage) failed because the blocker was not access or comprehension but conviction. The onboarder kept applying convenience-fit answers to a conviction-floor problem.
THE RULE: Identify the actual blocker (capacity, fit, or conviction) before choosing a response; a second demo is the wrong move for a principled objection.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any onboarding flow or prompt that treats non-adoption as a friction problem without first checking whether the user has already seen the tool work.
  2. Any logic that schedules a follow-up demo or re-pitches a feature when a user has already completed an initial session but has not increased usage.
  3. Any code or copy that assumes technical seniority correlates with faster or higher AI adoption.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.