Concepts

Why does AI-generated UI look AI-generated?

Because coding agents design from defaults instead of from the job. They don't know who uses the screen, what that person is trying to do, or what your product has already decided, so they reach for the most common pattern. Here are the tells, why they happen, and what actually fixes them.

AI-generated UI looks AI-generated because coding agents design from defaults, not from the job. An agent building a screen usually doesn't know who will use it, what that person is trying to get done, or what your product has already decided. So it falls back on the most common answer: the component library's defaults and the layout that maps most directly onto the data. The result compiles, passes review and looks competent. It also looks like every other agent-built app, and it often doesn't fit the person using it.

That's a fixable problem, but not with a better adjective in the prompt.

The tells

You've seen these. Each is a reasonable default that becomes a tell when it shows up regardless of the job.

None of these is wrong in itself. They're wrong when they're chosen because they were the default, not because they serve this user and this job.

Why agents produce them

Three gaps, all about context.

1. The agent doesn't know the job. It knows the schema: tables, fields, types. It doesn't know the person on the other side is a planner clearing twenty reorder decisions before lunch, or a reviewer deciding whether to ship a pull request in two minutes. Without the job, the data shape is the only signal left, and the data shape suggests a table, a dashboard and a form per record.

2. The agent doesn't know your design system. If your tokens, components and the reasoning behind them aren't in front of the agent, the component library's defaults win. Even when a DESIGN.md exists, nothing checks that the result follows it.

3. Nothing checks the result against the user. The agent's loop has a type checker, a linter and tests. None of them ask whether the screen fits the job. So the first design review happens later, from a human, after the layout is already in the code. Often it doesn't happen at all.

The pattern: an agent with no job, no design context and no review defaults to the most common answer. The most common answer is what "AI-generated" looks like.

What doesn't fix it on its own

What does fix it

Close the three gaps, inside the agent's loop, on every screen:

  1. Before the build, give the agent the job. Who uses this screen, what they're trying to do, which heuristics and patterns apply, and your design tokens. A short brief changes what the agent builds, not just how it styles it.
  2. After the build, review against the job. Score job fit, UX heuristics, cognitive load and pattern conformance, plus brand and visual quality from a real screenshot. Then let the agent fix what's flagged and check once more.
  3. Remember. Keep a model of the project, its personas and past findings, so the next brief starts smarter and every agent on the repo shares it.

That's what a design agent in your coding agent's loop does, and it's what we built TheDesignAgent to be. Setup takes a few minutes in Claude Code, Codex or Cursor. For the wider landscape, see the best AI design agents in 2026.

A quick check for your own screens

Before you ship an agent-built screen, ask:

If the honest answer to the last one is "no", that's the AI-generated look.