AI didn't kill software craft. it moved it.

A familiar argument is going around: AI has killed software craftsmanship. The reasoning is straightforward. For years, being good at this job meant being good at producing code — naming things well, structuring a module, choosing the data structure, getting the edge cases right by hand. That was the work, and the people who did it with care were the craftspeople. Now a model writes most of it in seconds, and the hand-built thing and the generated thing look about the same in the diff. If the typing was the craft, and the typing is gone, then so is the craft. People who feel this loss are not being precious. They are noticing something real.

It's worth taking seriously before answering, because the weak version of the response — "actually it's all better now" — is not true and nobody believes it. So let me steelman the worry, then explain why it points at the right grief and the wrong conclusion.

The strongest version of "AI killed craft"

Here is the case at its best. Craft is built in the friction. You learned to design good interfaces by writing bad ones and living with them. You developed taste by sitting in the details long enough for them to teach you something. A model that produces a plausible answer instantly removes exactly the slow contact with the material where judgment used to form. Worse, it produces work that looks finished — fluent, idiomatic, confident — which makes it harder to notice when it is subtly wrong. The fear isn't only "I won't type as much." It's "the next generation won't build the judgment, because the thing that built it is being automated away."

That is a real concern, and any honest answer has to hold it. The mistake is narrower than it looks. The argument defines craft as the act of producing code. That was always a proxy. Production was where craft showed up, but it was never what craft was.

What craft actually was, before the model

Strip a senior engineer's day down and very little of the value was in keystrokes. The value was in deciding what to build and what to refuse to build. In knowing what "good" looks like for this system and holding the work to it. In designing the boundaries between parts so the whole stays comprehensible. In catching the case that breaks in production six weeks from now. In reading a change and knowing, before the tests run, whether it will hold.

None of that is typing. All of it is taste, judgment, and selection. The typing was the medium through which those things got expressed, the same way a writer's craft was never the act of moving the pen. We confused the medium with the skill because, for forty years, you couldn't have one without the other. AI separated them. And once they are separate, you can see that the part the model took — producing the text — was already the least of it.

So where did the craft go

It moved. It went upstream, into the questions the model cannot answer for you: what is worth building, what does correct look like here, where are the boundaries, what are we deliberately not doing. And it went downstream, into the part that got larger once a machine started producing the code: review. When you write every line by hand, review is a check on work you already understand. When a model writes it, review is the primary place judgment is applied — the moment taste decides whether this is right, whether it fits the system, whether you would put your name on it.

The grind of producing code is gone. The craft of deciding what is worth producing, and rigorously judging what came back, is now the entire job. It didn't shrink. It moved to the ends of the pipeline, where it was always doing the real work.

This reframes who is thriving and who feels bereft. The developers who anchored their identity to producing code feel the floor drop, because the thing they were good at got cheap. The ones thriving quietly relocated: they spend their attention on problem selection and on review, and treat the model as a fast, tireless, occasionally wrong contributor whose output they own. The skill didn't die. It changed address. We wrote about a related shift — how the work moves rather than disappears, and where the cognitive load lands — in the cognitive load of running parallel Claude Code agents.

The line between owning code and disposing of it

There's a version of AI development that genuinely has no craft in it, and it's worth naming so the rest of the argument stays honest. Generating a disposable app you don't understand, shipping it, and moving on is not the same activity as owning production code you stand behind. The first is fine for a throwaway. It becomes a problem the moment anyone has to maintain it, extend it, or trust it with real data — because nobody understands it, including the person who prompted it into existence.

The dividing line is simple and old: you own every line. Not "you typed every line" — you understand it, you can defend the decisions in it, you would sign off on it in review with your name attached. That standard didn't change when the author changed from your hands to a model. If anything it got stricter, because the model will hand you fluent, confident, wrong code more readily than you ever would have written it. Owning the output is the craft. It's also the comparison we draw out in defract vs Claude Code Agent Teams: parallel agents can produce a lot of code fast, and the open question is always whether anyone owns what came back.

The honest counter: the hard part moves too

Someone from this audience pushed back on a cleaner version of this idea, and the pushback is right enough that it deserves space. Their point: fine, craft moved to taste and judgment — but the friction didn't vanish, it relocated as well. Once you can build almost anything quickly, the bottleneck stops being construction and becomes deciding what is worth building and then getting anyone to use or buy it. Taste in code is now table stakes; taste in problem selection and distribution is the new scarce thing.

That's correct, and it doesn't undercut the thesis — it extends it. The craft moved upstream far enough that it ran off the end of engineering and into product and judgment about markets. That is uncomfortable for people who chose this field to avoid those questions. But it is the same motion: the mechanical part got automated, and what's left is the part that was always hard and was always where the value sat. The work didn't get easier. The leverage moved to the decisions.

Putting craft back where it lives

If craft now lives in selection and review, the tooling problem is to make those the load-bearing stages rather than afterthoughts you do when there's time. This is the problem defract was built around, so treat it as one approach rather than the answer. defract runs Claude Code through a structured lifecycle — story, design, architecture, implementation, review, release — and makes review a gated stage rather than a glance at a diff: agents check types, lint, tests, architecture, security, and UX and surface what they found, while you sign off on intent. The point isn't to automate the judgment away. It's the opposite — push the mechanical production into the machine and put your attention back where craft moved: on what to build, and on whether what came back is correct and will hold.

You don't need any particular tool for this. You need to stop measuring yourself by code produced and start measuring by problems chosen and judgment applied. The craft was never the typing. It just took the typing leaving for us to see what it actually was.