DEV Community

𝗝𝗼𝗡𝗻
𝗝𝗼𝗡𝗻

Posted on

AI Can Build Your UI β€” But Can It Maintain It?

#webdev #ai #productivity #frontend

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

AI can build a surprisingly convincing UI in a few minutes.

That is useful. It is also dangerous in the same way a good mockup is dangerous: it can look finished before the engineering decisions are finished.

The question is no longer whether AI can generate components.

The better question is:

Can your team maintain what AI generated six months from now?

Generated UI has a smell

AI-generated frontend often looks impressive at first glance and strange on review.

Common signs:

  • duplicated components,
  • inconsistent spacing,
  • random animation choices,
  • inaccessible markup,
  • weak loading and error states,
  • hard-coded colors,
  • unclear state ownership,
  • no component contract,
  • tests that only prove rendering happened.

None of this means the tool is bad. It means the output needs engineering.

Give AI constraints, not vibes

Bad prompt:

Build a beautiful dashboard.
Enter fullscreen mode Exit fullscreen mode

Better prompt:

Build a dashboard page using our existing Card, Button, Badge, and Table components.
Use semantic HTML. Include loading, empty, and error states.
Do not introduce new colors outside the design tokens.
Keep state local unless it is shared by more than one component.
Add keyboard-accessible interactions.
Return the component and a short review checklist.
Enter fullscreen mode Exit fullscreen mode

AI is much more useful when you give it boundaries.

Ask for states, not just screens

A screen is not a component.

A component has states:

loading
empty
success
error
permission denied
partial data
saving
saved
validation failed
Enter fullscreen mode Exit fullscreen mode

If the generated UI only includes the happy path, it is not ready for production.

Require component contracts

Before accepting generated UI, define the contract:

type InvoiceTableProps = {
  invoices: InvoiceSummary[];
  status: "loading" | "empty" | "ready" | "error";
  onRetry?: () => void;
  onOpenInvoice: (invoiceId: InvoiceId) => void;
};
Enter fullscreen mode Exit fullscreen mode

This forces the component to have a clear boundary.

Without a contract, generated UI tends to reach outward: global state, random fetches, hidden assumptions, and props that grow without discipline.

Keep design tokens non-negotiable

AI loves inventing colors.

Do not let it.

:root {
  --color-bg: #0b1020;
  --color-surface: #121a2f;
  --color-text: #f8fafc;
  --color-muted: #94a3b8;
  --color-accent: #22c55e;
}
Enter fullscreen mode Exit fullscreen mode

Tell the tool:

Use only existing design tokens. Do not invent new hex colors, spacing values, shadows, or font sizes unless explicitly requested.
Enter fullscreen mode Exit fullscreen mode

Consistency is not decoration. It is maintainability.

Make accessibility part of the prompt

Do not ask for accessibility after the component is generated.

Include it at the start:

Use semantic HTML.
All interactive elements must be keyboard accessible.
Use visible focus states.
Do not use divs as buttons.
Connect form labels and error messages properly.
Avoid ARIA unless native HTML is not enough.
Enter fullscreen mode Exit fullscreen mode

This will not guarantee perfect accessibility, but it raises the floor.

Review generated UI like a pull request

Use this checklist:

## AI-generated UI review

- Does it use existing components and tokens?
- Are loading, empty, error, and permission states handled?
- Is the markup semantic?
- Is keyboard interaction supported?
- Are props explicit and typed?
- Is state owned by the right component?
- Are side effects isolated?
- Are tests meaningful?
- Is there duplicated logic?
- Could another developer safely change this later?
Enter fullscreen mode Exit fullscreen mode

The last question is the point.

Good uses of AI in frontend

AI is genuinely helpful for:

  • first drafts,
  • test scaffolding,
  • refactoring repetitive markup,
  • converting rough UI ideas into components,
  • writing stories for component states,
  • finding accessibility issues,
  • generating edge-case checklists,
  • explaining unfamiliar code.

It is less reliable for:

  • architecture boundaries,
  • product intent,
  • design consistency,
  • long-term ownership,
  • subtle accessibility behavior,
  • performance tradeoffs.

Use it where speed helps. Slow down where judgment matters.

Final thought

AI can generate UI. That is no longer the impressive part.

The impressive part is building a frontend system where generated code has to pass through the same standards as human-written code.

A fast draft is useful. A maintainable product is better.

Sources

Thanks for reading.

You can find me here:

Top comments (0)