The developers who've spent the longest mastering their craft are often the last to adopt AI coding tools. That's not stubbornness - it's psychology.
Geir Isene, a programmer and writer, proposes a framework that cleanly explains the divide: are you coding for the process or the result? Process-oriented programmers find satisfaction in the craft itself. The elegant algorithm. The clever optimization. The feeling of solving a hard problem with your own brain. For them, AI coding assistants don't help - they steal the fun part.
Result-oriented programmers care about shipped features and solved problems. For them, tools like GitHub Copilot, Cursor, or Claude Code are straightforward productivity multipliers. The code is a means to an end, and faster means are welcome.
Skill Space vs. Idea Space
Isene frames this as a transition from "skill space" to "idea space." AI increasingly handles the skill-intensive work - syntax, boilerplate, debugging, translating intent into working code. What it can't replace is the creative layer: deciding what to build, why, and for whom.
The uncomfortable implication: developers who've spent a decade or two building their identity around technical skill are being asked to shift their value proposition to ideas and architectural thinking. That's a real psychological cost, not a trivial adjustment.
Isene speaks from personal experience. After adopting Claude Code, he says he produced more GitHub commits, music albums, and creative output than at any other point. His skills became less important; his ideas became more productive.
The Practical Split
His rule of thumb is simple: "Use AI for tasks where you love the process? Then the AI takes away the fun. Use AI for tasks where you're focused on the result? Then the AI amplifies the fun."
This maps neatly onto how AI coding tools actually get adopted in practice. The same developer might resist using Copilot for the algorithmic core of their project (where the craft matters to them) while happily letting it generate test scaffolding and boilerplate (where they just want the result).
The framework also explains why adoption isn't simply a seniority issue. A senior developer who's always been result-oriented will adopt quickly. A junior developer who fell in love with coding as a craft may resist despite having less skill to "protect."
For teams trying to drive AI tool adoption, the lesson is to stop framing it as efficiency and start framing it as creative leverage. Nobody wants to hear their hard-won skills are being automated. But most developers will listen when you say: "Spend less time on the parts you don't enjoy so you can spend more time on the parts you do."