A good friend and former business partner, Lars Nielsen, said to me recently: “AI will never be worse than it is right now.”

That line stayed with me.

Not as a defence of AI, but because it moves the question. The argument about whether the tool is good enough has an expiry date. The question of what you do yourself once it is does not.

What actually changed

I have been coding professionally since 1998. For most of that time the work was writing the code – sitting with the problem, finding the way through and writing the lines myself. It is still a large part of my work. But not in the same way as before.

I still write code, but a larger part of the day goes to stating the task precisely, assessing what comes back, and rejecting what does not hold. It looks less and less like one developer in front of an editor, and more like a developer who is also running a very fast, very literal and rather unreliable small team.

It reminds me of sitting at Lifeguard briefing my developers – writing the tasks into Trello, explaining what needed building, and reviewing what came back. The working day now feels closer to that role than to the one I had ten years earlier.

Why it takes more experience, not less

The common assumption is that the tool makes experience worth less. My experience is the opposite. A model can write something that looks convincingly right even when it is not – and the difference is not necessarily visible on a first read.

Seeing that difference requires knowing what to look for. You need to recognise the query that works on ten rows and falls over at a hundred thousand. The error handling that looks complete but never covers the path that matters. The library that solves the problem and drags in thirty times more than needed.

That does not come from knowing how to prompt. It comes from having seen systems work, fail and be maintained long enough to recognise the problems before they get expensive.

That judgement has not become less important. It takes up more of the work than ever.

What I hold on to

I do not let anything ship that I have not read. Not on principle, but because I answer for it. When a client calls in eighteen months because something has broken, it is not a tool that has to explain why it was built that way.

And there are still tasks where I open the editor and write it myself, because that is faster than describing it. That is not nostalgia. It is the right call more often than the debate suggests.

Will there be developers in the future?

I have asked myself that often. I think there will be.

But I think a great deal more is going to get built. Things that used to be too expensive to build can now be done in a fraction of the time. And when the price falls, people do not necessarily stop buying. They also start buying what they previously had to go without.

There will still be demand for solutions that are not generic, and for design somebody has actually thought about. That does not become worth less because the trivial gets cheaper.

What worries me more is the way in. The routine work – the tasks you learned the craft on – is being taken over. That was where you built the experience that later lets you see when a suggestion does not hold up.

I do not know where that experience is meant to come from now. I have no good answer to that.

Nor do I know how much of the code I work with in five years I will have written myself from the first character.

But that is no longer the interesting question either.

I still have to understand the problem. I still have to see when the solution is wrong. And when the client calls eighteen months later, the responsibility is still mine.

I am still the developer. I just spend more of the day reviewing a colleague who writes extremely fast, never gets tired, and is occasionally completely wrong.

Lars Nielsen, who set the thought going, writes regularly about AI on LinkedIn.