Reviewing AI-generated UI: a checklist
Generated UI tends to fail in consistent ways: invented values outside the scale, missing states, absent accessibility attributes, and layouts that only hold at the width they were written for. A short checklist covering those catches most problems before review becomes a matter of taste.
Reviewing generated UI is disorienting at first because it does not fail the way hand-written code fails. There are no typos and no half-finished functions. It looks complete.
The failures are elsewhere, and they repeat. Which means a checklist works.
Values outside the system
Start here, because it is the most common and the easiest to miss by eye. Scan for spacing, colours, radii and font sizes that are not in your scales. A 14px gap where the scale has 12 and 16 reads as fine individually and as sloppy in aggregate.
And components used outside their context
A card nested in a card, a section that added its own page padding, a heading level that jumped from h2 to h4. Structurally valid, conventionally wrong.
The states nobody asked for
Ask for a table of orders and you get a table of orders. You do not get the empty state, the loading state, or what happens when the request fails — because you did not ask, and the model does not know those exist in your product.
This is the single largest gap in practice. Generated UI is almost always the happy path only.
Accessibility
Markup is often semantically reasonable and still missing the parts that make it usable: labels tied to inputs, focus visible, a button that is a button, alt text that says something, an icon-only control with an accessible name.
Much of this is mechanically checkable. Put it in CI rather than in a reviewer's head.
The two tests that find the rest
Make the window narrow. Then put a very long string in every text field — a product name of sixty characters, a customer with three surnames.
Between them these find most remaining layout faults: the row that does not wrap, the truncation that never arrives, the button that overflows its container. Both take under a minute and neither requires judgement.
Then look properly
With the mechanical faults gone, the remaining question is whether the interface is any good — whether the hierarchy is right, whether the primary action is obvious, whether it feels like the rest of the product.
That is the part worth human attention, and it is easier to give when you are not also hunting for a stray margin.
Frequently asked questions
Can the checklist be automated?
Partly, and that is where to start. Off-scale values, unknown class names and missing alt text are all mechanical checks. Whether the layout is actually good is not, and that is what the human attention is for.
Should generated UI be held to a higher standard?
The same standard, applied more systematically. The volume is higher and the failures are more predictable, so a checklist pays off faster than it would on hand-written code.
