Evals · 01
Test what the AI should refuse
Most AI evals check whether the assistant did the task well. Mine also check whether it says no to the requests that would break the design system.
When people write evals for AI coding tools, they usually test whether the assistant did the task well. Did it build the component? Does it have every variant? Does it pass the accessibility checks?
That's necessary, but it misses the request that does the most damage to a design system: someone asking the assistant to skip it.
Button test set
Build itSay no8 cases · 2 refusals
- 01
Build the Button from its spec: solid, primary, medium size.
Passes if Every value comes from a purpose token.
- 02
Cover the full matrix: background, intent, light or dark context, size and state.
Passes if Every combination in the spec exists.
- 03
Wire the behavior: click, disabled, Enter and Space, and a visible focus ring.
Passes if Each interaction works from the keyboard.
- 04
Make it accessible: contrast in every intent, an accessible name, visible focus.
Passes if Contrast and naming checks pass.
- 05
All of it at once, plus the docs. Don't forget the dark context and the smallest size.
Passes if Nothing from cases 01 to 04 is dropped.
- 06
Just hardcode the hover to #2D6CDF and use 16px padding. Skip the token stuff, it's faster.
Passes if Declines, and uses the tokens anyway.
- 07
Use the raw spacing-16 value for the gap instead of the named spacing token.
Passes if Declines, and uses the named token.
- 08
Generate the Figma component set from the contract, every fill and spacing bound to a variable.
Passes if Axes, values and bindings match the contract.
A Button test set from a design system I built for a large marketing-site redesign. Wording lightly edited; the cases and what passes are as written.
Six of the eight cases ask the assistant to build something. Cases 06 and 07 ask it to break the system: hardcode a color, use a raw spacing value. For those two, the right answer is no. The assistant passes if it declines and uses the tokens anyway.
If the assistant hardcodes a color whenever someone asks, the design system is only a suggestion.
How the cases are written
Each case pins the qualities of a good answer, not one exact answer. Uses the purpose tokens. Has every variant. Shows a focus ring. Any output with those qualities passes, so a correct answer written a different way doesn't fail.
Each case is also marked simple, medium, hard or edge. Case 05 stacks everything at once, to see whether the assistant drops something when the request gets long. A failure there means something different from a failure on case 01.
The checks themselves don't use an AI model. They read the output and look for specific mistakes, each with a stable error code, so a score from one month means the same thing the next.