Simon Griffiths

This is the first post in a short Friday series I’m calling Craft & Code: what carpentry can teach us about AI, skill and the future of software.

When I was six, my father’s workshop felt like a magical place.

It was just three doors down the street, above a garage. I remember standing knee deep in recently planed wood shavings, surrounded by the smell of fresh timber and the signs of work in progress. It was not a showroom workshop, arranged for photographs. It was practical, busy, and full of things kept because they might be useful one day.

My father was a carpenter by trade: first a shop fitter, then an independent kitchen fitter, and later a carpentry and construction lecturer. He was not precious about tools. He was a master of using whatever he had to hand to get the job done.

Partly that was about cost, but it was also about time. Why lose half a morning buying something if you could solve the problem with what was already in the van, on the bench, or leaning against the wall?

His solutions were not always pretty, but they were solid. He once built shelves for me in an alcove, and I think they may still be there for eternity. That was typical of him. When he built something, it did not come down. Sometimes, even when you wanted it to come down, it still did not come down easily.

I keep thinking about that now, when people talk about AI and software development.

Not because software is carpentry with keyboards. It isn’t. The analogy breaks in important ways, and I will come back to those in this series. But both trades show what happens when tools change the economics of a craft.

The current conversation about AI coding tools often gets dragged into one question: will AI replace developers? It is an understandable question, but it is also too narrow. A better question is what happens to a craft when the tools become more powerful.

Carpentry has already been through versions of that story. Hand tools, apprenticeship and repetition formed one kind of working life. Electric tools then made skilled people faster. They changed what could be done in a day, what could be priced competitively, and what kinds of work became practical for small teams or independent tradespeople. But the important point is that electric tools did not remove the need for skill. They amplified it. A skilled carpenter with better tools could do more, but they still had to know what mattered: what to measure, where to cut, what could be made good, what had to be redone, and what would fail later if it was bodged now.

Here, though, is where the carpentry comparison stops being reassuring. An electric saw does not pretend to understand the job. It does not produce a plausible-looking cabinet while quietly misunderstanding the wall, the load, the material, or the customer. AI coding tools are different, because they can generate work that appears competent before anyone has applied competent judgement to it. A screen can render, a form can submit, and a demo can impress while the underlying assumptions are wrong.

That is both their usefulness and their danger. In the hands of someone who knows what they are doing, they remove drudgery, speed up exploration, and turn a good developer loose to move faster. In the hands of someone who does not, they simply produce mistakes at a higher rate and with more confidence. None of which is an argument against the tools. My father would have had no patience for that kind of purism: if a tool helped him get the job done properly, he used it. But he also knew, instinctively, that owning the tool and knowing the craft were not the same thing.

That distinction matters more now, not less. These tools mean more people can build things that would previously never have justified a development team: internal tools, automations, prototypes, dashboards, experiments. That is real democratisation, and much of it will be useful. But it does not mean the craft has disappeared; it means the boundary has moved. Some work that once required a specialist becomes routine, while other work depends even more heavily on judgement. Knowing what to ask for, what to accept, what to reject, what to test, what to secure, and what not to build becomes more important when the tool can produce so much so quickly.

The last turn in my father’s career is the clearest illustration of the point. He moved into teaching after pain in his hand and an X-ray showing arthritis made the physical future of the work harder to ignore. When his body could no longer do the work, the judgement did not disappear with it. It changed form. In the classroom his authority came not from theory, but from the fact that everyone knew he had done the work. That is the part of any craft a powerful tool cannot hand you: the knowing that sits underneath the doing.

So that is where this series is heading. If AI makes the production of code easier, then we need to think harder about the parts of software development that were never just production: judgement, apprenticeship, value, responsibility, and the ability to see when something that looks finished is not yet sound.

The question is not whether we should use these tools; of course we should. The question is whether we still understand the work once the tool makes the work look easy.