The Death of the Craftsman Engineer (And Why That’s Fine)

Last week, I shipped a feature that would have taken me three days to code. It took about an hour. Not because I found some shortcut or used a better framework. I didn't write a single line of code.

I described what I wanted, broke it into parallel tasks, and watched four AI sessions build it simultaneously while I reviewed, redirected, and refined. By the end, the feature was live. It worked. And honestly, it felt good. I knew what the outcome should be, I described it clearly, and the outcome matched. There's something satisfying about that loop when it clicks.

But there's also something underneath the satisfaction that's harder to name. Not discomfort exactly, more like a quiet shift in how you relate to the thing you built. You conceived it, you directed it, you verified it. But you didn't make it. Not in the way you used to. And that changes something about how it feels to call it yours.

I used to work as a machine learning engineer. Now I'm a technical founder. I've spent thousands of hours writing code, debugging code, thinking about code. And now, increasingly, I don't write code anymore. I write requirements. I orchestrate. I judge outputs. I think about what needs to exist, not how to make it exist.

This article isn't about whether AI will replace engineers. That debate is boring, and the answer is obviously no. What I want to talk about is something more uncomfortable: what happens to us when the thing we built our identity around stops being the hard part? What do we lose? What do we gain? And what does the engineer of tomorrow actually look like when writing code is no longer the job?

The Scribe Fallacy

Everyone is asking the wrong question. "Will AI replace engineers?" is the 2025 version of "Will the printing press replace scribes?" The answer was yes, obviously. But that's not the interesting part. The interesting part is what happened next.

Before Gutenberg, if you wanted a copy of a book, you hired a scribe. This was a skilled profession. Years of training, meticulous attention to detail, deep knowledge of languages and texts. A scribe's value was real and earned. But the job was never really "moving a quill across parchment." The job was making knowledge accessible. The quill was just the only tool available at the time.

When the printing press arrived, scribes didn't all disappear overnight. But the ones who survived were the ones who understood that their real skill wasn't handwriting. It was knowing what was worth copying in the first place. Editors, translators, publishers. The function evolved. The purpose stayed.

You can find the same pattern everywhere. Switchboard operators weren't in the business of plugging cables into boards. They were connecting people. Accountants with ledgers weren't in the business of arithmetic. They were making financial decisions legible. In each case, the manual layer got automated, and the people who thrived were the ones who had already internalized that the manual part was never the point.

Now here's where it gets uncomfortable for engineers specifically. We have, more than almost any other profession, built our identity around the craft itself. Not just "I solve problems with software" but "I write elegant code." There's a real satisfaction in clean architecture, in a perfectly optimized function, in debugging something obscure until it finally clicks at 2 AM. For most engineers, this isn't about showing off. It's about the quiet pride of understanding a system deeply enough to shape it exactly the way you want. It's what drew most of us to the field in the first place. The feeling of building something with your own hands, even if those hands are just typing.

And that's exactly why this shift is so personal. Most engineers will keep their jobs. But the part of the job that gave us the most fulfillment is the part that's getting automated first. What remains is knowing what to build, why to build it, and whether what got built is actually correct. That's a fundamentally different skill. It's arguably a harder one. But it doesn't feel the same. And for a lot of people, it won't feel like enough.

I think this is what's really driving the anxiety in the industry right now. Not the fear of unemployment. The fear of irrelevance. The fear that the thing you spent years mastering might not be the thing that matters anymore. And if you're honest with yourself, that fear isn't entirely irrational. It's just pointed at the wrong target. The craft isn't dying. It's migrating. From how you write the code to how you think about the problem.

The Ownership Problem

Here's something I don't see enough people talking about honestly. When you write every line of code yourself, you understand the system in a way that feels almost physical. You know why that function is structured the way it is because you tried three other approaches first. You know where the edge cases hide because you discovered them the hard way. The codebase isn't just something you work on. It's something you know, the way you know your own apartment in the dark.

When AI writes the code, that intimacy disappears. You can read the output, review it, test it. But you didn't live through the decisions that shaped it. And there's a real loss in that. I won't pretend otherwise. The first few times I let Claude Code build an entire module while I just described what I wanted, I caught myself thinking: "Is this still mine?"

I think the answer is yes. But it took me a while to get there.

The analogy that helped me was thinking about architects. An architect doesn't lay bricks. Doesn't pour concrete. Doesn't wire the electrical. But nobody walks into a building and says "this isn't really the architect's work." The architect conceived it. Defined the constraints. Made the decisions about what goes where and why. The value was always in the vision and the judgment, not in the physical construction.

The same is true for film directors, for music producers, for product designers. The people we consider the creative owners of a work are almost never the ones who executed every detail of it. They're the ones who held the intent clearly enough that the execution could follow.

That's the transition engineers are going through right now. Ownership is migrating from "I wrote this" to "I specified this, verified this, and take responsibility for this." It's a different kind of ownership. Less tactile, more cerebral. And if I'm being honest, it took some getting used to. There's a version of engineering pride that only comes from having personally fought a bug for six hours. That specific pride is fading. What's replacing it is the pride of having thought clearly enough that the bug never existed in the first place.

I'm not going to pretend that transition is painless. But I also won't pretend I miss debugging for six hours just to find a typo that could have been fixed in thirty seconds. The new version is more valuable. You just have to let go of the old one first.

When Ideas Become Worthless

There's a second consequence of this shift that I think is even less discussed than the ownership problem. And it's more brutal.

If building software becomes trivially cheap, then the ability to build something stops being a competitive advantage. Which means ideas, on their own, become worthless.

This might sound counterintuitive. For years, the bottleneck was execution. "Ideas are cheap, execution is everything" was practically a mantra in the startup world. If you had an idea for an app, the question was always: can you actually build it? Do you have the technical skills, the team, the time, the money? Most ideas died right there, at the execution barrier. And that barrier is what gave engineers their leverage. We were the ones who could cross it.

Now that barrier is collapsing. A side project that used to take a month takes a weekend. A prototype that required a full stack developer can be assembled by someone who's never opened a terminal. When everyone can build, the ability to build stops being the filter. And if execution is no longer the scarce resource, then ideas certainly aren't either. Because everyone already had ideas. They just couldn't build them before.

So what's actually scarce now?

Judgment. Taste. Distribution.

Knowing which of the hundred things you could build is the one worth building. Knowing whether what you built is actually good, not just functional. And knowing how to get it in front of people who will use it. These were always valuable skills, but they used to live in a different department. Product managers thought about what to build. Designers thought about whether it was good. Marketing thought about distribution. Engineers just built the thing.

That separation is dissolving. The engineer of tomorrow needs to operate across all of those layers, because the pure building layer is no longer where the value concentrates. Writing code was the moat. Now the moat is everything around the code: the problem selection, the quality judgment, the go-to-market instinct.

I realize this sounds threatening if you've spent your career optimizing for technical depth. But I actually think it's liberating. The ceiling for what one person can accomplish just got dramatically higher. You're no longer bottlenecked by how fast you can type. You're bottlenecked by how clearly you can think. And thinking, unlike typing, scales with experience rather than declining with age.

What I Actually Do Now

Let me describe what a typical workday looks like for me now, because I think it illustrates this shift better than any abstract argument.

I don't open VS Code anymore. I haven't in weeks. Instead, I open a tool called Clave, a desktop app I built specifically for this new way of working. It's a session manager for Claude Code that lets me run multiple AI coding sessions in parallel from a single window. It has a built-in kanban board where I create tasks, and from there I can launch each task directly into its own Claude Code session.

So my morning starts with thinking. What needs to get built today? What are the dependencies? What can run in parallel without conflicts? I break the work into discrete tasks on the kanban board, write clear requirements for each one, and launch three or four sessions simultaneously. Then I watch, review, redirect. One session is building a new API endpoint. Another is refactoring a component. A third is writing tests for something I shipped yesterday. My job is to make sure each session has enough context to succeed, and to catch the moments where the AI makes an assumption I wouldn't have made.

The skill that matters most in this workflow isn't coding. It's decomposition. Can you break a complex problem into chunks that are independent enough to run in parallel, but coherent enough that they integrate cleanly when they're done? That's systems thinking, not programming. And it's genuinely hard. Harder than writing the code yourself in many cases, because you have to hold the entire architecture in your head while delegating the details.

Here's the part I find most satisfying about this. Clave itself was built this way. I used Claude Code to build a tool for managing Claude Code. The recursion isn't lost on me. A tool born from the exact workflow shift it's designed to enable. It started as a personal frustration: I was juggling terminal tabs, losing track of which session was doing what, copy-pasting context between windows. So I described what I needed, and built it the same way I build everything now. Requirements first, AI execution, human judgment throughout.

I open-sourced it because I think this workflow isn't unique to me. Any engineer going through this transition will eventually hit the same friction: you need a way to manage the orchestration layer that your job has become. Clave is my answer to that, but more importantly, it's a concrete example of what engineering looks like on the other side of this shift. Less typing, more thinking. Less doing, more directing.

GitHub - codika-io/clave Contribute to codika-io/clave development by creating an account on GitHub.

And if you want a concrete measure of how dramatic this shift is: I built a desktop application that replaced a tool I'd been using daily for years, VS Code, in a matter of hours. Not a toy prototype. A real, functional app with multi-session management, a kanban board, theming, keyboard shortcuts. Something that would have taken weeks of focused development not long ago. The fact that a single person can build a polished developer tool over a couple of evenings, and then actually use it as their primary workflow, says more about where engineering is heading than any think piece could.

The Engineer of Tomorrow

So if writing code is no longer the job, what is?

I think it's worth remembering what engineering actually means. The dictionary definition of an engineer is "a person who designs, builds, or maintains machines, structures, or systems." Designs. Builds. Maintains. Notice that code isn't in there. Engineering was never about writing code. It's about critical thinking, scientific method, and solving problems efficiently. Code was just the implementation layer. The tool we used to express our solutions. That part of the job hasn't changed at all. What's changed is that once the problem is understood and the solution is clear, there might no longer be a need to implement it yourself.

But here's where I become less certain about the future, and I think intellectual honesty matters more than confident predictions.

Right now, AI is ruthless about exposing ambiguity in your thinking. If you give vague instructions, you get vague results. You have to define exactly what you want, steer the direction precisely, and catch every wrong assumption along the way. The thinking still has to be sharp. The human still has to do the hard cognitive work of problem definition and solution design.

But I've already noticed something shifting over the past few months. The starting point is getting better. The default direction when you give AI a loosely defined task is closer to correct than it used to be. Models are getting better at inferring intent, filling in gaps, and selecting reasonable approaches even when you haven't spelled everything out.

So the question I keep asking myself is: where does this trend end? At some point, will we even need to define the solution precisely? Will the model be able to look at a problem, evaluate the possible approaches, and select the most efficient one in context without us having to architect it? I don't know. And I'm skeptical of anyone who claims they do.

What I do feel reasonably confident about is the direction. There will be more need for generalist profiles. Engineers will need to do more product thinking, more customer conversations, more understanding of the business context around the problems they're solving. The value moves further upstream: not "how do we build this" but "what should we build and for whom." Whether that means the engineer of tomorrow looks more like a product manager, a technical strategist, or something entirely new that we don't have a name for yet, I genuinely don't know.

But I'd rather be honest about that uncertainty than pretend I have a clean answer. The shift is real. The destination is blurry. And I think that's okay.

The Craft Evolves

I started this piece by describing a moment that would have been unthinkable two years ago. Shipping a feature in an hour that would have taken days. Not by cutting corners, but by working in a fundamentally different way.

The anxiety around this shift is real, and I don't think dismissing it helps anyone. If you've spent years becoming great at writing code, watching that skill get commoditized is unsettling. It's personal. It touches something deeper than career prospects. It touches how you see yourself.

But I keep coming back to the scribes. The ones who thrived after Gutenberg weren't the ones who grieved the longest for their quills. They were the ones who recognized, faster than others, that their real value was never in the handwriting. It was in knowing what was worth putting on the page.

Engineering is going through that same recognition right now. The craft isn't dying. It's shedding a layer that we mistook for the core. Underneath, the actual job remains: understand problems deeply, think about them clearly, and make sure the right thing gets built. That was always the job. We just used to do it with our hands on the keyboard. Now we do it with our hands on the wheel.

I won't pretend to know exactly what this looks like in five years. I shared my uncertainty about that earlier, and I meant it. But I do know that the engineers I admire most have always been the ones who think the hardest, not the ones who type the fastest. If anything, this shift just makes that distinction official.

The future of engineering belongs to clear thinkers. And the printing press never made good writing obsolete. It just made it matter more.

If you enjoyed this article, you can follow me on LinkedIn and X for more writing on AI, automation, and building Codika.

You Might Also Like

Beyond the Knowledge Closure Why LLMs can recombine everything we know but discover nothing we don't

The Purpose Recession AI's real threat isn't unemployment, it's existential emptiness

Before ChatGPT Could Talk The 70-year problem of teaching machines language