Back-office is where AI-built UI belongs first

The "can AI build the front end" argument is always fought over the wrong example. Someone points at a consumer product — a distinctive visual identity, an interaction with no prior art, motion design, the long tail of polish that separates "fine" from "feels expensive" — and concludes the models are not there. On that example they are right. Point the same tools at an internal admin tool and the answer flips. If you want to adopt agent-assisted UI work seriously, back-office is where it already pays, and where being wrong costs a Jira ticket instead of a customer.

The debate uses the wrong test case#

Consumer front-end is precisely where models struggle, and back-office is the inverse on every axis that matters.

Five things that make back-office the right place#

1. The work is repetitive and templated

The fortieth list-plus-detail-plus-form is eighty per cent the thirty-ninth. That is exactly the work an agent does well, and exactly the work that bores a senior engineer into copy-paste mistakes. The variation that matters — which fields, which filters, which permissions, which bulk actions — is small, structured, and mostly derivable from the contract.

2. A design system makes the output good by construction

This is the load-bearing point, and the reason this post has a companion on building the system itself. If the agent may only compose from <DataTable>, <Field>, <FormGrid> and semantic tokens, the output is consistent whether a person or a model assembled it. Without a system, the agent invents spacing, picks hex colours, hand-rolls a table, and you review pixels forever. That failure is not the model — it is a missing constraint.

The design system is the guardrail that turns "generate a screen" from a slop risk into filling in a template.

3. The spec already exists

API contract plus data model plus permission model is most of the requirement for a CRUD screen. Hand the agent the OpenAPI or Zod schema: generate the types, then the column definitions derived from the response shape, then the form from the write schema. The capabilities flags from the contract become the disabled and hidden logic on row actions. A .http file that already proves the feature is also the agent's acceptance test.

4. The audience is forgiving and the blast radius is small

Internal staff tolerate a rough edge and tell you about it; customers leave without a word. A v1 that is ninety per cent right is fine and cheap to finish. There is no SEO, no marketing screenshot, no app-store review, no viral "look at this broken checkout".

5. Volume amortises the setup

Writing the scaffolding — a skill describing the system, evals that check compliance, a workflow document, a reference screen — is real work. It pays back when you are generating screens weekly, which is exactly the back-office cadence. This is the applied case for turning ad-hoc prompting into a repeatable workflow.

What still needs a human#

• The design system itself — the primitives, the tokens, the interaction patterns, the density calls. Humans build the vocabulary; the agent writes sentences in it.
• Novel interactions — a new bulk-edit paradigm, a bespoke scheduling or timeline view, anything with no pattern in the library. Recognising "this one is actually new" is a judgement call.
• The contract review — if the API shape is wrong the screen is wrong, and the agent will cheerfully build on a bad contract instead of pushing back the way a person should.
• Accessibility verification — the keyboard path, focus order, a screen-reader pass. A number is not an audit.
• Data-scale performance — the agent writes the naive client-side .filter() over every row; the fifty-thousand-row reality needs server paging and virtualisation, which is a deliberate decision.
• Deciding what not to build — the screen that should not exist, the three-step flow that should be one, the report nobody reads. Agents do not say no.

How to set it up#

1. Encode the system as agent context: a skill or document with each component's API, worked examples, and hard rules — compose from primitives, never restyle; no raw hex or px; every tabular view is <DataTable>; labels visible, never placeholder-as-label.
2. Feed the schema as the spec: generate types first, then derive column definitions and form fields from the response and write shapes.
3. Give it a reference implementation: one hand-built, exemplary screen to imitate. A template beats a paragraph of instructions.
4. Add evals for the machine-checkable rules — the set below.
5. Set the review posture: read the contract mapping and the accessibility closely; skim the rest. The diff size lies — four hundred lines of generated column definitions and JSX is not four hundred decisions.
6. Keep a screen catalogue: as generated screens land they become the next reference set, and the agent's output converges on the house style.

# evals — the machine-checkable rules
✓ no raw hex / rgb / px in the diff — tokens only
✓ every tabular view uses <DataTable>, not <table>
✓ form fields use <Field>; no placeholder-as-label
✓ row actions read capabilities.* from the response, not client-side role checks
✓ loading / empty / no-results / error states all present
✓ axe: 0 serious or critical violations
✓ the feature's .http checks still pass against the mock

The honest bill#

• Setup is not free — the skill, the evals, the reference screen, the review time, the token spend. It is negative return on screen one and clearly positive by screen ten.
• Consistency cuts both ways: an agent subtly wrong about focus management is subtly wrong the same way forty times. Evals catch the mechanical errors; the systematic-taste ones need a human spot-check across a batch, not per-PR.
• Ownership does not transfer. When a generated screen breaks at 2am, a person has to understand code they did not write — so keep the output boring and close to the template, precisely so that is easy.
• Skill atrophy is real for juniors who only ever assemble via an agent. The system team and the hard screens are where that experience still has to be earned.

The checklist#

1. There is a real design system and the agent may only compose from it.
2. The API contract is settled and reviewed by a human before a screen is generated.
3. The agent gets the schema as spec and a hand-built reference screen to imitate.
4. Evals check the mechanical rules: tokens only, <DataTable>, <Field>, capability-driven actions, all four table states, axe clean, .http checks pass.
5. Human review concentrates on the contract mapping and accessibility, not line count.
6. Accessibility is audited for real, not scored.
7. Data-scale performance — paging, virtualisation — is a deliberate human decision.
8. Someone owns each generated screen for the incident case.