Shipping AI-generated UI safely
Agents write front-end code faster than anyone can look at it, and they cannot see what they built. What that changes about review, what breaks differently, and how to keep velocity without shipping broken screens.
The constraint on front-end delivery used to be writing the code. It is not any more. An agent will restyle forty components while you read this paragraph, and the work is often good. The constraint moved to the step that did not get faster: somebody looking at the result.
That is not a complaint about AI-written code. It is an observation about throughput. Code generation scaled by an order of magnitude; visual review scaled by zero, because it is still one human opening a browser.
The asymmetry, stated plainly
| Step | Before agents | Now |
|---|---|---|
| Writing a UI change | Hours | Minutes |
| Running the test suite | Minutes | Minutes |
| Looking at the result | Minutes | Minutes — unchanged |
| Changes per engineer per week | A handful | Many |
Every row held constant except the two that matter. The result is that the informal safety net most teams relied on — someone will notice if it looks wrong — quietly stopped working, because the ratio of changes to eyeballs changed underneath it.
How agent-written UI breaks differently
The failure modes are not new. Their distribution is, and that distribution is what makes them slip through.
- Confident, plausible CSS. An agent produces a value that is locally correct and breaks a layout three routes away. It has no way to check, because it cannot see.
- Wide blast radius by default. "Update the design tokens" is one instruction and forty files. A human doing that change knows which screens are fragile; an agent does not know they exist.
- No memory of past decisions. Ask an agent to resolve a visual diff and it may cheerfully revert a deliberate change someone approved last week, because nothing recorded that the decision was made.
- Volume defeats review. Ten diffs get read. A hundred get skimmed. This is the mechanism by which a green pipeline stops meaning anything.
The specific defects are the ordinary ones — overflow, stacking, fallback fonts, broken empty states. Common visual bugs catalogues them. What is new is that nobody is looking.
Why your test suite does not help
It is worth being blunt about this, because "the tests pass" is doing a lot of unearned reassurance in most teams right now.
Unit, integration and end-to-end tests assert on behaviour and the DOM. A submit button rendered white-on-white, positioned off-screen, or covered by a cookie banner satisfies every one of them. An agent optimising to make tests pass will happily produce that button, because by the only signal available to it, the button is correct.
What actually works
1. Make the visual result machine-readable
An agent cannot see a screenshot, but it can act on a structured description of what changed: which route, how much, against which baseline. That turns visual review into a feedback loop it can close by itself for the obvious cases, leaving humans the judgement calls.
2. Record why a change was approved
One line, when you accept a visual change, saying why. This is the cheapest high-value habit available and almost nobody does it. Without it every approval is an undocumented decision, and the next agent has no way to distinguish intended from regression nobody caught.
3. Check the blast radius, not the diff
When an agent changes a shared component, whether that component changed is not the question — obviously it did. The question is which other forty routes changed with it. Change-impact mapping matters much more when the author cannot reason about what their edit touched.
4. Keep determinism strict
Agent loops amplify flake badly. A human seeing one spurious diff shrugs and moves on. An agent may spend four turns confidently "fixing" a late-loading font, and each turn is another change you now have to review. Everything in fixing flaky visual tests matters more here, not less.
5. Keep approval human
Generation can be automated. Verification can be automated. Acceptance should not be. Approving a baseline is the moment a change becomes permanent, including a regression, and that is a judgement about intent that nothing in the pipeline has access to.
The workable loop
- Agent makes a change, opens a pull request.
- Visual check runs on the routes that change can affect — not everything, or review volume defeats you again.
- Results return as structured data: route, diff magnitude, baseline, current.
- The agent gets the approved baseline and prior review notes for those routes as context.
- It fixes what it broke, or explains why the change is intended.
- A human approves. Always.
Tooling for this is young and moving — visual testing for AI coding agents covers what exists. The requirement will outlast whatever ships this year: something has to look at the screen, and the thing writing the code cannot.
The honest version for a leadership conversation
Not "AI writes bad UI" — that is both contentious and mostly untrue. The defensible framing is a throughput mismatch:
We increased front-end change volume substantially and did not increase visual review capacity at all. The informal check — somebody notices if it looks wrong — was load-bearing, and it does not scale to this volume.
That is a capacity argument rather than a quality complaint, it is measurable from your own pull request data, and it does not require anyone to agree that agents are bad at CSS.
Frequently asked questions
Is AI-generated UI code less reliable?
The code is often fine. The problem is throughput: agents produce front-end changes far faster than teams review them, and an agent cannot see what it rendered. The informal safety net — somebody noticing if a page looks wrong — stopped scaling once change volume rose, which is a capacity problem rather than a code-quality one.
Should AI agents be allowed to approve visual test baselines?
No. An agent with access to a snapshot-update flag can turn any failing visual suite green by accepting whatever it just produced, then report success. That removes your regression detection while telling you the opposite. Keep baseline approval out of agent-accessible scripts and make baseline changes visible in review.
How do you review UI changes written by an AI agent?
Run visual checks on the routes the change can affect, return results as structured data the agent can read, give it the approved baseline and any prior review notes so it does not undo earlier decisions, and keep final baseline approval as a human step.