Why AI UI Drifts Off-Brand

If you've shipped anything with Claude Code, Cursor, or Copilot, you've seen the symptom: the app works, but it looks like every other AI-generated app. Same rounded cards, same indigo buttons, same Inter-on-white sameness. This page names the four mechanisms behind that, so you can diagnose which one is biting you, and fix the right thing.

Why does AI-generated UI look the same?#

Coding models learn UI from public code and design content, which is dominated by a handful of frameworks, UI kits, and default themes. When a prompt underspecifies the design (and almost every prompt does), the model falls back to the statistical center of that training data: the most common palette, the most common radius, the most common font stack. This explanation is widely discussed rather than formally established, but the output pattern is consistent enough that it has a name: AI slop.

The industry data point that made this concrete: Atlassian's published test on giving agents design-system context described the jump in output quality as going "from generic 'slop' to something recognizably Atlassian." The variable that changed wasn't the model: it was whether the model had the brand's actual design decisions in context.

The deeper issue is that "looks generic" isn't one problem. It's four, and they have different fixes.

The four failure modes of design drift#

1. Token fabrication#

The model needs a value your prompt didn't supply (a hover state, a border gray, an error red), so it makes one up from its training priors. The fabricated value is usually plausible, which is what makes it dangerous: #10B981 instead of your brand's #0F4C3A passes a glance and fails a brand review.

Scenario (illustrative, not a measurement): you ask for a pricing page. Your design system's primary is a deep forest green. The agent ships a default UI-kit emerald with an 8px radius your system doesn't use. Nobody specified those values: that's the point. Fabrication fills every gap you leave.

For context on how many values a real system involves: in our July 2026 analysis of the 61 parseable files in the awesome-design-md collection (74 total), the median design system defines 23 colors and 14 typography levels. A prompt specifies maybe three of those. Everything else is fabrication surface.

2. Within-session drift#

Even when a session starts on-brand, it rarely stays there. As the conversation grows, early instructions compete with hundreds of later messages, diffs, and errors: their influence dilutes. The model starts "harmonizing" new components with its own recent output instead of your original constraints.

Scenario (illustrative): a two-hour session building a dashboard. The first button uses your 4px radius. By component five, cards have drifted to 12px; by component nine, there are two similar-but-different grays and a second font weight. No single step looked wrong. The sum is a screen your design lead can't approve.

3. Between-session amnesia#

Chat context dies with the session. The twenty corrections you made yesterday ("radius is 4px, not 8"; "never use pure black") shaped yesterday's context. Today's session knows none of it. Multiply by every developer on the team, each re-teaching the same conventions and each getting a slightly different result.

Scenario (illustrative): the same prompt ("build a settings screen") run in three fresh sessions produces three visually different screens: different accent shades, different spacing rhythm, different table styling. None are wrong in isolation; together they're three products.

4. Silent breaking changes#

Agents edit code globally and confidently. When a later task touches shared styles (a theme file, a base component), the agent may "improve" values that were deliberate, and nothing fails: no type error, no test, no warning. You discover it two sprints later when someone asks why the buttons changed.

Scenario (illustrative): "make the dashboard denser." The agent tightens padding inside the shared Button component, shrinking every button in the app, and while it's there, nudges the disabled-state gray. The diff is 40 lines in a 900-line change. It merges.

What doesn't fix it#

• Prompt engineering alone. A meticulous style prompt works exactly once, then evaporates (amnesia) and dilutes (drift). You cannot re-paste your design system into every prompt forever, and your teammates won't.
• Screenshots as reference. Models can imitate a screenshot's mood, but they read approximate values from pixels: near-miss colors and eyeballed spacing. That's fabrication with better camouflage.
• Your existing style guide PDF or Figma. The decisions are right; the medium is wrong. Agents can't reliably parse a 60-page brand PDF, and a design file isn't in the repo where coding agents work. Documentation written only for humans doesn't constrain a machine.

What fixes it: persistent, machine-readable design context#

All four failure modes share one root cause: the model doesn't have your design decisions in context at the moment it writes code. The fix is to put them there, permanently, in a form both machines and humans can read. This is the idea behind agentic design systems. An agentic design system is a design system structured so that AI agents can read, interpret, and apply it autonomously: design tokens, component specs, and usage rules exposed as machine-readable context (via files like DESIGN.md or an MCP server) rather than as documentation written only for humans. More on that concept in our overview of agentic design systems.

The lightest-weight implementation is a file in your repo. DESIGN.md is an open-source file format from Google that stores a complete design system in a single Markdown file: machine-readable design tokens (colors, typography, spacing, components) in YAML frontmatter, plus human-readable rationale in Markdown prose. AI coding agents like Claude Code, Cursor, and Copilot read it to generate UI that consistently matches your brand. Map it against the failure modes:

1. Token fabrication → exact values exist in the repo, plus a standing rule to ask instead of invent.
2. Within-session drift → the file can be re-read at any point to re-anchor a long session.
3. Between-session amnesia → the file is committed; every session and every teammate starts from the same source of truth.
4. Silent breaking changes → design decisions live in a reviewable file, and npx @google/design.md diff reports token-level changes between versions, with a nonzero exit code on regressions, so CI can catch them.

To be clear, DESIGN.md is one approach, not the only one. Editor rules files encode instructions (but not tokens), and MCP servers expose a design system dynamically. In the same Atlassian test, their MCP server (and skills) covered about 80% of their design system, versus about 30% for DESIGN.md alone, and using DESIGN.md as the sole source needed roughly 92% more tokens than the MCP approach, while the Markdown file still produced their best one-shot prototypes. The honest comparison lives in DESIGN.md vs MCP. For most teams, the file is the right first step: no server to run, works in every tool, reviewable in a PR.

Quick start#

1. Create a DESIGN.md in your repository root with your real tokens (colors, typography, spacing, components) in YAML frontmatter, and your non-obvious rules as prose. What is DESIGN.md covers the format basics.
2. Point your agent at it. Agents don't read it automatically: add a reference in CLAUDE.md for Claude Code or a rules file for Cursor: "read DESIGN.md before any UI work; follow its tokens exactly; ask instead of inventing missing values."
3. Verify, don't trust. Lint the file (npx @google/design.md lint DESIGN.md), render it in the DESIGN.md viewer to see your tokens as swatches, and compare generated screens against that rendering.

---

Next step: name the failure mode you're seeing, then set up the fix in your tool: DESIGN.md with Claude Code or DESIGN.md with Cursor, and paste your file into the viewer to see what your agent will actually follow.