I insist on certain ways to use CSS (this, I realized, is where most of the untapped "alpha" is. There are a lot of patterns, like the css checkbox trick and using selectors/tags to pull data from html element attrs, that can introduce a lot of interactivity and generality without JS) and specific design+page contents. Then I typically look at the output visually and make sure the structure doesn't do anything stupid. To fix things I often will just start editing the html and css manually until the page looks exactly like I want it, then save the temp state and pass it back into the model to make the code changes.

Basically I invested a lot of time in learning how CSS, browser apis, and modern html work and figuring out how to do tricks with them that eliminate or greatly reduce the need for SSR and JS. Even though this took several months and a LOT of specs/docs and tedious design work, it was worth it because now I actually understand the foundational abstractions that all these web UIs actually are implemented against, and which don't change. Now I only need LLMs and a way to communicate those tricks (and I know the right language and terms to use to get them build on the right foundations).

But I'm working towards training my own preference set and training pipeline/tools so that I can get models to output things the way I like without all the process/styling/etc. steering that I still need between and across sessions. This is why I think coding agents are long-term only going to be used for vibe coding or to replace less skilled SWEs. You can't get them to consistently do things the way you want or build new devtools/abstractions that get fully internalized and baked into the weights unless you trian them. And a very useful thing about vanilla css/html is that they are much more easily verifiable and something you can generated/search synthetically vs SSR-npm style output.