Design drift is the tax AI charges on generated UI

Vibe coding hands you an app in an afternoon, and every screen looks fine on its own. Open them side by side and you start squinting: the button radius is a little rounder over here, the gray is off by a step, the spacing almost matches but never quite. That is design drift. I keep writing that consistency is the trust signal because drift is its exact opposite — a hundred near-misses nobody can name but everyone can feel.

Design drift is the slow accumulation of near-misses in AI-generated UI, where no single screen is broken but the product stops reading as a system.

On this page

• What is design drift, exactly?
• Why does AI drift on every screen?
• Where does drift actually show up in a product?
• How do you stop design drift as a solo founder?

What is design drift, exactly?

A single broken screen is easy to catch. You look at it and fix it. Drift is harder because every screen passes the "looks fine" test — it only fails the test you never thought to run: does it look fine next to every other screen? Plausible individually, anonymous collectively. The screens do not share a source of truth, so each one is a fresh guess about the same design system, and the guesses are slightly different every time.

Why does AI drift on every screen?

Because the model generates each screen against its prior over what "SaaS UI" looks like, not against your tokens. There is nothing shared between one generation and the next, so the details re-roll every time. Nielsen Norman Group makes the sharpest version of this point: when the AI decides what to generate, it is accountable for the design decision — not just execution fidelity. Today that judgment defaults to whatever the model averaged in training, which is why you get the same off-palette gray and the same rounded button margin after margin.

Where does drift actually show up in a product?

Dark mode is the biggest tell. Generate screens light-first, then flip them to dark, and the colors shift meaning — a green that passed on white fails hard on black. Empty states, error states, hover states, data tables: all the surfaces the demo never showed. The unglamorous failure is often contrast, which is why I check generated output against WCAG's non-text contrast rule before shipping anything. The user will not say "the green is eight percent too saturated." They will say it feels off, or say nothing and click away.

How do you stop design drift as a solo founder?

Freeze the decisions before you generate, not after. Pick the palette, radius, spacing scale, and type first and encode them as tokens — plain CSS custom properties are enough. Then audit every generated screen against those tokens, not against the screen beside it. Same tokens on both sides means the screens converge by construction instead of by luck.

Treat generated output as a high-fidelity wireframe. The layout hypothesis might be worth keeping; the design system embedded in it almost certainly is not. And make the drift check a ritual: dark mode, empty states, hover and focus states, keyboard-only navigation. I miss something on every project, and the cheapest fix is a checklist that runs before I call it done.

Drift is the tax. Tokens are the exemption. Generating fast gets you the speed; auditing against one source of truth is what makes the speed worth anything. A founder who generates without a system ends up shipping a stranger's aesthetic by accident — and users notice even when they cannot say why.