Stephen Brennan argues that AI coding tools like Claude Code automate the very process that makes software development valuable and enjoyable for many engineers, transforming them from creators into managers and potentially sacrificing deep learning in pursuit of pure output.
LLM-based coding agents like Claude Code and OpenAI's Codex are having a moment. They're genuinely useful now, capable of helping both seasoned developers and non-technical users build features or entire projects with surprising competence. But Stephen Brennan, a software engineer and blogger, offers a contrarian perspective that cuts through the current euphoria: he finds these tools strip away the joy of programming itself.
The Automation Paradox
Brennan's core argument rests on a simple principle: we automate tasks we don't value. We use dishwashers because we care about clean dishes, not the act of scrubbing. We use mechanical looms because fabric is the goal, not the meditative process of hand-knitting. Yet many of us still knit by hand precisely because we do value the process.
This creates a fundamental divide in how developers approach AI coding tools. For product-focused builders who see software purely as a means to an end, Claude Code is transformative. It turns development into a management exercise: define requirements, iterate on output, and let the AI handle implementation details. The value is purely the final product.
But Brennan represents a different archetype—the engineer who codes for the sake of understanding. "I enjoy the process of representing a problem in code, and I enjoy learning & building a mental model of systems so that I can better understand and debug them," he writes. For this mindset, using AI to generate code feels like skipping the workout but still wanting the fitness benefits.
The Honest Goal Assessment
This tension has forced Brennan to become more explicit about his actual goals. When he picks up a crochet hook, he admits the goal isn't really the blanket—it's the act of creation. Similarly, when he starts a software project, he's often more interested in learning a new language or understanding a problem domain than shipping a finished product.
This honesty helps him decide when AI assistance makes sense. For tasks where he genuinely doesn't care about the process—boilerplate, repetitive code, administrative overhead—AI tools are perfect. They free up time for the parts of development he actually values: deep technical exploration, debugging complex systems, and building expertise.
The key is recognizing that not all code is created equal. Hundreds of lines of boilerplate don't teach you much. But writing a debugger from scratch, or tracing through a kernel bug, builds knowledge that compounds.
The Career Question
Of course, values don't pay the bills. Brennan acknowledges the elephant in the room: will AI replace software engineers? His answer is nuanced and depends on what kind of value your work actually creates.
His own job—debugging Linux kernel issues for customers—illustrates the distinction. Yes, he writes code, but that's not the real value. The worth comes from reading massive codebases, building mental models of complex systems, creating diagnostic tools, and finding creative ways to debug under customer constraints. The code is just a byproduct of deep technical understanding.
This suggests a durable career path for engineers who focus on the "why" and "what" rather than just the "how." There will always be systems where reliability and debuggability matter enough that human expertise is non-negotiable. Brennan's bank, his car's software, his computer's OS—he wouldn't want those "vibe-coded" by AI.
The real risk isn't AI replacement, but rather a divergence between two types of developers: those who use AI to accelerate product delivery, and those who use it to augment deep technical work. Both paths can be viable, but they require different value systems.
Finding the Right Fit
Brennan's conclusion is cautiously optimistic but grounded in self-awareness. He's found a job that aligns with his values—technical expertise and system understanding—and believes that as long as that alignment holds, his role remains secure. The key is knowing what you actually care about.
This might mean using Claude Code to scaffold a web app's frontend while hand-writing the critical backend logic that needs to be debuggable. Or letting AI generate unit tests while you focus on architectural decisions. The tool becomes a way to offload the parts of development you don't value, preserving time for the parts you do.
For developers who feel the same loss of joy when using AI coding tools, Brennan's framework offers a way forward: be brutally honest about whether you're building to learn or building to ship. Then choose your tools accordingly. The industry's rush toward AI automation doesn't have to be a universal good—it just has to fit your actual goals.
The future probably isn't one where everyone loves Claude Code. It's one where different developers use it for different reasons, and some of us still choose to knit by hand.
Stephen Brennan writes about software, systems, and the craft of programming at stephencbrennan.com.
Comments
Please log in or register to join the discussion