log 0002: turning taste into constraints agents can follow

“make it feel nostalgic” is not an executable brief. hand that sentence to an ai coding agent and you get the median of everything it has ever seen: gradients, rounded cards, confetti. this note is the method i used to turn a pinterest board of aesthetic feelings into constraints that the agents building this site (claude, hermes, codex) can actually follow.

the problem

taste is implicit. agents flatten implicit things. a moodboard communicates perfectly to a human designer and almost not at all to a model that needs to make four hundred small decisions about padding and color without you in the room.

the method

three moves, in order:

1. make the source concrete. the board got analyzed pin by pin, and the dominant colors were sampled from the actual images instead of described from memory: #fbf9ed cream, #6b84b8 riso blue, #a89b5f halftone gold. an adjective drifts; a hex does not.
2. write refusals, not just rules. the strongest lines in the resulting canon are the negative ones: no glossy gradients, no boxes (whitespace does the structure), one effect per surface, no stock imagery, no em dashes. a refusal is testable. “warm and nostalgic” is not.
3. put the canon where agents must read it. one canonical design doc in a shared knowledge vault that every agent reads before touching ui code, plus css tokens in the repo. the agent does not remember taste; it retrieves it.

the control

the canon existed before this site did. every ui change gets reviewed against written rules instead of vibes, and when review finds a gap, the fix becomes a new rule and goes back into the canon. receipts from this site’s own build:

• the first plot layout used bordered grid cells. human review called it what it was (it was giving highschool). the refusal “no boxes” got written down, and the rework took an hour because the target was explicit.
• the site mascot took three attempts before landing. the canon now records which form won and why, so no agent resurrects the rejected ones.
• em dashes were banned mid-build. the ban was enforceable with a grep, which is exactly what makes a written refusal different from a preference.

the limit

a written canon reduces drift; it does not prove visual quality. every correction above was caught by a human looking at the rendered page, not by the rules. the canon made each fix fast and durable. it did not make the human unnecessary, and it should not.

takeaway

before delegating ui work to agents: sample your references into hexes and type rules; write refusals, not just preferences; store the canon somewhere agents are required to read it; keep a human review loop that feeds new rules back in. taste in, constraints out, drift down.

(the digit flower on the homepage is what this method produced. its own story is a design note for another day.)

how do you encode taste for your agents? i actually want to know: send a rabbit hole.