A test of taste.

What does a model choose on its own?

When you leave room in a brief, a model has to make choices: type, color, spacing, layout, and how people move through the interface. Some choices keep showing up. Others change with a little guidance.

This project started with a question about the design taste models pick up during training. How much of that comes through in their work? And what happens when you give them a design skill or ask for a less familiar direction?

The grid gives us something concrete to look at while asking those questions.

Same task. Different choices.

The shared briefs cover a city journal, weekend discovery, a team inbox, and a workshop site called Forma. Each asks for a usable frontend. The sites are static, with demo interactions and no live backend.

Each run starts in a fresh workspace. Vanilla uses the coding agent’s standard instructions without an added design skill. Skill variants include the selected skill’s files and supporting resources. Unrelated skills and extensions are kept out.

The setup is recorded with the result: model, coding agent, brief, skill, sample, and generation limits. Pi runs through Lunaroute; other models use Claude Code or Codex. Those agents can affect the output too.

Why four samples?

One attempt tells you what happened once. These four let you look at repetition and deliberate variation.

ABaseline A

A first attempt at the brief.

BBaseline B

A fresh attempt with the same instructions.

↗Alternative

A different direction, informed by summaries of A and B.

✳Whacky

An invitation to try a strange, playful organizing idea while keeping the interface usable.

Open the designs. Try them.

Choose a brief, then compare models down a column or skills across a row. Open the thumbnails to use the actual sites. Check mobile, try the controls, and use the side-by-side view to look closely.

Automated checks catch things such as broken interactions, overflow, and some accessibility problems. Passing them doesn’t make a design good. A failed run can also mean a provider or tool problem; inspect the result before drawing a conclusion about the model.

The stats page shows runtime, reported tokens, and turns. Compare matching tasks and settings, and check how much data each model has. Agents count work differently, so these numbers need context.

A few runs can only tell us so much.

The brief, assets, skill, agent, and chance all affect the result. A screenshot can hide a broken interaction. A shared photo can make two different layouts look alike. Four samples won’t establish a definitive ranking.

We can observe recurring design choices. We can’t trace a particular choice back to training data from these outputs alone. The useful question is what you notice across several comparable runs.