Does AI Kill Craft? Taste, Judgment, and Quality in the Age of Generated Code

---

A senior engineer I respect said something that stuck with me: "I'm worried AI is going to produce a generation of developers who can ship anything and understand nothing." It's a real fear, and I've seen its early shape — engineers accepting AI output they can't explain, code that works until it doesn't, a creeping sense that nobody's really holding the quality anymore. If craft is care and understanding, and AI lets you ship without either, doesn't AI kill craft?

I've come to the opposite conclusion, and I'll argue it here. AI doesn't kill craft. It does something more interesting: it makes the typing free and the taste precious. When anyone can generate a plausible implementation in seconds, the thing that separates a craftsman from a code-forwarder isn't the ability to produce — it's the judgment to know what's worth producing, the taste to tell good from plausible, and the standard to refuse output that won't last. Those were always the heart of craft. AI just stripped away the manual labor that used to hide them.

The danger is real, but it's not the one people name. The danger isn't that AI replaces craft. It's that we let it remove the struggle that builds craft — and end up with engineers who never developed the judgment because the machine always did the hard part. That's avoidable, and avoiding it is a choice. Here's the case.

Power tools didn't kill woodworking

Every craft has been through this. The lathe, the table saw, the CNC machine — each arrived with the same prophecy that "real" woodworking was finished, that machines would flatten craft into mass-produced sameness.

What actually happened: power tools raised the floor and moved the craft up a level. They eliminated the brute labor (cutting boards to rough size by hand for an hour) and freed the craftsman to spend their judgment where it mattered — the joinery, the proportions, the finish, the design. A master woodworker today uses power tools constantly. The craft didn't die; it relocated to the decisions the tools can't make.

AI is the power tool for software. It eliminates the brute labor — boilerplate, the tenth CRUD endpoint, the function you've written a hundred times — and frees you to spend judgment on what matters: the architecture, the edge cases, the question of whether this is the right thing to build at all. The craft doesn't die. It moves to where the tool can't go. This is the same realization behind how senior engineers leverage AI: the leverage is in directing and judging, not typing.

What AI can't do is exactly what craft is

Strip software craft down to its core and you find a set of capabilities AI conspicuously lacks:

• Taste — the sense of whether a solution is good, not just functional. AI produces the statistically plausible; it has no taste, only patterns. Knowing that a clever one-liner will haunt the next maintainer, or that this abstraction is elegant and that one is over-engineered, is taste — and it's yours.
• Judgment about what's worth building. AI will happily build the wrong thing beautifully. Deciding what not to build, what trade-off to accept, what the actual problem is — that's craft, and AI has no opinion.
• Recognizing subtle wrongness. AI states wrong things in the exact confident tone it states right things. The craftsman's suspicion — "this looks right, which is exactly why I don't trust it yet" — is the skill that catches what the model can't flag.
• Conceptual integrity. AI generates locally-plausible code that's globally incoherent — five functions that each work and together form a mess. Holding the whole in your head so the parts cohere is craft.

Notice that these were always what separated great engineers from adequate ones. AI didn't change what craft is — it removed the production work that used to camouflage the fact that taste and judgment were the real differentiators all along.

The real danger: AI can kill the path to craft

Here's where the fear is legitimate, and it's worth taking seriously. Craft is learned — through struggle, through making mistakes on real systems and feeling the consequences, through the slow accumulation of judgment that comes from doing the hard part yourself. If AI always does the hard part, where does the next generation's judgment come from?

This is a genuine risk. An engineer who only ever accepts AI output never builds the taste to evaluate it. They become a forwarder of plausible code, not a craftsman — and they can't tell the difference, which is the worst part. The struggle AI removes is, partly, the struggle that builds the craftsman.

But the answer isn't to reject the tool — it's to deliberately preserve the learning. The distinction is everything:

• AI as a crutch: accept output you can't explain, never wrestle with the problem, skip the struggle, build no judgment. Craft atrophies.
• AI as a tutor and tool: use it to go faster on what you understand, interrogate what you don't, demand explanations, verify everything, and spend the time you saved on harder problems. Craft accelerates — you can learn faster than my generation did, because you have a tireless explainer on tap.

The tool is neutral. Whether it kills your craft or compounds it depends entirely on whether you keep doing the hard thinking or outsource it. (This is the personal version of the team-level apprenticeship problem — judgment has to be deliberately built now, not absorbed by accident.)

How to use AI to deepen craft, not erase it

Concretely, the practices that keep AI on the craft-compounding side:

• Never ship code you can't explain. If you can't defend why it's correct, you haven't done the craft — you've forwarded a guess. This one rule prevents most of the atrophy.
• Use AI to interrogate, not just generate. "Why is this the right approach? What are the failure modes? What would break this?" Turn it into a sparring partner for judgment, not a vending machine for code.
• Spend the saved time going deeper, not just shipping more. The point of removing boilerplate is to invest that time in the hard problems — architecture, edge cases, the design question — not to ship twice as much mediocre work.
• Keep your hands in the hard parts. Deliberately do some of the difficult thinking yourself, especially while learning. The struggle is the gym; don't skip every workout because there's a forklift.
• Hold the same standard you always did. AI output gets reviewed against the same bar as human output — maintainability, clarity, does-this-age-well. Generated isn't an excuse for a lower standard.

What to do Monday morning

1. Audit your own AI use: crutch or tool? For the last thing you shipped with AI, can you explain why every part is correct? If not, you've found where craft is leaking out.

2. Add the one rule: never ship what you can't explain. Apply it to yourself and your team. It's the single highest-leverage guard against AI-driven atrophy.

3. Turn AI into a sparring partner. Next time you use it, don't just take the code — ask it to argue the trade-offs, find the failure modes, and justify the approach. Practice judgment, not just acceptance.

4. Reinvest saved time in depth. Decide deliberately that the hours AI gives back go to harder problems and better quality, not just more volume.

Key takeaways

• AI makes typing free and taste precious. When anyone can generate plausible code, the differentiator is the craft AI lacks — taste, judgment, suspicion, conceptual integrity. Those were always the heart of craft; AI just removed the labor hiding them.

• Power tools didn't kill woodworking; they moved the craft up a level. AI is the power tool for software — it eliminates brute labor and relocates craft to the decisions the tool can't make.

• What AI can't do is exactly what craft is. It produces the plausible, not the good; it builds the wrong thing beautifully; it states wrong things confidently; it generates locally-plausible, globally-incoherent code. The gap is craftsmanship, now the scarce part.

• The real danger is to the path to craft, not craft itself. If AI always does the hard part, judgment never forms. The fix isn't rejecting the tool — it's deliberately preserving the struggle that builds the craftsman.

• Crutch vs tutor is a choice. Used as a crutch, AI atrophies craft; used as a tutor and power tool — explain everything, interrogate, reinvest saved time in depth — it accelerates craft faster than ever.

Your next step

Look at the last thing you built with AI and try to explain, out loud, why each non-trivial part is correct. If you can, you're using AI as a craftsman uses a power tool. If you can't, you've just found the exact place where the machine is doing your thinking — and the fix is to go back and do that thinking, this time. Craft was never about typing the code. It was always about the judgment behind it. AI didn't take that from you. It just made it the only thing that matters.

Frequently asked questions

Does AI kill software craftsmanship?

No — it tends to make craftsmanship more valuable, not less. When generating code becomes nearly free, the scarce and differentiating skills are exactly the ones AI lacks: taste (knowing good from merely functional), judgment about what's worth building, suspicion that catches subtly wrong output, and the conceptual integrity to keep a system coherent. These were always the core of craft; AI simply removed the manual production work that used to obscure the fact that judgment and taste were the real differentiators. The genuine risk is to the path that builds craft, not to craft itself.

Will AI make engineers worse at their craft?

It can, but only if used as a crutch rather than a tool. An engineer who only accepts AI output they can't explain never builds the judgment to evaluate it and becomes a forwarder of plausible code. Used as a tutor and power tool — interrogating its reasoning, verifying everything, refusing to ship code they can't defend, and reinvesting saved time in harder problems — AI can actually accelerate skill-building, because it provides a tireless explainer on demand. The outcome depends on whether the engineer keeps doing the hard thinking or outsources it.

What can AI not do that human engineers can?

AI lacks taste (the sense of whether a solution is genuinely good, not just functional), judgment about what's worth building (it will build the wrong thing beautifully), reliable detection of subtle wrongness (it states incorrect things in the same confident tone as correct ones), and conceptual integrity (it produces locally-plausible code that can be globally incoherent). These capabilities are precisely what distinguish strong engineers and what software craftsmanship has always been about — which is why they become the scarce, valuable skills as code generation gets cheap.

How do I use AI without losing my engineering skills?

Adopt a few disciplines: never ship code you can't explain (if you can't defend why it's correct, you've forwarded a guess rather than done the work); use AI to interrogate problems, not just generate code (ask it for trade-offs, failure modes, and justifications); reinvest the time AI saves into deeper work rather than just more output; deliberately keep doing some hard parts yourself, especially while learning; and hold AI output to the same quality bar as human-written code. These keep AI on the skill-compounding side rather than the skill-atrophying side.

Is using AI to write code "cheating" or bad for quality?

Not inherently — it's a tool, and like any power tool the result depends on how it's used. Using AI to eliminate boilerplate and routine work so you can focus judgment on architecture, edge cases, and design is exactly how skilled practitioners use tools, and it can improve quality. Quality suffers only when AI output is accepted uncritically, shipped without understanding, or held to a lower standard because it was "just generated." The standard for AI-written code should be the same as for human-written code: is it correct, maintainable, and built to last?