In a large CSS codebase, changing one element's utility classes feels safe while changing `.card { padding: 24px }` in the stylesheet does not. Explain the mechanism behind that asymmetry and what it means for a codebase maintained over several years.

## Why the shared class is dangerous A CSS class selector is a **global name with no declared users**. The stylesheet says what `.card` does; nothing anywhere says who uses it. Finding out means searching every source of markup, and in a real product markup comes from more places than the repository: server templates, client components, a CMS where editors pasted HTML, a marketing page owned by another team, transactional emails, a third-party widget configured with your class names. So the question "is it safe to change `.card`'s padding?" is genuinely unanswerable in the strict sense. You can search and be *fairly* confident. You cannot be certain, and the failure mode is visual breakage in a place nobody looks until a customer complains. Contrast with editing the classes on one element. The set of things that can change appearance is exactly one element. You do not need to know the codebase; you need to know this template. That is not a smaller risk of the same kind — it is a **bounded** risk instead of an unbounded one. ## The ratchet this creates Give that asymmetry a few years and many hands, and it produces a predictable pathology. Faced with "this card needs less padding here", the engineer has two options: 1. Change `.card` — cheap to type, unknown blast radius, might break pages they have never seen. 2. Add `.card--compact`, or a more specific selector such as `.sidebar .card`, applying only where needed — slightly more code, zero risk to anything existing. Option 2 is correct for the individual every single time. The aggregate result is a stylesheet that only ever grows, in which the same visual idea is expressed a dozen ways, and in which specificity escalates because each new override must out-rank whatever was added before. Eventually somebody reaches for `!important`, and the file becomes something people route around rather than edit. Dead rules accumulate for the mirror-image reason. When a component is deleted, its CSS stays, because proving the class is unused runs into the same unanswerable question — and an unused rule costs bytes, while a wrongly deleted one costs an incident. ## What utility-first actually changes Utility-first does not make CSS safer to edit. It makes you edit CSS far less often. Day-to-day styling work becomes markup work — adding, removing and swapping classes on a specific element — which is bounded by construction and reviewable in the same diff as the markup it affects. The stylesheet is touched only when the *vocabulary* changes, which is rare and deliberate once the system settles. Two further consequences follow: - **Deletion becomes safe.** Delete the markup and its styling goes with it. There is no orphaned rule left behind, because no rule was ever written for that component. - **Reading becomes local.** To know what an element looks like you read the element. You do not have to reconstruct the cascade from several files and hope you found every matching selector. ## What you give up The wide blast radius is not purely a hazard — it is the mechanism by which a single edit restyles the whole product. "Every card gets more padding" is one line in a component stylesheet and a mass edit in raw utility markup. Utility-first recovers this only if the class string lives in one place, inside a template or component. That is why utility-first works well on componentized codebases and poorly on hand-written pages: without the markup abstraction, you have traded an unbounded risky edit for a bounded but enormous one. It also weakens shared vocabulary. `.card` is a name a designer and an engineer can both say. A class string names nothing, so the shared term has to live in the component layer instead — which is fine when that layer exists and a real loss when it does not. ## How to answer this in an interview Lead with the mechanism — global names with no reverse index, therefore unbounded blast radius — then the ratchet it causes over time, then the honest counterweight that the wide reach is exactly what makes a global restyle a one-line change. Candidates who only say "utilities are easier to delete" are repeating a slogan; candidates who explain *why* the individually rational choice degrades the codebase have actually lived in an old stylesheet.