AI-Generated UI Fails in a Fixed Set of Ways
Generated interfaces share the same defaults, so their failures form a short list. That makes the fix a checklist run after generation, most of it checkable against source code, instead of better taste in the prompt.
Ask a coding agent for a dashboard and the result is familiar before it finishes loading. A saturated blue or purple accent. Emoji standing in for icons. A row of stat cards across the top, every card at the same visual weight.
The usual response is to work on the prompt: describe the look in more detail, add adjectives, name a style. I think that puts the effort in the wrong place. Olly Rosewell makes the argument in a video on SaaS interfaces. His claim is that the gap between a generated app and one people pay for is about a dozen interface decisions the tools get wrong by default. If the failures are a fixed list, the fix is an audit after generation, and an audit does not need taste.
Why the list is short
Rosewell's starting observation is that Cursor, Lovable and Bolt apply the same defaults every time. He does not measure this. He shows a grid of near-identical generated landing pages and lets the viewer recognize them. I find the explanation plausible: the tools learned from similar material, so their habits cluster.
His organizing line is "AI decorates. Your job is to inform." Each default is decoration sitting where information should be. Emoji replace a real icon set. Bright accents replace color that encodes status.
He also says the tool optimizes for a screen that looks finished. My reading of why, which is inference and not something he demonstrates: a model generating a screen has no user and no task in front of it, so visual completeness is the only success signal it has. It fills the space.
Failures that repeat as patterns are what checklists are good at. Linters exist for the same reason.
The failure classes and what to check
This is my condensed version of his list, regrouped by what I would look for.
| Failure class | What to check | Where to look |
|---|---|---|
| Emoji used as icons | One icon library, used at one weight and one size | Package manifest, imports |
| Default palette | A restrained base and one accent, with color reserved for data and status | Theme tokens, button styles |
| Repetition across pages | The same stat component on several routes; whether each page can name the one question it answers | Route files |
| Everything at equal weight | Rows that show every button, chip and timestamp at once | Component markup, then the rendered screen |
| Missing states | Empty, loading and error states on async paths; long names, nulls and very long lists | Async call sites, test data |
| Silent destructive actions | A confirmation that names the consequence, then a visible completion state | Delete handlers |
| Drifting conventions | Delete on one screen and Remove on another; whether a rules file exists | String search, repo root |
Two rows deserve more than a cell.
Repetition is what Rosewell calls the clearest tell. The tool puts the same stat cards on the dashboard, the analytics page and the billing page because it has no memory of what it already built. His remedy is a question per page: what did someone come here for? Anything that does not serve the answer gets deleted. That step is free and needs no design judgment.
Equal weight is where he says the least work buys the most visible change. Collapse the row of buttons into a single menu, turn text chips into icons, mute the date, and push the one number that matters to the right.
Run it after generation, mostly against source
What makes this list useful to me is something Rosewell does not emphasize, since he presents everything visually. Most rows can be answered by reading the repository. Is there an icon library in the manifest? Do three routes import the same stat component? Does every async call have a pending state? Those are yes-or-no questions. A person can answer them without design vocabulary, and I expect an agent can answer most of them about its own output.
That is why I call it mechanical. A prompt asks the model to have better judgment up front. An audit asks whether specific things exist afterward.
One item on the list prevents drift instead of repairing it, and that is the rules file. Rosewell's version is a single page covering text sizes, button heights, spacing steps and the verbs used for actions, pasted into the tool's rules file so later generations obey it. Every other fix is a one-time repair that the next generation can undo.
This is the design-specific case of something I already rely on. My vault routes agents through a CLAUDE.md at the root and a CONTEXT.md in each folder. Consistency comes from the files an agent reads before it generates, not from effort spent on each prompt.
Where the checklist stops
Rosewell opens by saying taste is not required. He closes by saying the taste is in choosing a reference: screenshot an interface that already does the job and hand it to the agent. Both statements cannot be fully true. My reading is that the checklist reliably moves output from bad to inoffensive. Getting from inoffensive to good still takes a judgment, and he has moved that judgment to reference selection without removing it.
The evidence is weaker than the checklist. He states that about 88 percent of users abandon an app after one poor experience, and that a one-second delay costs about 7 percent of conversions. Neither figure comes with a citation. The video ends in a pitch for his paid playbook, and several of the examples he holds up as good design are his own products. The individual items are conventional UI practice and I would use them. The claim that these decisions drive revenue is asserted, not shown.
There is also a gap. Accessibility never comes up. Muted chrome, thin borders and near-white backgrounds are the palette direction most likely to fail a contrast check. If I adopt the palette row I am adding a contrast row beside it, along with focus states and keyboard navigation.
Key Takeaways
- Generated UI fails in repeated patterns, and repeated patterns can be audited without taste.
- Most of the audit is checkable against source: dependencies, component reuse across routes, pending states, confirmations, a rules file.
- The rules file is the only item that prevents the problem. The rest are repairs the next generation can undo.
- The checklist raises the floor. It does not make a design good, and it leaves out accessibility.
Sources
Open question: how many of these rows can an agent check on its own output before a person has to look at the screen?