Why AI coding assistants write clean-looking CSS that breaks in production (and how to fix it)

A developer has documented five recurring CSS bugs that AI coding assistants such as Cursor, Claude, and Copilot introduce in frontend code, including layout shift from loading spinners, flexbox overflow from missing min-width bounds, and tooltips that fail on natively disabled buttons. The writeup pairs each failure mode with a production-ready fix, such as keeping the original label in the DOM to lock button width and using aria-disabled instead of the disabled attribute so hover events still fire.

If you use Cursor, Claude, or Copilot for frontend work, you already know the feeling. You prompt the model to generate a dashboard card or a modal component. It spits out fifty lines of clean TypeScript and Tailwind classes in two seconds. It compiles without errors. In your local browser with sample data, it looks ready to ship. Then you deploy it to staging or open it on your phone, and subtle UI bugs start popping up everywhere. The layout jumps every time a button loads. Long usernames overflow their containers. Tooltips stop working on disabled buttons. Text gets clipped on smaller screens. AI models are great at syntax, but they tend to skip defensive CSS patterns. Here are five visual bugs AI coding assistants introduce on almost every prompt, and the exact code fixes to prevent them. When you ask an AI to add a loading state to a button, it almost always writes something like this: // Typical AI code <button disabled={isLoading} className="px-4 py-2 bg-blue-600 text-white rounded-md" {isLoading ? <Spinner className="w-4 h-4" / : "Save Changes"} </button The problem is that a 16px spinner is much narrower than the text "Save Changes". The moment the user clicks, the button width shrinks. Adjacent inputs and buttons shift across the screen, causing a jarring Cumulative Layout Shift CLS . Keep the original label in the DOM to lock the button width, and place the spinner in an absolute overlay: // Production fix <button disabled={isLoading} className="relative px-4 py-2 bg-blue-600 text-white rounded-md" <span className={isLoading ? "invisible" : "visible"} Save Changes</span {isLoading && <span className="absolute inset-0 flex items-center justify-center" <Spinner className="w-4 h-4 animate-spin" / </span } </button This keeps the button width fixed regardless of state. AI tools love flexbox, but they rarely include defensive width bounds. When a user has a long name or uploads a file with a fifty-character title, the layout breaks. // Typical AI code <div className="flex items-center gap-3" <Avatar / <div className="flex flex-col" <span className="font-medium truncate" {user.name}</span <span className="text-sm text-slate-500 truncate" {user.email}</span </div </div Adding truncate does nothing here because flex children default to min-width: auto . If the container gets squeezed, the text refuses to shrink and pushes the parent element beyond the viewport. Add min-w-0 to the flex child holding the text: // Production fix <div className="flex items-center gap-3" <Avatar / <div className="flex flex-col min-w-0" <span className="font-medium truncate" {user.name}</span <span className="text-sm text-slate-500 truncate" {user.email}</span </div </div That one utility class tells the browser that the flex child is allowed to shrink below its content width, making text truncation work as expected. When an action is blocked, you usually want a tooltip explaining why for instance, "You need admin permissions to delete this project" . AI models almost always disable the button directly: // Typical AI code <Tooltip content="Admin permissions required" <button disabled={ isAdmin} className="btn-primary" Delete Project </button </Tooltip When HTML buttons have the native disabled attribute, browsers stop firing all mouse events on that element. Hovering over the button will not trigger mouseEnter, and the tooltip never renders. Users click a dead button with no idea why it is inactive. Use aria-disabled and manage the interaction styles manually: // Production fix <Tooltip content={ isAdmin ? "Admin permissions required" : ""} <button aria-disabled={ isAdmin} onClick={ e = { if isAdmin { e.preventDefault ; return; } handleDelete ; }} className={ btn-primary ${ isAdmin ? "opacity-50 cursor-not-allowed pointer-events-auto" : ""} } Delete Project </button </Tooltip The button remains keyboard and screen-reader accessible, mouse events still bubble to the tooltip, and the user gets a clear explanation. Ask an AI model for a modal, drawer, or settings panel, and it will often set a fixed height: // Typical AI code <div className="fixed inset-0 bg-black/50 flex items-center justify-center" <div className="w- 500px h- 600px bg-white rounded-lg p-6 flex flex-col justify-between" <ModalHeader / <ModalBody / <ModalFooter / </div </div On a desktop monitor, 600px looks fine. On a smaller mobile screen or a laptop with browser toolbars open, the modal footer gets pushed off the bottom edge. Users cannot see or tap the submit button. Use dynamic viewport units and internal scroll areas: // Production fix <div className="fixed inset-0 bg-black/50 flex items-center justify-center p-4" <div className="w-full max-w-lg max-h- 90dvh bg-white rounded-lg flex flex-col" <div className="p-6 border-b border-slate-200" <ModalHeader / </div <div className="p-6 overflow-y-auto flex-1" <ModalBody / </div <div className="p-6 border-t border-slate-200" <ModalFooter / </div </div </div The header and footer stay pinned in view, while long form content scrolls cleanly inside ModalBody . When generating edit modals, AI tools frequently store form inputs inside component state without resetting them when the target entity changes. // Typical AI code function EditUserModal { user, isOpen, onClose } { const name, setName = useState user.name ; const role, setRole = useState user.role ; if isOpen return null; return <Modal onClose={onClose} <input value={name} onChange={ e = setName e.target.value } / </Modal ; } If the user edits "Alice", closes the modal, and clicks edit on "Bob", the inputs will still show "Alice". The state initialized on the first mount and never refreshed. Key the modal instance by entity ID at the call site so React tears down and remounts fresh state on entity change: // Production fix at the parent call site {activeUser && <EditUserModal key={activeUser.id} user={activeUser} isOpen={Boolean activeUser } onClose={ = setActiveUser null } / } Using a key boundary is cleaner and less error-prone than juggling multiple useEffect reset hooks inside the child component. Fixing these edge cases prompt after prompt takes up a lot of code review time. One way to solve this is to define strict CSS rules directly inside your .cursorrules or AGENTS.md file so the model stops reaching for fragile patterns. Another is maintaining a dedicated set of accessible UI primitives that already handle layout shifts, touch targets, and viewport bounds out of the box. We put together an open-source collection of accessible flat UI primitives for React 19 and Next.js 16 over at devpreflight.com https://devpreflight.com to save developers from rebuilding these safeguards on every project.