I disagree about your last statement. That only covers the initial creation/generation phase. It ignores the engineering aspect of maintaining that design through the entire lifecycle of the product. How do you evolve that table design?

Sure an LLM can update every table in your project every time you make a change, just as a human could. It also can make mistakes and burn significantly more tokens doing so. Or, it could update one component with a one line change and be done. Easy to verify, less change for mistakes.

Engineering is a discipline and does not change dramatically with the advent of outsourcing it to agents.

> to translate code into a different language someone would need to write a tokenizer, a parser, an AST and finally a translator. All significant engineering challenges, taking days to finish. Nowadays you can tell an LLM to do that in minutes.

Do people do that on a regular basis? The most recurring case of building the above is when someone wants to include a language into a project and they usually don't bother with a translator. The second case is when transpilling (ex. LESS to CSS) and that's more akin to macro and other preprocessing tricks than a full blown translation.

> we could easily argue that CSS wouldn't have existed if LLMs existed and could create table layouts from pasted images in a chat window.

All current UI and Document conceptual models include styles (either as direct properties or separate models) and some does include named styles. The novel aspect of CSS is the Cascading concept, not the styling part. And cascading is obvious when we consider that there was supposed to be user stylesheets for documents. I read epub and user stylesheets (created from UI) is crucial.