# 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. Source: https://www.thedesignagent.ai/field-notes/why-ai-generated-ui-looks-ai-generated · Concepts · 2026-10-04 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. - **Library defaults, untouched.** The same cards, radii, grays and spacing as every other app built on the same kit. Nothing about your brand or your users changed the result. See [the component library constraint](/field-notes/the-component-library-constraint). - **The dashboard.** Four KPI cards, a table and a date filter, when the person needed to make a decision on each row, not watch totals. See [the dashboard default](/field-notes/the-dashboard-default). - **Tabs for a sequence.** A step-by-step workflow split across status tabs, so the user has to remember where they are. - **Modals for every edit.** Click a row, edit in a modal, save, close, click the next row. Twenty rows, twenty interruptions. See [modals all the way down](/field-notes/modals-all-the-way-down). - **Every field, every time.** Forms that ask for everything the schema has rather than what this moment needs. See [the eight-field form](/field-notes/the-eight-field-form). - **Filters for everything.** A filter for every column, because every column exists. See [the filter buffet](/field-notes/the-filter-buffet). - **Confirmation everywhere.** "Are you sure?" on actions that are cheap to undo. See [confirm everything](/field-notes/confirm-everything). 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 - **A better prompt.** "Make it modern and beautiful" changes the paint, not the decision about what the screen should be. And you'd have to write it again for every screen. - **A style skill.** Skills like Anthropic's frontend-design or Impeccable give the agent a stronger aesthetic voice, and they're worth having. They shape how the site looks; they don't know your users' jobs, and they don't check the result. - **An accessibility checker.** Axe or Lighthouse tell you whether a screen is valid. Keep them. A perfectly accessible dashboard is still the wrong screen for a deciding job. ## 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](/field-notes/add-design-review-to-claude-code), [Codex](/field-notes/add-design-review-to-codex) or [Cursor](/field-notes/add-design-review-to-cursor). For the wider landscape, see [the best AI design agents in 2026](/field-notes/best-ai-design-agents-2026). ## A quick check for your own screens Before you ship an agent-built screen, ask: - Could I describe the person using this and the decision they're making? Does the layout put that decision first? - Did the agent choose this pattern for the job, or because it's what tables usually become? - Does it use our tokens and components, or the kit's? - How many clicks, modals and fields stand between the user and done? - Would it look any different if it were built for a different product? If the honest answer to the last one is "no", that's the AI-generated look.