Why We Banned AI-Generated UI Components: The 'Perfect' Designs That Users Couldn't Click

For a brief, shining moment last quarter, our product development velocity doubled. Our designers would sketch a wireframe, pass it through an autonomous AI-to-React pipeline, and within seconds, we had a fully styled, visually stunning React component ready to be merged. The CEO praised our efficiency. The board was thrilled. Then, the support tickets started rolling in.

I am the lead design engineer at a SaaS platform managing inventory for mid-market retailers. When we started using AI to generate our frontend components, we evaluated the output entirely on aesthetics and unit test coverage. The buttons looked sleek, the gradients were modern, and the glassmorphism effects made our dashboard look like a premium consumer app. It was exactly the "wow" factor we were aiming for.

But software is not a static painting. It is an interactive, tactile interface that humans have to navigate using keyboards, screen readers, thumbs, and varying degrees of visual acuity. The AI models we used were trained primarily on screenshots of flat designs and GitHub repositories of visually complex web apps. They had absolutely no semantic understanding of human-computer interaction (HCI) fundamentals.

This is the post-mortem of how our "perfect" AI-generated UI caused a 14% drop in our core conversion funnel, the forensic analysis of the generated code, and the strict rules we instituted that ultimately led us to ban automated UI generation entirely.

The Aesthetic Mirage and the Semantic Void

The core failure of AI-generated UI is what I call the Aesthetic Mirage. The component looks correct visually, so the developer assumes the underlying structure is sound. Let me give you an example that took down our primary checkout flow.

Our team needed a complex multi-select dropdown with inline searching and category grouping. The AI agent produced a beautiful component. Here is a simplified version of the React code it generated:

// AI-Generated "Dropdown" Component
export const BeautifulSelect = ({ options, onSelect }) => {
  const [isOpen, setIsOpen] = useState(false);
  const [selected, setSelected] = useState([]);

  return (
    

      
 setIsOpen(!isOpen)}
      >
        
          {selected.length ? `${selected.length} Selected` : 'Choose categories...'}
        
        
      

      {isOpen && (
        

          

            
          
          

            {options.map(opt => (
              
 handleSelect(opt)}
              >
                

                {opt.label}
              
            ))}
          
        
      )}
    
  );
};

Visually, it was flawless. But fundamentally, it wasn't a dropdown or a select element at all. It was a stack of <div> tags masquerading as an interactive element. It lacked role="combobox", aria-expanded, aria-controls, and tabIndex. The options lacked role="option" and aria-selected.

When this component hit production, three things happened immediately:

• Keyboard Navigation Failed: Power users who navigate forms with the Tab key completely bypassed the input because <div> tags are not naturally focusable. Pressing Enter did not open the menu.
• Screen Readers Went Silent: Visually impaired users using NVDA or VoiceOver heard nothing when tabbing over the component. To them, the entire checkout configuration step simply ceased to exist.
• Mobile Focus Hijacking: Because the AI used a custom search input inside the popover without managing mobile keyboard events, tapping the search bar on iOS caused the screen to zoom awkwardly and immediately dismiss the popover dropdown, making it impossible to search.

The Touch Target Disaster

AI models lack physical bodies. They do not understand the biomechanics of a human thumb interacting with a 6-inch glass screen while walking down a street.

A few weeks into the experiment, the AI generated a new contextual action menu for our data tables. The prompt was: "Make it look like the sleek, minimalist action menus used in [Popular Consumer SaaS App]."

The AI delivered a beautiful horizontal row of icon-only buttons. The problem? The SVG icons were 16x16 pixels, wrapped in a <button> with zero padding. According to Apple's Human Interface Guidelines and WCAG 2.1 AA, touch targets must be at least 44x44 pixels (or 24x24 pixels for strict WCAG AA).

When users on mobile devices tried to click the "Edit" icon, their thumbs overlapped the "Delete" icon located just 8 pixels away. Our "Accidental Deletion" support tickets spiked by 400% in a single week. Users were furious.

UI Component Standard	Human-Engineered Metric	AI-Generated Metric	User Impact
Touch Target Size	Min 44x44 CSS pixels	16x16 CSS pixels	Severe mis-clicks on mobile devices
Color Contrast Ratio	Min 4.5:1 (WCAG AA)	2.8:1 (Light gray on white)	Unreadable in bright sunlight
Semantic HTML	Using native <button>	<div onClick={...}>	Completely inaccessible to keyboards
Focus States	Visible 2px offset ring	outline: none	Lost navigation context for keyboard users

The AI had prioritized the visual "sleekness" of tight clustering over the physical reality of human fingers.

The Cost of Remediation

The argument for AI generation was that it saved time. But the time saved writing the initial code was completely dwarfed by the time spent discovering, debugging, and remediating the inaccessible markup.

When a human writes a component, they generally use a shared design system or a robust foundational library (like Radix UI, React Aria, or Headless UI) that handles accessibility state machines out of the box. The AI, however, was trained to maximize the probability of generating code that looks like the prompt. It found that hallucinating raw CSS classes on div tags was the fastest path to visual success.

To fix the AI-generated dropdown, a senior frontend engineer had to spend 4 hours retrofitting a complex ARIA state machine onto the component, managing focus-trap logic, and writing unit tests for keyboard navigation. If we had just built the component from scratch using a primitive library, it would have taken 45 minutes.

Here is what the remediation code actually looks like when you have to fix an AI's inaccessible dropdown. Note the sheer amount of event management required:

// Human Remediation: Adding Accessibility to the AI Component
const handleKeyDown = (e: React.KeyboardEvent) => {
  if (e.key === 'ArrowDown') {
    e.preventDefault();
    if (!isOpen) setIsOpen(true);
    setHighlightedIndex(prev => Math.min(prev + 1, options.length - 1));
  } else if (e.key === 'ArrowUp') {
    e.preventDefault();
    setHighlightedIndex(prev => Math.max(prev - 1, 0));
  } else if (e.key === 'Enter' && isOpen && highlightedIndex >= 0) {
    e.preventDefault();
    handleSelect(options[highlightedIndex]);
  } else if (e.key === 'Escape') {
    setIsOpen(false);
    triggerRef.current?.focus();
  }
};

// We had to wrap the trigger in a proper semantic combobox
return (
  

    {/* Component body */}
  
);

The Breaking Point: The 14% Drop in Conversion

The final straw was the checkout redesign. The AI generated a multi-step checkout form that utilized floating labels (where the placeholder animates to become the label when you start typing). It's a popular design pattern, but notoriously difficult to implement correctly.

The AI's implementation relied heavily on the :placeholder-shown CSS pseudo-class. However, because our application used a password manager integration that auto-filled the inputs directly via JavaScript without triggering standard input events, the CSS failed to detect that the input was filled.

The result? The floating label remained positioned directly over the auto-filled text, rendering the email and password fields an illegible jumble of overlapping letters. Users couldn't read what they were submitting. Trust in the payment form evaporated, and our conversion rate plummeted by 14% over a 48-hour period.

Why We Banned It

We immediately rolled back the AI-generated checkout and instituted a total ban on autonomous UI code generation. We established a new set of operating principles for our frontend team:

1. Design Systems Over Generation

We returned to strict adherence to our internal design system, which is built on top of robust, accessible primitives. Developers are forbidden from writing custom dropdowns, modals, or tooltips. You compose existing, heavily tested components. AI is terrible at adhering to strict internal component APIs, often hallucinating props that don't exist.

2. Accessibility is the Primary Metric

A component that looks good but cannot be navigated with a keyboard is considered a critical production bug. Visuals are secondary to operability. We integrated eslint-plugin-jsx-a11y and axe-core into our CI pipeline to automatically fail builds that contain the kind of inaccessible markup AI models love to generate.

3. AI is for Logic, Not Interfaces

We still use AI. It is fantastic for writing data transformation functions, generating mock data for tests, or writing regex patterns. But the barrier between the user and the system—the User Interface—must be crafted by humans who understand human needs.

Conclusion

The allure of AI-generated UI is strong because visuals are the easiest part of frontend development to evaluate at a glance. It creates a false sense of completion. But an interface is not a picture; it is a machine. When you let an AI build the machine based only on what it looks like on the outside, you end up with a beautiful facade covering a fundamentally broken engine.

Software is built for humans. Until AI models develop thumbs, deteriorating eyesight, and the need to navigate the web using a screen reader, they have no business writing the code that connects humans to computers.