Learn to think above the code: learn how to model problems and reason about them using maths. There are plenty of tools in this space to help out: model checkers like TLA+ or Alloy, automated theorem provers such as Lean or Agda, and plain old notebooks and pencils.
Our jobs are not and have never been: code generators.
Take a read of Naur's essay, Programming as Theory Building [0]. The gist is that it's the theory you build in your head about the problem, the potential solution, and what you know about the real world that is valuable. Source code depreciates over time when left to its own devices. It loses value when the system it was written for changes, dependencies get updated, and it bit-rots. It loses value as the people who wrote the original program, or worked with those who did, leave and the organization starts to forget what it was for, how it works, and what it's supposed to do.
You still have to figure out what to build, how to build it, how it serves your users and use cases, etc.
LLM's, at best, generate some code. Plain language is not specific enough to produce reliable, accurate results. So you'll forever be trying to hunt for increasingly subtle errors. The training data will run out and models degrade on synthetic inputs. So... it's only going to get, "so good," no matter how many parameters of context they can maintain.
And your ability, as a human, to find those errors will be quickly exhausted. There are way too few studies on the effects of informal code review on error rates in production software. Of those that have been conducted any statistically significant effect on error rates seems to disappear when humans have read ~200SLOC in an hour.
I suspect a good source of income will come from having to untangle the mess of code generated by teams that rely too much on these tools that introduce errors that only appear at scale or introduce subtle security flaws.
Finally, it's not "AI," that's replacing jobs. It's humans who belong to the owning class. They profit from the labour of the working class. They make more profit when they can get the same, or greater, amount of value while paying less for it. I think these tools, "inevitably," taking over and becoming a part of our jobs is a loaded argument with vested interests in that becoming true so that people who own and deploy these tools can profit from it.
As a senior developer I find that these tools are not as useful as people claim they are. They're capable of fabricating test data... usually of quality that requires inspection... and really, who has time for that? And they can generate boilerplate code for common tasks... but how often do I need boilerplate code? Rarely. I find the answers it gives in summaries to contain completely made-up BS. I'd rather just find out the answer myself.
I fear for junior developers who are looking to find a footing. There's no royal road. Getting your answers from an LLM for everything deprives you of the experience needed to form your own theories and ideas...
so focus on that, I'd say. Think above the code. Understand the human factors, the organizational and economic factors, and the technical ones. You fit in the middle of all of these moving parts.
[0] https://pages.cs.wisc.edu/~remzi/Naur.pdf
Update: forgot to add the link to the Naur essay