Prototypes got cheap. Judgement didn't.

A year ago, the expensive part of a prototype was making it. Today I can describe a screen to an agent and have five working variants before my coffee is cold. Cursor, Claude Code, v0 and Lovable have collapsed the cost of a first draft to almost nothing.

The cost of deciding which draft is right hasn't moved at all.

We still put the variants on a screen, gather the team, and argue. Someone notices the contrast is off. Someone else doesn't like the button copy. The most senior person in the room says it feels busy, and that settles it. Then the agent makes six more variants overnight and we do it again.

I think this gap, between how fast we can make things and how slowly we can judge them, is the most important problem in product design right now. And I think the AI industry has already shown us how to close it.

The industry learned this lesson first

Model builders hit the same wall a few years before we did. Once training a model became routine, the hard question stopped being can we build it? and became is this version better than the last one, and how would we know?

Their answer was evals. An eval is a written-down definition of good, turned into something you can run. A set of questions with known answers. A rubric a grader can apply. A test that fails loudly when a new version gets worse at something the old one did well.

Evals changed the culture of those teams more than any single technique. Debates about whether a model felt smarter turned into conversations about which evals moved and why. Nobody ships a serious model now without them. When a lab announces a release, the first thing anyone looks at is the eval table.

Design has no eval table. We have design reviews, which are evals run by hand, by whoever is in the room, against criteria nobody wrote down.

Why reviews don't scale

Design review worked when prototypes were scarce. If a designer spent a week on a flow, an hour of senior attention on it was a reasonable ratio. The review was slow, but so was everything else.

That ratio has broken. When an agent produces variants faster than people can look at them, three things happen:

• Review becomes the bottleneck. The team's throughput is now capped by how many screens a senior designer can look at in a day.
• Standards drift. Each review applies whatever the reviewer happens to notice that afternoon. The same issue passes on Tuesday and fails on Thursday.
• The agent never learns. Feedback lives in a meeting, a Figma comment or a Slack thread. The thing generating the next variant never sees it.

The last one is the real cost. We have built a production line where the machine that makes the work and the people who judge it don't share a language.

What a design eval looks like

A design eval is the same idea as a model eval, pointed at an interface. You write down what good looks like as rules, you run those rules against a real prototype, and you get a verdict per rule.

Some rules are pure measurement. Body text has at least 4.5:1 contrast is a number, and a browser can check it on every element on the page in a fraction of a second. Tap targets are at least 24 by 24 pixels is the same. These should never go near a meeting.

Some rules need judgement. The headline says what the product does and for whom can't be measured with a ruler, but it can be judged consistently, by a person or a model, if the rule is written clearly.

And some rules are yours alone. One primary action per screen. We never say 'Get started'. Prices always show the currency. These are the things your best designer says in every review. Written down, they stop depending on that designer being in the room.

Once the rules exist, two things become possible that weren't before. You can score every prototype against the same standard, so comparing variants becomes a conversation about evidence. And you can give the same rules to the agent before it builds, so the first draft is already aiming at the target.

The loop I want

This is why I've been building Glitterball. The loop is short:

1. Define the rules: accessibility, usability heuristics, the tells of generated design, and your own house rules.
2. Build with them. The coding agent reads the rules over MCP before it writes a line.
3. Judge the prototype in the browser. Measurable rules are checked in code. The rest are judged by a model built for decisions, not prose.
4. Fix by handing the failures straight back to the agent as specific instructions, then run it again.

The part I care about most is the last step. A review that ends in a list of opinions is a report. A review that ends in instructions the builder can act on is a loop. Loops are how you get better on purpose.

What this changes for designers

I don't think this replaces taste. I think it changes where taste gets applied.

Today, a senior designer's taste is spent one screen at a time, in review. In a world with design evals, that taste goes into the rules. Writing copy names concrete features, numbers or examples rather than abstract benefits takes ten minutes. It then applies to every screen the team and its agents produce, forever, without the designer in the room.

That is a very different job. It's closer to writing a style guide than running a crit, except that this style guide runs itself. I'll write more about what that means for design leaders later in this series.

What's next in this series

Over the next few pieces I want to work through the ideas underneath this:

• Why generated design all looks the same, and why that's measurable.
• What design can borrow from the way AI labs evaluate their models, and what it shouldn't.
• The difference between measuring and judging, and why mixing them up made my first version useless.
• Why design systems need to be written for agents as well as people.
• What the design leader's job becomes when the eval is the standard.

If you lead a design team and you've felt the review bottleneck, I'd like to hear how you're handling it. The fastest way to reach me is a reply wherever you found this.