A V2EX thread caught my eye this week: someone had vibe-coded a few apps and pages, leaned on skills like apple-design, and still ended up frustrated. Their words, roughly: the prototypes come out low, the interactions, the fonts, the styling all feel dated. The replies went straight to tooling — switch to a Claude account for design, buy a $20 account just to generate templates for Codex, try impeccable.style to rescue the aesthetics, or let Antigravity's Gemini spit out the HTML and tune from there. One person flatly said Codex is at least two years behind mainstream taste.
I think most of that advice is treating a symptom. The deeper problem isn't which model has better taste. It's the workflow. People ask an agent for a prototype, get a single flat mockup, judge it like a finished design, and then regenerate the whole thing when it misses. Every round throws away the last one. You never get to iterate — you only get to re-roll.
The real complaint is the artifact, not the model
A one-shot mockup is a dead end by construction. The spacing, the type scale, the color ramp, the border radii — they're all baked into one blob of output. If the headline feels heavy or the accent color reads cheap, you can't nudge it. You go back to the prompt and spin the wheel again, hoping the next generation keeps the three things you liked and fixes the one you didn't. It usually doesn't.
There's a better pattern hiding in another post on the same board. Someone building AI science videos described rewriting their pipeline so every stage is a canvas: the agent edits files in a workspace, you watch the result and keep giving feedback, and you only lock a stage once it looks right. They also kept a snapshot per round so they could diff and roll back. Different domain, same insight — stop generating finished artifacts, start editing a living one.
Apply that to UI and the shape of the solution falls out. You want a live hosted prototype where the agent writes real HTML, where all the styling is driven by an editable token layer you control, and where you produce variants in the browser instead of regenerating a static image every time.
What to actually build on VicroCode
Here's the version I'd put together, mapped to what the platform can actually do.
Start with the prototype itself as a plain HTML page you run HTML online and host directly. No build step, no local toolchain, no screenshot-and-compare loop. The agent writes semantic HTML and references styling through CSS custom properties — things like `--color-accent`, `--font-heading`, `--radius-card`, `--space-unit`. The markup stays stable. The look lives entirely in those variables.
Then separate the tokens from the page. Put them in a SQLite table: token name, value, group, and a note on intent. This is the swappable design-token layer. You edit values in the SQLite editor, and a small Python backend reads the active token set and renders them into a `:root` block the page pulls in. Change the accent from a flat blue to a warmer tone, bump the base spacing unit, swap the heading font stack — reload, and the whole prototype re-skins. You're not re-prompting the model to redo a mockup. You're turning dials on something that already exists.
Variants become rows, not regenerations. Keep a `theme` column or a second table of named token sets — "calm", "dense", "high-contrast" — and let the page take a query parameter to pick one. Now comparing directions is loading two tabs, not generating two images and squinting. That snapshot-and-rollback idea from the video workbench maps cleanly here too: before an agent edit, copy the current token set to a history table so you can always get back to the version you liked.
The agent stays in the loop through the structural work, not the taste work. You use AI coding to have it build out new components, restructure layout, wire up states — the parts where it's genuinely strong. The styling decisions you keep in the token table, where they're legible, diffable, and yours. That division is the point. The model is good at producing HTML scaffolding and bad at being trusted with every pixel of visual judgment in one pass, so you give it the first job and keep the second.
If you want the token layer editable from outside the database view, host a tiny endpoint that reads and writes the table, and drive it from a small control panel on the page. Same backend, just exposed as an in-platform API instead of manual edits. One caution worth stating plainly: if you put that write endpoint on a hosted prototype, anyone with the link can change your tokens unless you add some form of access control. For a private design exploration that may be fine; for anything shared, gate it.
Where the boundary is
Two honest limits. First, this doesn't make a specific model's default aesthetic better — the thread's complaints about one tool's taste are about that tool, and swapping the underlying model is only possible for models already available through the platform's Model Center. The workbench's value is that it stops you depending on one-shot taste at all. Second, whether this actually produces nicer prototypes faster for you is unverified; it's a workflow I'm describing from how the pieces fit, not a measured result I can point to.
What I'm fairly confident about is the structural claim. The frustration in that thread isn't really "the AI has bad taste." It's "I keep judging a flat mockup I can't edit." Move the styling into tokens, keep the HTML live and hosted, and iterate in the browser — and the question changes from "regenerate until it's good" to "adjust until it's right." That's a workflow you can keep improving, and once it works for one page you can publish it as a reusable starter and share or monetize it the same way you would any other project.