Do we have to learn everything again? AI and the fatigue of constant change

When tiredness comes before enthusiasm

I did not greet the arrival of AI with enthusiasm straight away either. At first, I found it genuinely difficult to deal with. People I knew kept sending and showing me applications they had put together with it in just a few days. Meanwhile, I was wondering what I was supposed to do with my eighteen years of programming experience if this was how things were going to work from now on.

This was not an afternoon of uncertainty. For weeks, perhaps even months, I kept wondering which direction to take and what I should retrain for if things really did fall apart. It left me feeling pretty low: it seemed as though my entire professional world was beginning to collapse. I think it matters to say this, because once we start seeing the opportunities in something, it is easy to forget what the beginning felt like.

Then, gradually, the attitude I wrote about in the first article began to return: I believe nothing is impossible; perhaps I just cannot see the solution yet. If this tool is here, I need to learn to live with it and work out what I can make of it. To do that, I first had to take a closer look at what had actually come out of those ideas put together in a few days.

That is why I do not like dismissing uncertainty by saying that good professionals will adapt. Of course we need to adapt. But it can still be tiring, and we do not have to pretend that every change is a joy from the very first moment. Sometimes we need time just to feel like engaging with it at all.

Things are no easier for people starting out. Someone has just finished a course and is already hearing that a tool can do some of what they have only just learned. Experienced developers worry about the years they have invested; beginners are trying to work out what to build on. It is worth keeping that in mind before offering either group easy advice.

What has actually been finished?

When I took a closer look at the applications people had sent me, I gave them a few questions worth asking the AI. What technologies make up the system? Why were those chosen? For one application, the answer was a React frontend and custom PHP code on the server side.

There is nothing inherently wrong with that combination. I wanted to understand why it had been built that way and what would happen if a developer needed to take it over later. How easily would they understand what had been done and why? How long would it take to make changes, and what would further development cost? If it was going to use PHP, why had it not been built on an established framework? There can be good answers to these questions, but I wanted to see whether there was a considered decision behind it.

The answers then pointed to the need to move quickly, the user's lack of development knowledge, and this being the easiest way to build it. That still did not explain to me why the same approach would work well later on. Meanwhile, the Gemini my friend was using rewarded me with a virtual beer for the occasional “good senior-level question”. A few more questions, and by the end I was virtually quite tipsy.

More important than the beers, though, was what I came to understand. AI can write a system, and with the right guidance it can write a good one. But someone still has to notice which question has been missed, what would be better built differently, and what will be needed after the first demonstration. This was where I began to feel again that my previous experience very much had a place in all of this.

A website created with AI can be surprisingly good. It would not be fair to talk about these tools as though they were only capable of impressive but unusable experiments. For a simpler task, a solution that previously required a developer's involvement may genuinely be enough. As professionals, we need to accept that change too.

What matters, though, is which task we consider finished. A website introducing a business raises different questions from a system that handles orders, customer data and payments. Both may look as though they work on screen, but everyday use places very different demands on them and brings very different responsibilities.

When I look at a booking process, I do not just want to see whether someone can select a time slot. I also want to know what happens with two simultaneous bookings, an interrupted payment or a later cancellation. AI can help implement those parts too, but someone needs to recognise the questions and check the answers. Previous experience remains very useful here.

The most valuable part of my knowledge is not what I know by heart

As developers, it is easy to associate professional knowledge with how many languages, frameworks or solutions we know. We need those, but something else develops over the years: we become quicker to notice when an important condition is missing, a task has grown too large, or the chosen solution will be difficult to live with later.

I do not mean that experience automatically outweighs a new approach in every situation. A beginner can find a better solution, and an old habit can be wrong. Experience is worth something when it helps us judge the situation in front of us, rather than simply hold on to what we are used to.

That is why, when working with AI, I do not see my own role as just writing code. I need to understand the task, choose the right tools and take responsibility for making the result useful. If some of the implementation becomes faster, those decisions do not disappear. Instead, we have more opportunities to give them attention early enough.

We do not have to learn every new thing at once

I think it helps a lot if we stop trying to relearn our entire profession over a weekend. It is worth choosing one clearly defined task that we already understand and trying the new tool on that. This gives us something to compare against: we can spot when it misses an important step, as well as when it genuinely makes the work easier.

That might mean explaining an existing module, preparing a few test cases or comparing two possible solutions. The initial aim is not to hand everything over, but to learn to recognise when we are getting useful help. The time spent checking the result has to count towards that assessment too. A fast answer alone does not mean time saved.

For a beginner, the difficulty lies elsewhere. If I cannot yet judge an answer, I can easily confuse a convincing explanation with a correct solution. That makes the fundamentals, small tasks we can check, and trying to explain for ourselves what has been built especially important. Using AI can be part of learning, but understanding is not a step worth skipping.

We cannot know exactly what this profession will look like

I cannot honestly promise that every role and every task we have done so far will remain unchanged. The tools I recalled in the first article already changed what clients needed help with. AI is now raising the same question on a much broader scale.

Even so, I do not feel that the time I have spent learning has been wasted. It helps me understand the limits of a new tool, ask questions and see when a solution that looks finished at first still needs more work. We do not necessarily have to begin with enthusiasm. Sometimes it is enough to look, with curiosity, at where it might fit into our work.