You once again seem to be thinking of trivial examples of frontend to say there is an “easy” way to verify the loops. I really wish it were that simple for anything reasonably complex I encountered that were customer-facing — often filled with plugins/apps/micro-frontends/libraries owned by other teams etc or clients. I also think if it were that simple, companies wouldn’t be popping up every now and then trying to solve challenges in this space w.r.t validating flows, interactions/animations are smooth and ensuring some weird stuff isn’t happening across all the browsers the customers of your product are using. But there are a lot of them gunning for a piece of the pie, more since the LLM frenzy. And this is largely just web stuff I’m talking about, I’m sure similar complexity exists for mobile apps if we are to count that also into the equation.

Re: backend risks, I once again think you try to rub this off by equating all of backend development is done the way you’re talking about — to perfection, with backups, tests for those backups and all that. I’m sorry to burst your bubble here but if we’re thinking about the same kind of scrappy development you’re talking for frontend, the backend side is about as bad or worse (given how critical you think all of this is, which I agree with). I doubt the backend engineers are sitting there, carefully reading manuals and crafting code instead of vibecoding.

> You can't just vibe code the infra configs and hope for the best, you need someone who understands the output well enough that they could have written it themselves.

It’s not vibecoding but I’ve seen engineers in this role google, copy-paste and modify configs and scripts that run multi-million dollar workflows which somehow worked at the end of the day. I bet LLMs can do a much better job than that, don’t you?

> It's also much harder to simulate the output of LLM infra changes compared to running a browser, so it's more expensive to get training data to boost the next version of the model's performance.

I disagree. It’s much, much harder to go and debug why your customer on X OS, Y Browser and Z GPU (to simplify) is seeing glitches when others are not. Sometimes that leads you to browser bugs. I am yet to see any AI-loop based tools come close to tackling the kind of real-life, serious prod-driven challenges. If you think running a browser is all it takes, I can say something dumb like “running a container is all it takes” but see how stupid that sounds? :)

And it’s also silly to think UI mistakes don’t have real-world implications. There are countless examples for this already — broken purchase flows resulting in losses, frustrated customers unable to complete their work and leaving apps, incorrect request flows causing small/big DDoS, sometimes even stuff that might lead to lawsuits.

——

I feel you have a bleak view of frontend as a whole or you never worked with teams who do a good job or you have been conned by the chest-thumpers who have been saying for years and YEARS that frontend development is pointless, not real CS and have zero value. Oh, and that JavaScript is not a serious language — classic!

If I saw backend/infra engineering the same way based on the # of devs and teams I had to hand-hold and # of their mistakes I had to help fix while working as a front-end engineer, I’d be shitting on them too. But I know better to see that there’s a right way to do it.