DEV Community

Cover image for How to fix the 'AI-generated' look in your frontend
Alan West
Alan West

Posted on

How to fix the 'AI-generated' look in your frontend

The problem: every AI site looks like the same AI site

I did a small experiment last month. I asked three different code-gen tools to build me a landing page for a fake SaaS product. Different prompts, different sessions, different models. The output? Practically identical.

Purple-to-blue gradient hero. Three feature cards in a row with rounded corners and lucide icons. A pricing section with the middle plan slightly elevated. A FAQ accordion at the bottom. CTA button with bg-indigo-600 hover:bg-indigo-700.

If you've shipped anything with an LLM lately, you've seen it. There's a specific visual fingerprint to AI-generated frontends, and once you can spot it, you can't unsee it. The frustrating part is when a client or a non-technical stakeholder looks at your work and says "this looks like ChatGPT made it" — even when half of it didn't.

Let's debug why this happens and walk through fixes that actually move the needle.

Root cause: the model is averaging over its training data

LLMs that generate UI code aren't choosing aesthetics. They're predicting the most likely next token given billions of public code samples. Public code samples are overwhelmingly tutorials, starter templates, and component libraries — which all tend to use the same defaults.

There are three specific failure modes I keep seeing:

1. The default Tailwind palette

The Tailwind default config uses a specific set of named colors (slate, indigo, emerald, etc.) that are mathematically pleasant but instantly recognizable. When a model can't decide on a color, it reaches for indigo-600 or slate-900 because those tokens appear in roughly a billion tutorials.

2. The component-library layout vocabulary

Hero → features grid → social proof → pricing → FAQ → footer. This isn't because that's the right layout for a landing page. It's because it's the layout used in every shadcn/ui example, every Tailwind UI screenshot, every Vercel template. Models pattern-match on structure.

3. The "safe" typography pairing

Inter for everything, with the occasional font-bold for headings. Default line-height. Default tracking. The result is technically readable and entirely forgettable.

The fix, part 1: tear out the default palette

First step is replacing your Tailwind theme with something that doesn't ship by default. Don't just rename indigo to primary — actually pick colors that aren't in the default scale.

// tailwind.config.js
import { defineConfig } from 'tailwindcss'

export default {
  theme: {
    // 'extend' keeps defaults; replacing 'colors' wipes them entirely
    colors: {
      transparent: 'transparent',
      current: 'currentColor',
      // custom palette built from a base hue, not 'indigo'
      ink: {
        50:  '#f6f5f1',
        500: '#3d3a32',
        900: '#1a1814',
      },
      ember: {
        400: '#e8775a', // warm accent, not the usual cool blue
        600: '#c45530',
      },
    },
    fontFamily: {
      // pair a serif display with a mono body for an unusual feel
      display: ['"Fraunces"', 'serif'],
      sans: ['"IBM Plex Sans"', 'sans-serif'],
    },
  },
}
Enter fullscreen mode Exit fullscreen mode

Notice I dropped colors instead of extending it. That kills bg-indigo-600 entirely — if the model (or a junior dev) tries to use it, the build fails. Forcing the failure is the point. It pushes everyone toward the custom palette.

The fix, part 2: break the layout grammar

AI-generated layouts are almost always vertically stacked, full-width sections with centered content. You can break this pattern with very little code by using CSS Grid for asymmetric layouts.

/* asymmetric hero — content offset to the left, art bleeds right */
.hero {
  display: grid;
  grid-template-columns: minmax(2rem, 1fr) minmax(0, 38rem) minmax(0, 1fr);
  align-items: end;
  min-height: 80vh;
}

.hero__content {
  /* sit in the second column, not centered across the page */
  grid-column: 2;
  padding-block: 4rem;
}

.hero__art {
  /* let the visual element extend past the content column */
  grid-column: 2 / -1;
  align-self: stretch;
}
Enter fullscreen mode Exit fullscreen mode

This is a five-minute change that immediately signals "a human chose this." Centered hero + three cards is the visual equivalent of beige carpet. Off-center compositions, overlapping elements, and content that breaks the grid all read as intentional design choices.

The fix, part 3: kill the rounded-2xl reflex

Every AI-generated component has rounded-2xl shadow-lg p-6 somewhere. Override your component defaults at the source.

// components/Card.jsx
export function Card({ children, variant = 'default' }) {
  // pick ONE radius vocabulary for the whole site, not per-component
  const variants = {
    default: 'border border-ink-500/20 bg-ink-50',
    inset:   'border-l-2 border-ember-600 bg-transparent pl-6',
    flat:    'bg-ink-50',
  }

  return (
    <article className={`${variants[variant]} p-5`}>
      {children}
    </article>
  )
}
Enter fullscreen mode Exit fullscreen mode

No border radius. No drop shadow. Borders and color contrast do the work instead. This won't fit every brand, but the point is to pick a vocabulary and stick to it rather than letting each component drift toward generic-AI-card defaults.

The fix, part 4: replace placeholder copy before showing anyone

This one isn't visual, but it triggers the same uncanny-valley response. "Empower your team to unlock productivity" and "Built for modern teams" are the textual equivalent of the purple gradient. If you ship a draft with that copy, even non-technical people pick up on it — they can't articulate why, but they know.

I keep a checklist on my second monitor before any client review:

  • No sentence that starts with "Empower", "Unlock", or "Transform"
  • No feature card titled with two abstract nouns ("Seamless Integration")
  • At least one specific, concrete claim with a number
  • At least one sentence that sounds like a real person wrote it

Prevention: catch it in code review

The cheapest fix is a linter rule that fails the build when forbidden class patterns show up. Tailwind's safelist and a custom ESLint rule can enforce this:

// eslint custom rule, simplified
module.exports = {
  create(context) {
    const banned = [
      /bg-(indigo|violet|purple)-600/,
      /rounded-(2xl|3xl)/,
      /from-purple-\d+ to-(blue|pink)-\d+/, // the gradient
    ]
    return {
      Literal(node) {
        if (typeof node.value !== 'string') return
        for (const pattern of banned) {
          if (pattern.test(node.value)) {
            context.report({
              node,
              message: `Banned default-AI class: ${node.value}`,
            })
          }
        }
      },
    }
  },
}
Enter fullscreen mode Exit fullscreen mode

Is this petty? A little. But I'd rather have CI yell at me than ship something a client describes as "that AI look." After putting this rule in place on two projects, the diffs got noticeably more interesting — people started reaching for the custom tokens instead of the defaults, because the defaults didn't compile.

The takeaway

The "AI look" isn't really about AI. It's about defaults. LLMs amplify defaults because their training data is mostly default-using code. The fix isn't to stop using AI assistance — it's to remove the defaults from your toolchain so neither the model nor your team can fall back on them.

Replace the palette. Break the layout grammar. Pick a component vocabulary and enforce it. And read the copy out loud before you ship.

Top comments (0)