Codex kept rebuilding the same dashboard, so I changed what it sees before it codes
Prompting “make it less generic” was the wrong layer.
The workflow that finally held up for us was:
- Give the agent 3–5 real product screens before it touches the layout.
- Turn those references into a short design contract: hierarchy, density, spacing, component rules, and states.
- Let Codex build against that contract.
- Run a finish gate against the references before shipping, instead of asking the model whether its own work looks good.
The references matter more than another paragraph of adjectives. “Clean, modern, premium” leaves the model free to converge on the same card grid, sidebar, and purple accent it already knows.
I built UIZZE from this internal workflow: https://uizze.com. Founder disclosure: it’s my product. It searches 800,000+ real web and iOS screens and gives Codex reference evidence, a design contract, and the finish gate; Claude Code and Cursor work too.
What evidence do you give coding agents before asking them to make UI taste decisions?
The workflow is interesting because it shifts the problem from prompting to evidence. I'd keep validating whether developers adopt UIZZE because it helps them find design references, or because it gives coding agents a more reliable way to produce UI that meets human expectations.