As engineers, we can be the supervisor, doing code review, managing things at a higher level. Instead of choosing which libraries to do the work for us, we choose which LLM to write that code and we make sure those tests are all good and we insist they fix the failures they gloss over.
As coders… well, right now it's only "mostly" taking over that, because there are still cases where the AI has no idea what it's doing, where it can* get the syntax right but the result is still useless. One example of this I've been trying recently is having an LLM do music generation**, both with "give me a python script to make a midi file" and Strudel (https://strudel.cc), and at this task it sucks much much worse than GPT-2 did with dungeon text adventures.
I'm always on the lookout for the failure modes, because those failure modes are going to be my employment opportunities going forwards.
Right now, if you're a coder who knows something else besides just coding, I think you can do useful work with the intersection that a lot of other coders without that side-interest would fail at even with LLM assistance. On the other hand, if your only side-interests are other forms of code, e.g. you want to make a game engine and a DSL for that game engine, but you're not fussed about writing any games with either, then you probably won't do well.
* "can", not "will always" like we're used to in other domains.
** "why not use Suno?" I imagine you asking. Where Suno works well I like it, but it also has limits. Ask it for something outside its training domain… I've tried getting a 90 second sequence of animal noises with no instruments, it made something 140 seconds long consisting of only instruments and no animal noises.