Three Objections From a Strong Coder Who Won't Use Claude Code

Plan paid. Tool installed. Paired session done. The strongest pure coder we’ve onboarded to Claude Code is still the lowest-usage adopter, and we haven’t found the move that lands it in his daily workflow.

That broke an assumption we’d been carrying without examining: capability tracks conviction, so smart technical people see the value faster.

We screen-shared while he drove the tool against his own real code. His skepticism comes from understanding the tool, and the part that survived that session is principled. It points at a layer of adoption we didn’t have a name for.

Most onboarding playbooks we’ve seen, including the one we had in mind, treat non-adoption as 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 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, access isn’t the gap. When you walk them through a working session and they engage and still don’t use it, comprehension isn’t the gap either. There’s a third floor above those two. The conviction floor is where the user has to believe the tool’s output is worth integrating into their workflow, on its merits and on their terms. You can’t demo your way through it. The demo already happened.

What the objections turned out to be

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

The first is 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. The third is security: what does the tool read, what does it send, what does it execute, on whose authority.

The first two are real, but we’ve decided to leave them unargued. Adoption doesn’t require resolving the question of machine thought, and the cognition debate is a tar pit. Re-running a demo doesn’t address regurgitation either, because the objection was never 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 we’re starting.

Starting with security

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 win it. The legitimate concerns are well-defined and addressable, and a strong coder will respect a real answer. Two, you’ve shown that you take their objections seriously instead of filing them under “Luddite” and pushing harder on convenience. That 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 we got wrong

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 our model, and it’s gone now.

We treated a paid plan plus a working install as adoption. Those boxes were the wrong checklist. Our instinct was to schedule another demo, find a flashier use case, and re-pitch. Wrong move. We were applying a convenience answer to a conviction problem, when capacity, fit and conviction are different blockers that need different moves.

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

Before adding more convenience

A paid plan, a working install and a completed demo don’t show that someone has adopted an AI tool. Find out whether the blocker is capacity, fit or conviction. If it is conviction, listen for the objection the person actually holds and answer that one.

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.