> The trope of "frontend is not a serious job" has been infuriatingly going on for a long time before LLMs took the center stage and that seeps out of the things you've said so far.
Eh, sorry I came across that way. To me, seeing a complex system visualized, making it interactive, is just so beautiful. That's a big part of why I got into frontend in the first place. I wouldn't take anyone seriously who doesn't think frontend is a serious job.
I also suspect that you are doing more complex, and finely judged frontend work than I did - I took a peek at your public profile ;). So it's not surprising that we have different impressions. If someone is building a frontend that needs to work seamlessly for billions of people across many devices, that sounds incredibly challenging and frankly I've never even tried to do that so I can't even comment on it.
But, I would say that a lot of the frontend work that I find interesting can now be automated with LLMs. Historically, I've tended to build internal tools that usually had a fixed runtime environment and small number of users. So I'm not as worried about the fine points of the web, but about creating a lot of features and interactivity in a particular, easily tested environment. I would wager that the average frontend developer is doing work somewhere in between the two of us.
> you can apply these _exact_ arguments to a _shockingly_ large portion of backend too
Hmm, I think we just disagree here. I think a lot of my view comes down to how frontend ultimately needs to collapse into something that can be visualized and interacted with, and this helps force the state to evolve in sane ways. On the other hand, I think backends quickly grow from a spreadsheet to insane, highly-dimensional, highly-coupled nightmares that no one can really visualize anymore, first at the logic level and later at the architecture and schema levels.
Ultimately LLMs are helpful when they can sort of grok the overall structure and plan of your code and add stuff helpfully to it. I think that LLMs have more public examples of frontend codebases and that helps them follow the overall structure a bit better. In my experience, LLMs are doing a bit better in trying to add small features to large frontend codebases than to large backend codebases, probably for this reason.
Finally, you can often define what changes are wanted on the frontend fairly precisely. A series of mockups plus descriptions of the interactions carries a lot of detail. On the other hand, backend changes often interact implicitly with unstated business context that you can't get solely from the backend code itself (this become particularly tough when you try text-2-SQL, for example.) So I think many backend and architectural changes have inherently vague specifications that need to lean heavily on context that's not captured in the ticket.
None of this is meant to undermine the seriousness or difficulty of frontend as a profession. But it is still my opinion that, on average, LLMs have a better chance of doing useful things on the frontend than the backend.