If you're doing industrial embedded work and have an oscilloscope and a logic analyzer on your desk, and spend part of your time going into the plant and working directly with the machinery, you're in better shape.
This differentiating factor is what will wear out a less-experienced LLM user. They will make bigger claims or set expectations higher, and suffer more for them. The details that matter, yet were missed, will stick out more and more, as more experienced LLM users flex that experiential factor in a variety of ways.
For this reason, front end will absolutely still be a thing. And it'll be a much better, deeper thing, thanks to those who are a good fit for a kind of LLM-coding mindset.
However, this also depends on the type of coder. You can start from interpretation of the project spec as a logical code of sorts, or you can start from the spec as more of a visualized outcome.
If you work in the latter style, your survival key, so to speak, may simply be stringing together support requests you make to various LLM-interfacing vendors. A COTS-integrative style / opportunistic approach to coding, which has always been a thing.
Along the way, this kind of person usually integrates the NIH logical style a bit, and vice-versa, or they'll suffer through their respective blind spots. Same story, new layer of abstraction that's really cool.
(Plus...survival may still depend on who you know, not what you know, for a lot of people)