@darrylyeo
80% of the type of frontend engineering work I do is taking a giant soup of one-off UI coupled to particular expressions of application logic, and distilling it into generic, higher-level reusable UI components, with clearly enumerated input variables describing the exact range of styles and behaviors I want, and iterating on these properties as a prerequisite to supporting the unique features I want to add.
Without this underlying structure of a design system, you and your agents will be stuck fixing inconsistencies and edge cases for every possible instance and variant of a particular pattern or behavior, across every possible page or screen. Which means adding or changing a feature becomes a tedious O(n) task that scales with the literal amount of features and UI surface area involved, rather than ≈ O(log n) which scales only with the number of unique UI patterns and behaviors that you introduce.
In the age of software abundance and one-off vibe-coded UIs that no human software engineer would ever want to maintain, this is the kind of skill that is glossed over and which I think will become a bit of a lost art (which makes me a bit sad). But it’s what makes the difference between an average UI and a scalable, well-maintained UI. Or at least, one that a specialized UI dev or design engineer (increasingly endangered specimens) would be willing to steward for you.