backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.
I totally get your point. I'll just give you a little color about where I'm coming from. Most products don't need a team of over five frontend/backend devs (so imagine a team of 10 people). Most teams have been over staffed. When you are overstaffed, that's when everyone needs to be cookie cutter
with cookie cutter expectations (e.g backend should do ui, frontend should backend). On non-overstaffed teams, the core group compliments each other very well and brings extreme expertise. No one on such a team ever goes "I can do what that guy does", because it's not a run of the mill mass market team.
I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.
That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.
Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.
