Craftsmen and Pragmatists
Artificial intelligence has exposed a rift in the developer community. Some developers are energized by AI coding tools—they see them as accelerants, better levers for building what they want to build. Others feel something being lost, an erosion they can't quite name but recognize immediately.
The divide runs deeper than capability or adoption speed—though those factors matter. It's about identity and what we find meaningful in our work.
For some developers, writing code is intrinsically rewarding. The craft, the elegance, the satisfaction of a well-architected solution—these things matter independent of the outcome. Their identity is tied to being a coder. AI tools feel like they're eroding something meaningful, not just changing a workflow.
For the second group, code was always instrumental. They wanted to build things, solve problems, and ship products. Code happened to be the most powerful lever available. AI just gives them a better lever.
Call them craftsmen and pragmatists—two poles of a spectrum rather than two tribes. The names are reductive—useful for clarity, dangerous if taken literally—but capture real orientations. Most developers fall somewhere between these poles, and many shift depending on context.
These aren't hypothetical positions. Real developers express these views in online discussions:
One developer on HackerNews put it plainly: "I will personally never use Copilot, or any other AI code generation tool, for the simple reason that I enjoy writing code."1 Another wrote: "Reliance on Copilot subtly undermined my problem-solving abilities...immediate access to AI-generated solutions...dulling my problem-solving acumen over time."2 The concern isn't abstract—it's visceral. AI feels like it's eroding code as craft.
On the other side, Armin Ronacher (creator of Flask) describes how AI tools give him "30% more time in my day because the machine is doing the work," making all his programming skills "more relevant than ever, just with a new kind of tool."3 Kent Beck captured the shift succinctly after 52 years of programming: "90% of my skills just went to zero dollars and 10% of my skills just went up 1000x."4 For these developers, code was always instrumental—AI just gives them a better lever.
The divide is real, not imagined.
Ends of the Spectrum#
The craftsman writes code the way a carpenter planes wood—there's pleasure in the process itself. The pragmatist writes code the way an architect uses CAD software—necessary, powerful, but not the point. The building is the point. Neither position is wrong, but they predict different futures.
The craftsman view says abstraction loses something important. Understanding, precision, maybe even a kind of discipline. There's wisdom in knowing how things work at a low level. There's danger in letting tools do work you don't fully comprehend.
The pragmatist view says the goal was never the code itself. Code is frozen thought, a way to instruct machines. If AI handles more of that translation layer, we move up the stack—closer to the actual problem, further from the implementation details. Clinging to code-as-craft is like insisting on hand-calculating spreadsheets or typesetting by hand.
The tension is real. But it's not new.
This Divide Predates AI#
Similar philosophical tensions surfaced with each major abstraction layer in computing history. Assembly programmers looked at C and saw dangerous distance from the metal. When Java introduced garbage collection in the mid-1990s, C++ programmers raised concerns mirroring today's AI debates. Brian Kernighan explained why C's directness mattered: "You will have a very good mental model of what's going to happen on the machine; you can predict reasonably well how quickly it's going to run, you understand what's going on."5 Bjarne Stroustrup dismissed garbage collection as "a last choice and an imperfect way of handling resource management," preferring explicit control.6 The fear was identical: abstraction erodes understanding. Backend engineers looked at no-code tools with skepticism bordering on contempt.
Each transition triggered the same debate: are we losing something essential, or freeing ourselves to work on harder problems? In each case, the abstraction layer succeeded commercially, and developers either adapted or specialized in maintaining legacy systems. The holdouts weren't wrong about what was lost—they were wrong about whether the loss mattered more than the gain.
But AI may differ categorically. Previous abstractions—garbage collection, high-level languages—were deterministic and predictable. You could reason about what they would do. AI is probabilistic and opaque. The abstraction isn't just higher—it's fundamentally different in kind. Whether the historical pattern holds depends on whether that difference matters. The timeline has compressed, making the rift visible before we know the answer.
The Economic Dimension We Can't Ignore#
Economics complicates this picture. If AI can write code, what happens to the market value of developers? Job security concerns are legitimate, and they likely compound—or even drive—the identity concerns described above.
Is "craftsman" resistance to AI genuinely about craft, primarily about economics, or some mix of both? Stated reasons and actual motivations aren't always the same. And that's not cynical—economic anxiety and identity erosion can be genuine simultaneously. The anxiety is measurable: Stack Overflow's 2024 survey found that 30% of developers see AI as a threat to their jobs—rising to 42% among early-career developers.7 Meanwhile, companies laid off 666,000 tech workers between 2022 and 2024, driven by multiple factors including economic conditions and restructuring.8 The correlation with increased AI-related job postings amplifies the perception that AI threatens traditional roles, even if causation is complex. Evans Data found that 71% of developers believe they'll eventually be replaced by AI.9 While AI-specialized roles are booming (earning a 25% salary premium), traditional software roles have declined 20%+.10 The paradox: AI tool adoption grew from 70% (2023) to 84% (2025) while trust in AI output dropped from 40% to 29% and favorability fell from 72% to 60%.11
The both/and position I describe below requires security. A senior developer with in-demand skills can afford to be flexible about tool usage in ways that a junior developer competing for entry-level positions cannot. Recognizing this privilege matters for an honest conversation about AI tools.
The point isn't to reduce everything to economics. It's to acknowledge that identity and livelihood are intertwined, especially when your professional identity is tied to a skill that might be automatable.
The Both/And Developer#
Here's what makes this interesting: the same developer can hold both positions depending on context.
I'm a both/and developer. I love hand-crafting a tricky algorithm on a personal project. I also happily let AI scaffold boilerplate at work. Neither choice defines me. What matters is developing the judgment to know which mode serves the moment.
I treat AI as a junior collaborator. I still architect, review critically, and care about elegance. But I'm not precious about who—or what—types the first draft. The value isn't in holding a consistent position—it's in knowing when to savor the process and when to optimize for the outcome.
This isn't compromise—it's recognizing that the value of coding varies by context. Sometimes the act of writing code teaches me what I'm actually trying to build. Other times I know exactly what I want, and code is just the translation layer between intent and execution. The tool I reach for should match the kind of thinking I need to do.
Time and Experience Shift the Balance#
Early-career developers building fluency may need the reps that AI shortcuts bypass—though research on whether AI use impairs skill development is still emerging. The mental model matters. The muscle memory matters. Architecture students still learn to draw by hand even though they'll use CAD software in practice—the act of drawing teaches spatial thinking that informs everything they design later. The same may be true for writing code: the practice builds mental models that matter even when working at higher abstraction levels. Whether AI fundamentally changes this calculus for programming remains an open question.
Senior developers with deep intuition might delegate more confidently—they know what good looks like. They've debugged enough gnarly issues to spot the warning signs before things break. They can treat AI like a senior engineer treats a junior teammate—trusting them with well-scoped tasks while maintaining oversight.
The right relationship with AI tools might depend on where you are in your own development—not just chronologically, but contextually. What are you trying to learn? What are you trying to build? Those answers shape the tool.
The Deeper Question#
The rift isn't really about AI—it's about an older question AI has made urgent: What are developers actually here to do?
If the value is in typing code, AI is a threat. If the value is in problem decomposition, system design, and knowing what to build in the first place, AI might be an amplifier.
The dichotomy may be too clean. For many developers, value lies in the iterative dialogue between implementation and understanding—where writing code reveals what they're actually trying to build. If that's true, AI's impact depends on whether it preserves or severs that feedback loop.
The craftsman might say developer value lives in the nuanced judgment that comes from deep fluency with code. The pragmatist might say it lives in understanding the problem domain deeply enough to know what's worth building.
Both are probably right, which means the answer isn't choosing sides but developing the judgment to know which mode serves the moment. The most effective developers might be those who can answer "What am I here to do?" contextually rather than ideologically.
The divide will persist because it's rooted in something deeper than technology: what we find meaningful. But recognizing it as a divide about meaning rather than just a debate about tools might make the conversation more honest. And honesty is a better foundation than ideology for deciding when and how to use AI.
AI didn't create this rift, but it's now impossible to ignore.
References#
1 HackerNews user comment. "Why Copilot Is Making Programmers Worse at Programming." August 30, 2024. https://news.ycombinator.com/item?id=41513767.
2 Sankritayayana. "Why I Stopped Using Copilot: A Developer's Reflection." LinkedIn, October 16, 2024. https://www.linkedin.com/pulse/why-i-stopped-using-copilot-developers-reflection-sankritayayana-bwkmc.
3 Ronacher, Armin. "AI Changes Everything." June 4, 2025. https://lucumr.pocoo.org/2025/6/4/changes/.
4 Orosz, Gergely. "TDD, AI agents and coding with Kent Beck." The Pragmatic Engineer, 2024. https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent.
5 Kernighan, Brian. "An Interview with Brian Kernighan." Carnegie Mellon University. Accessed December 13, 2025. https://www.cs.cmu.edu/~mihaib/kernighan-interview/.
6 Stroustrup, Bjarne. "Bjarne Stroustrup's FAQ." Accessed December 13, 2025. https://www.stroustrup.com/bs_faq.html.
7 Stack Overflow. "2024 Stack Overflow Developer Survey." 2024. https://survey.stackoverflow.co/2024/ai.
8 TrueUp. "Tech Layoffs Tracker." Accessed December 13, 2025. https://www.trueup.io/layoffs.
9 Brainhub. "Is There a Future for Software Engineers?" Accessed December 13, 2025. https://brainhub.eu/library/software-developer-age-of-ai.
10 Index.dev. "8 AI Developer Salary Trends to Watch in 2025-26." Accessed December 13, 2025. https://www.index.dev/blog/ai-developer-salary-trends.
11 Stack Overflow. "Stack Overflow's 2025 Developer Survey." 2025. https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/.