> The frontend is less risky to just hand to an agent.
The smaller the problem, the less risky it is to do this, regardless of the nature of the problem. This is not a frontend-specific issue today.
The smaller the problem, the less risky it is to do this, regardless of the nature of the problem. This is not a frontend-specific issue today.
Systems engineering isn’t like that. Vibe coders beware: A database could silently corrupt data, or have latent security vulnerabilities. It might have a badly designed query language that will be difficult to change later. But frontend code can be rewritten at will. It’s a perfect target for LLMs.
Any website that has any UI state management or does any kind of network calls can be invisibly broken in many, many ways
Whatever lets you sleep at night man. If you really think you’re better than the machine at spotting arcane Unix incompatibilities, or that you’re somehow more “safe” than frontend jockeys, I’ve got really bad news for you.
??? Have you never debugged weird react state before??? Have you never used a nontrivial SPA before? Even the most simple react SPA has about a trillion states.
I don't really know how to respond to your statement than "no, they can definitely be invisibly broken."
Other kinds of software - for example, the backend of a website - have far more invisible failure modes. Security. Correctness. Performance. Bad API design leading to overfetching. Etc. Software works great on your machine and when you demo it, but it falls apart at scale. Endpoints that aren't secured properly. Race conditions cause silent data corruption. Memory leaks. And so on.
If claude messes up writing a react frontend, we're more likely to find the problem quickly. And frontend bugs usually don't continue to cause problems after they've been fixed. Silent bugs in the backend are more dangerous and more expensive.