The End of the Craftsman? — Simon Schrottner

The End of the Craftsman? | Simon Schrottner

I noticed something a few months ago.

I was talking less to my colleagues.

Not because anything was wrong.<br>I had a question, I described it to an AI, I got something useful back.<br>Why loop in a human if the loop is already closed?

It took a while to name what was actually happening.

There’s a version of the AI story where the interesting work disappears.

The agent implements.<br>The spec session produces the plan.<br>Humans review the output.<br>What’s left?<br>Ticket hygiene and rubber stamping.<br>Engineering as a series of approvals.

I think that’s wrong.<br>But I understand why it feels true.

Here’s what I think is actually happening instead.

The agent produces the increment.<br>But the agent doesn’t decide what the increment should move toward.<br>It doesn’t know whether this library is the right bet for the next three years.<br>It doesn’t know which of two implementation approaches leaves options open and which quietly closes them.<br>It doesn’t know whether the architectural call made today creates a problem nobody will notice until the system is under load eighteen months from now.

That work — giving the project direction, validating trade-offs, deciding what the system becomes — isn’t specable.<br>You can’t write a ticket for it.<br>And it’s not going away.

The craft didn’t disappear.<br>It moved.

Direction is the word I keep coming back to.

The agent executes well.<br>It implements against a spec.<br>It generates options when you ask for them.<br>But it doesn’t carry a point of view about where the system should go.<br>It doesn’t have a stake in the decision.<br>It will implement the wrong architectural direction just as confidently as the right one, if that’s what the spec says.

Someone has to hold the direction.<br>Someone has to know enough about the codebase’s history, the team’s constraints, and the product’s trajectory to say: not that library, we’ve been down that road.<br>Not that pattern, it doesn’t survive the load we’re heading toward.<br>This approach now, that refactor later, in this order, for these reasons.

That’s not a spec.<br>That’s judgment.<br>And it’s the part of engineering that the agent loop exposes rather than replaces.

A piece I read recently makes a related point.<br>Most engineers use AI, few engineer with it — the difference being whether you’re consuming outputs or shaping the problem before any output exists.

That framing is right but I think it undersells what’s actually hard.

Shaping the problem before the prompt is a skill.<br>But knowing what the system should become — which trade-offs are worth making, which implementation approach holds up over time, what the PoC needs to prove before you commit — that’s a different kind of knowledge.<br>It’s accumulated.<br>It comes from watching a system grow and break and get fixed over time.

You can’t prompt your way into it.

We tend to confuse craftsmanship with implementation because implementation was where craftsmanship was expressed.<br>The code review, the refactor, the careful choice of abstraction.<br>But the craft was never the typing.<br>It was the judgment behind it.

The agent can type.<br>The judgment is still ours.

Which brings me back to what I noticed about myself.

I was validating with the AI because it was right there.<br>Faster.<br>Always available.<br>Never in a meeting.

But there are two different conversations hiding under “does this approach make sense.”

One of them is: does this produce working code.<br>The AI is fine for that.

The other is: does this make sense given where we’re going, what we’ve tried before, and what we’re going to have to live with.<br>That conversation needs someone who knows the system, knows the team’s history with this pattern, and has a stake in what gets built.

AI is quietly substituting for the second conversation while only actually covering the first.

And nobody notices for a while, because the outputs look the same.

This is also where the junior engineer question gets uncomfortable.

The traditional growth path ran through implementation.<br>You wrote code, made mistakes, got it reviewed, iterated.<br>That feedback loop built intuition over years.<br>It was slow and mostly accidental, but it worked.

If the agent writes the code, that path gets thin.<br>Juniors who go through it in isolation — prompting, reviewing output, prompting again — are getting answers without developing the ability to form the questions.<br>They’re skipping the part where you learn to see the options before picking one.<br>Where you learn to hold a direction, not just execute against it.

That’s a quiet problem.<br>And it deserves more than a paragraph here — so I’ll come back to it properly in a later post.

The Spec Session helps with some of this.<br>It’s a forcing function for the room.<br>Intent, edge cases, product thinking — those surface where the whole team can catch them.

But direction isn’t a session.<br>It’s more continuous than that.<br>Which library do we standardise on?<br>What does the test harness...