Tracing AI's UI decisions

When an AI model builds a screen, most of it is fine. Then you spot a label nobody needed, the wrong font size, or a color token picked for its name rather than its role.

You can tell the model to fix it, and it will, once. The next screen has the same mistake, because nothing that produced it changed.

So when the model made a bad decision, I started asking it why, and followed the answer back to its source. It's a small habit, and it's the kind of systems thinking we need as more interfaces get built with AI.

The stronger fix, if you can afford it, is a stricter system. Models do better with prop-based components that only accept a fixed set of options. If text can only use the sizes in your type scale, there is no wrong font size to pick. The same goes for wrapping a plain div in a layout component. Polar's Building an LLM safe design system takes this all the way, down to checks that reject raw HTML before it's merged.

Not every team can work within constraints like that, though. When you can't make the wrong choice impossible, you have to make it unlikely.

Fixing the output

Correcting the output treats every mistake as new. You notice it, describe it, the model fixes it, and you wait for it to come back. Each fix depends on someone seeing the problem.

That holds up when the person reviewing is a designer. It falls apart when the person prompting is a teammate who isn't a designer. They may not know that 13px should have been the caption token, or they may read an extra label as helpful.

Asking why

A model's choices come from somewhere. It reads the instructions, components, and token names we give it, and builds a picture of what we want. When the picture is wrong, the bad output is a symptom.

When I saw a bad decision, I asked the model to explain it. The question can be as simple as: "Why did you use 13px here, and which rule, file, or example made that look right?" The answers were more useful than I expected. Often the reasoning was sound given what it had read, and the thing it read was the problem.

Fixing the source

Once you know where a decision came from, you can fix it at the source. Sometimes that means renaming a token or writing down what it is for. Other times it means adding the reason behind a rule, so the model can tell when the rule applies.

Each of these is a small change, and each one keeps helping after the conversation ends. It prevents the mistake on every future screen, for everyone who prompts for one.

The work also gets cheaper. The first few traces turned up a lot. Later ones turned up less, because the sources were getting cleaner.

Why this matters for the team

The goal is to let teammates who are not designers ship interfaces that look like a designer made them, without someone checking every screen. Reviewing harder won't get you there, since the reviewer is the bottleneck. What gets you there is making the right decision the easiest one for the model to reach.

Tracing is how you find out what makes the wrong one easy. That is the systems thinking this work asks for: improve what produces the interface, and every interface after it gets better too.