I hear this a lot lately: "Claude removes craftsmanship".

This idea makes me uncomfortable. Not because I think it is completely wrong, but because I deeply care about crafting things and I always have. For me, engineering has always been very close to craftsmanship.

I do understand where the feeling comes from though. Especially if you imagine craftsmanship as working without proper tools. As someone using a hand saw instead of a CNC machine. With this kind of tool, the woodworker does not need to choose which bit to use or determine the cutting depth. He can focus on design and on the experience being created. The underlying tools are abstracted away (even though a solid understanding of them remains important to know what is happening under the hood).

But that definition of craft has always felt odd to me because a woodworker's goal is not to protect the purity of the saw. It is to build good furniture, furniture that lasts, furniture that feels right. The tools matter, of course. You need to understand them, maintain them, and respect their limits. But they are not the purpose. Focusing more on the tool than on the result is just another way to miss the point.

For a long time, engineers were not really allowed to think like this. I think we are now, and that is the real shift.

The Shift: Embracing The Product

What surprises me the most is that focusing on the product feels more like craftsmanship than ever.

There is a strange relief in finally being able to spend time on the right things. To step back and ask what we are actually building, and for whom. Instead of spending most of our energy translating Linear issues into code and calling that value.

If I am honest, being paid mainly to convert PM-written tickets into code can feel deeply robotic. Sometimes even pointless. The value was never really there. And realizing that is actually freeing.

It does mean leaving a bubble because understanding customer needs is harder. It is messy and often uncomfortable. It requires trade-offs and conversations that don't fit neatly into tickets. Not everyone enjoys that, and that is fine. But pretending that writing code, even very good code, is the core value feels increasingly disconnected from reality.

This is probably why we see the term "Product Engineer" everywhere now. The label is imperfect, but the feeling is real. You are still an engineer. You are still accountable for technical decisions. But your usefulness is no longer measured by how much code you produce.

The value is now in being able to spot design issues, code smells, weak assumptions, in having a critical opinion, in reviewing things (with the introduction of Linear Reviews, code review is explicitly positioned as a first-class activity rather than a side effect of writing code, which is likely a sign of where the industry is heading), in saying "this works, but it is wrong for us", and being able to explain why.

Communication suddenly matters more than ever. Explaining context, constraints, and intent clearly. Keeping documents alive and up to date. Whether that is in markdown files, specs, or even in how you frame problems when working with Claude.

But We Still Have To Understand

None of this means disengaging from technical depth. If anything, it requires more of it.

You still need to understand what is being generated. You are accountable for it. If something breaks, "Claude did it" is not an answer. It is your name on the PR, your system in production. At least for now.

A co-author is not accountable.

What makes this harder is that the tool gives you the feeling that you can handle everything. That understanding becomes optional. That curiosity is no longer necessary.

This is exactly what we already see in schools. When the tool can always produce an answer, the desire to learn slowly fades. Not because people are lazy, but because the feedback loop is broken. You no longer feel the cost of not understanding.

That is why I intentionally keep parts of my work AI-light. I sometimes design things without inline suggestions. I still explore concepts and ideas. I test hypotheses on my own. I dig probably even deeper than before. Not because AI is bad, but because I want to keep that muscle alive. I want to know that I still can think through a problem from first principles.

In practice, this also means carefully reviewing everything. You are managing agents rather than typing every line yourself, but that does not change responsibility. If the system becomes a black box you are afraid to touch, something is already wrong.

I often ask myself a simple question: if Claude disappeared tomorrow, would we still be able to reason about this system? Even slowly. Even painfully. Or did we give up too much understanding along the way?

And We Can Go Further

One interesting side effect of all this is that many old excuses no longer really hold.

Tests are a good example. Writing them used to be tedious and easy to postpone. Now it is mostly cheap. AI can handle a large part of it end-to-end, as long as you give it the right context and constraints from the start. The effort shifts from typing to thinking clearly.

The same is also true for documentation, commenting, commit messages, etc.

The comment above is no longer true. The "why" does not only exist in your head if you intentionally write it down. If you provide the right context early on, the AI should also be able to write it:

In this example, we can clearly understand the intent behind this commit. It’s not only a list of changes. The key is not who types the words, but whether the intent is captured while it is still fresh and explicit. Context that lives only in your head is already lost.

This is where quality becomes visible again. Not abstract ideas of clean code, but product quality. Coherence. Intentionality. Care. That is what still separates a team of engineers from products assembled as opaque black boxes.

I do not think craftsmanship is disappearing. I think it is moving. We can probably craft more than ever before. The craft is just different now. It is less about the tool itself and more about intent, judgment, and responsibility. The result matters more than the saw.