Two developers sit side by side, using the same languages, the same editors, shipping the same kind of software. One of them is devastated by AI coding assistants. The other can't adopt them fast enough. What changed?
Nothing, argues developer Les Orchard in a recent essay. The divide was always there. AI just made it visible.
Before tools like Claude Code and Cursor could generate entire functions on demand, every programmer followed the same workflow: think, type, debug, ship. The process was identical regardless of motivation. But motivations were never the same. Some developers fell in love with the act of writing code. Others fell in love with what code could do.
Two Kinds of Grief
Orchard draws on writers like Nolan Lawson, who describes missing "the feeling of holding code in our hands and molding it like clay" and the pride of creating something "true and right and good." For craft-oriented developers, AI tools don't just change the workflow. They remove the part of the job that made it meaningful.
Then there's Orchard's own camp. He learned BASIC and assembly language not because the syntax was beautiful, but because he wanted to make things happen on screen. His career progressed from placing individual bytes in memory to writing functions to designing whole systems. "The puzzle got more abstract each time," he writes, "but it never stopped being a puzzle."
His grief is different. It's not about losing the joy of hand-writing code. It's about the broader ecosystem shifts that AI is accelerating: web consolidation, changing career landscapes, and the uncomfortable reality that models were trained on decades of open-source work without much consent.
The Hidden Split in Every Team
This framing resonated with me because it explains arguments I've watched play out in every AI tool discussion for the past two years. When a craft-focused developer says "AI code is sloppy and misses the point," they're not wrong. When a results-focused developer says "I shipped in two hours what used to take two days," they're not wrong either. They're measuring different things.
The problem is that most advice about AI coding tools ignores this divide entirely. "Just adapt" is useless counsel for someone whose core professional satisfaction is being automated. "Just resist" is equally useless for someone who was never in it for the typing.
Orchard's most useful observation: recognizing which kind of grief you're experiencing is more productive than fighting about whether AI coding tools are good or bad. That's a false binary built on the assumption that all developers want the same thing from their work.
What This Means for Tool Adoption
For teams adopting AI coding assistants, this split has practical consequences. Craft-oriented developers aren't being difficult when they push back on AI-generated code. They're responding to a genuine loss. Results-oriented developers aren't being lazy when they embrace AI pair programming. They're doing what they've always done: finding the fastest path to a working product.
The healthiest teams will probably be the ones that stop treating this as a skills gap to close and start treating it as a values difference to navigate. Some developers will use AI tools as a first draft generator. Others will use them as a reference. Some will avoid them entirely for the parts of coding they find most rewarding.
None of those approaches are wrong. But pretending they don't exist, or that one will inevitably win, is how you lose good people from both camps.