Where Do the Next Seniors Come From?

This is the third post in Craft & Code, a short Friday series about what carpentry can teach us about AI, skill and the future of software. Last week I argued that judgement is bounded — earned slowly, by doing the work. This week, the obvious follow-on: if AI takes over the work through which judgement is formed, where is the next generation’s judgement supposed to come from?

The last chapter of my father’s working life was teaching. After his hand gave out, he qualified as a lecturer and spent his second career in further education, training building and carpentry apprentices. He was good at it, and he cared about it in a way that went well beyond the job description. He believed, plainly and without much fuss, that the trade had a duty to form the people who would come after — that a craft which does not train its young is a craft quietly eating itself.

He also had a front-row seat to the opposite happening.

Over the years he taught, he watched the support for apprenticeships gradually thin. Funding tightened. Numbers fell. The places that had once been a normal route into a skilled trade became scarcer, and the message young people absorbed was that this was not where the future was. He was vocal about it, in the measured way he was vocal about most things. He could see what it would cost, not next year, but in twenty.

I do not think he was ever properly thanked for that. Over a long teaching career he must have put thousands of apprentices into the construction industry — people who went on to build things, run sites, train others in turn. That is an enormous contribution, and it is the kind that never shows up on a balance sheet, because the person who trains the workforce is rarely the person who profits from it. His value was real and almost entirely uncounted.

He was right about the cost, and we are paying it now.

Here in the UK, construction is in the middle of exactly the shortage he could see coming, and from where I sit in Wales it is not an abstraction — it is the trade my father gave his working life to, struggling to find the people to carry it on. The Construction Industry Training Board’s 2025-2029 outlook says the industry needs to recruit the equivalent of hundreds of thousands of extra workers over the next five years, once retirement, churn and growth are taken into account. Its apprenticeship analysis says around three times the current number of apprenticeship starts would be needed to keep pace with annual recruitment requirements. And when you ask firms why they are not training more, the answer is rarely hostility to the idea. It is cost and time. They cannot, individually, justify it.

That last point is the one worth sitting with, because it is where the real mechanism hides. No single firm declining to take on an apprentice is behaving unreasonably. Training is expensive, slow, and the person you train is free to leave the moment they are useful. From any one company’s position, the rational move is to let someone else bear the cost and then hire the finished article. The trouble is that when everybody reasons that way, there is no someone else. The pipeline is a thing everyone draws from and almost nobody is paid to refill. It empties slowly, invisibly, and then all at once.

That is the shape of the thing my father was warning about, and it is the shape I want to hold up against software, because I think we are about to build the same trap with better tools.

The reassuring story about AI and junior developers is that the tools simply make everyone more productive, juniors included. There is something to that. But underneath it runs a colder logic that any honest manager will recognise. A great deal of junior work — the boilerplate, the straightforward CRUD, the first-draft tests, the small well-defined tickets — is exactly the work AI now does quickly and cheaply. So the question presents itself, quietly, in planning meetings everywhere: if the tool can do the work we used to give the juniors, why are we hiring the juniors?

In the short term, that looks like efficiency. You ship the same amount with a leaner, more senior team. The numbers improve. Everyone is pleased.

But that junior work was never only output. It was the apprenticeship. It was how a beginner spent three or four years bumping into real systems, breaking things, fixing them, sitting in code review, watching production fall over at the worst possible moment and learning, in their hands, why the careful thing matters. The boilerplate was the boring surface of something important: the slow accumulation of judgement through consequence. Automate the surface and you do not just remove drudgery. You remove the path. You take away the very work through which someone becomes the senior engineer you are relying on AI to stand in for.

And here is the cruelty of the timing. AI makes juniors look least efficient at precisely the moment the industry most needs to keep forming them. The case for not hiring them has never been easier to make on a spreadsheet, and the cost of believing that spreadsheet will not arrive for a decade.

There is a tempting way out of this worry, and I want to meet it head on. It runs: why does it matter if we stop forming human seniors, when AI will simply be the senior judgement layer too? Let the models do the boilerplate now and the architecture later. Problem dissolved.

I do not believe that, and the reason is not faith. It is daily experience. Even with the best models available today, I find myself constantly applying my own judgement to steer a build — overruling a confident suggestion, noticing the thing that is technically correct and practically wrong, knowing that the tidy answer will not survive contact with the rest of the system. The tools are genuinely good, and they are getting better. But there is a ceiling to the kind of judgement they bring, and I keep bumping into it precisely on the questions that matter most: not “does this compile?” but “is this the right thing to build, and what will it cost us in two years?”

I would go a little further, though more tentatively, because it is a bigger thought than this post can carry. The models do have something you could call judgement, but I am not sure it is the same judgement a human brings, formed as ours is by consequence, responsibility, and having to live with what we make. A model optimises for plausible, helpful output inside the shape of the request; it does not carry responsibility for what happens when the system is used. That is a whole essay in itself, and not this one. But it is the reason I do not think “the machine will be the senior” is the safe assumption it is dressed up as. If anything, it makes the human judgement we are about to stop forming more important, not less.

I do not get to be smug about any of this, because I live inside the same pressure my father watched bear down on construction.

I have spent most of my career caring about this — putting energy into bringing new people on, giving them real work and real responsibility and the room to get things wrong somewhere it can be recovered. I always thought of it as simply my own conviction, a view I had arrived at.

It is only now, writing this, setting his story down next to mine, that I see plainly where it came from. I did not reason my way to it. I inherited it from him, absorbed across a childhood in that workshop and a lifetime of watching how he thought about the trade, and made it so completely my own that I mistook it for something I had invented. The ethic passed down exactly the way the series keeps insisting these things do: not taught from a manual, but caught from someone who lived it.

Which makes the rest of this harder to write, not easier. Because believing in it has not been enough. Hard-nosed business makes carrying it harder every year. The budget is for delivery, not formation. The pressure is to ship. And when a capable tool can produce in an afternoon what a junior would take a fortnight to produce while learning, the argument for the fortnight gets very hard to win, however much I believe in it. I find myself making my father’s case in the meeting, the case I now realise he handed me, and I do not always win it. Often I cannot.

So I recognise the trajectory, because I am standing on it.

For a while it will be fine. Those of us who were formed the slow way — who debugged the production incident, lived with the bad abstraction, unwound the migration that should never have been attempted — will keep things running on judgement we already have. We are the senior layer, and we are good at our jobs. But we are also, with every leaner team and every junior role quietly not filled, digging the foundation out from beneath our own feet. The judgement holding the industry up was made by a process we are in the act of switching off. We will be fine for a few years. The people who were meant to replace us may not exist.

None of this is an argument against the tools, any more than my father was arguing against the electric saw. The juniors should absolutely use AI; learning to direct it well is part of the modern craft. The argument is narrower and more uncomfortable than that.

It is that the path from beginner to expert used to be paid for almost by accident, bundled invisibly into the ordinary work of getting things done. AI is about to unbundle it. The beginner work and the beginner’s formation came as a package, and we are about to keep the work and drop the formation without quite noticing we have done it.

Construction noticed too late. The gap is here now, and it will take a generation to close, if it closes at all. Software has the advantage of watching it happen next door, in slow motion, with all the numbers published. The question my father spent his second career asking is the one we now have to ask ourselves, deliberately, because the old automatic answer is being taken away: if the tools do the work that used to make beginners into experts, how are we going to make experts instead?

I do not have a clean answer. But I am fairly sure that pretending the question is not there is how construction got where it is.

Next week: the ceiling. Why a wonky shelf looks wonky, and bad software often looks finished.