Your AI Coder Can Build the UI. Who Decides What It Should Look Like?

Two years ago, "build a settings page with a sidebar, a form, and a danger zone" was most of an afternoon. Now it is a paragraph and a wait.

What has not changed is that somebody still has to decide what the settings page should look like. And because the implementation cost fell so far so fast, that decision is now the expensive part. It just does not feel expensive, because it looks like typing a sentence.

Two requests that read the same

Here are two prompts. They are asking for the same page.

One:

Build a settings page. Sections for profile, notifications, and billing.
Include a danger zone for account deletion. Make it clean and modern.

Two:

Build a settings page. Sections for profile, notifications, and billing.
Include a danger zone for account deletion.

Follow the project's design rules:
- Sections are separated by a hairline and 48px of space. No cards.
- Section headings are heading-md. Field labels are label. Help text is small.
- Inputs: surface fill, 1px hairline border, 6px radius, 40px tall.
- One primary action per view. Everything else is outline or text.
- The danger zone uses the error colour on its button only. The section
  itself is not red, not boxed, not shaded.
- Elevation is surface colour. No shadows.

The first gets you a page. Probably a decent one. Three cards with borders and shadows, each with a heading, inputs of some size, and a danger zone with a red border and a pale red background because that is what danger zones look like on average.

The second gets you your page, first try, and you can then ask for the billing page and get something that matches.

The difference is not prompt engineering. The second prompt contains eleven decisions. The first contains none.

Why "make it clean" cannot work

"Clean and modern" is not underspecified in the way that a vague function signature is underspecified. It is underspecified in a way that has no correct answer.

The agent has to emit specific values. A background colour. A font size for the h1. A gap between sections. Dozens of them. If you have not made those choices, it makes them, and with nothing to go on it picks whatever is most strongly associated with the words you used. Which is the same thing it picks for everyone else who uses those words.

So the output is not wrong. It is average, which in a design context reads as wrong.

The decisions do not go away

This is the part I find people resist, and I understand why. The promise of these tools is that you describe intent and get an implementation. For logic that mostly holds — "sort by date descending, newest first" is complete. For visual work it does not, because there is no equivalent of correct.

Somebody has to decide that your product is warm rather than cool. That it uses one accent rather than three. That it has sharp corners. Those are not implementation details that a sufficiently good model will eventually infer. They are the actual design work, and there are roughly a dozen of them for a small product.

The good news is that a dozen is not many, and once made they are reusable indefinitely.

What changed is the cost of applying them

Before, having a design system meant a designer produced screens, then a developer implemented them, screen by screen. The system existed mostly in the designer's head and in a Figma file, and translating it into code was ongoing labour.

Now, if the rules are written down somewhere the agent can read, applying them is free. Not cheaper. Free. The agent will follow eleven rules across forty pages without getting bored or forgetting rule seven on page thirty.

That is a genuinely new capability and it inverts where the effort goes. It used to be: decide once, implement forty times. Now it is: decide once, write it down once, and implementation is a side effect.

Which means the leverage has moved entirely to how well you make and record those dozen decisions.

The thing that actually breaks

The failure mode is not usually a bad first page. It is the fifth page.

You get the homepage right through iteration. Twenty minutes of "bigger", "less purple", "tighten that". It ends up good. Every one of those corrections lived in the conversation.

Then you ask for pricing, in a new session, and the agent has none of it. So the pricing page arrives at the original defaults and you correct it again, but not identically, because you are working from memory. Then settings. Then the dashboard.

Six pages in, each carries a different subset of your preferences, and the product looks like six people built it who never spoke. Nothing went wrong at any individual step. The decisions just had nowhere to live.

I have written about how that drift compounds and how to stop it separately, because it is a big enough problem on its own.

Where the decisions should live

In the repo. In a file the agent reads on every task, next to the code, in version control, reviewable in a pull request like anything else.

The format barely matters. Markdown works. What matters is that it states values and their roles, so primary: "#FF4F00" # the one accent, primary actions only rather than a bare hex, and that it includes the prohibitions. The negative rules do more work than people expect. "No gradients" and "elevation is surface colour, not shadow" will each change more about how a page looks than any single colour choice.

You can write that file yourself in an hour. If there is a site whose visual language already does what you want, DesignMD will read it and write the file for you: the real values, named by role. But the file being there is the whole point. Where it came from is a detail.

The uncomfortable bit

None of this removes taste from the loop. If you do not know what you want your product to look like, no file and no model will decide for you, and you will get the average of everything again.

What has changed is that taste now needs to be expressed exactly once, in writing, instead of continuously through review. That is a much better deal than we had. It is just a different job from the one people think they are signing up for when they ask an agent to build a page.