De-vibe your product

Why “make it prettier” makes it worse

QYou’ve asked your agent to improve the design three times. Why does it look different every time and better none of them?

Because you’re not directing — you’re re-rolling. An agent session starts with no memory of the last one and no rules to obey, so “make it look better” means improvise a new taste from scratch. You get a new accent color, a new button shape, a new opinion — different, not better, and each roll adds to the pile of half-styles that made it look vibe-coded in the first place.

I run design through agents every day — the full system is documented in the pipeline essay — and the whole trick compresses to one move: never ask for taste; ask for decisions, written down, then applied. Audit what improvisation produced, decide each value once, write the decisions in a file the agent reads every session, sweep the codebase to match, and check with tests you don’t need a design degree to run. That is the entire guide. Three passes: the bones, the surface, the words.

Insight: This is also the cost trick: written rules are what let a cheap model perform. Every prompt here is built to run on a mid-tier model — a mid-tier model with written rules beats a frontier model improvising.

What you need

Two tools, and the cheap tier of both. First, an agent that can see and edit your whole project— Claude Code (Sonnet is enough), Codex CLI, or Cursor; whichever you already have is the right one. If you built on Lovable, v0, Bolt, or Replit, their built-in agent does the job: the rules file from pass two goes into the project’s instructions box instead of the repo root. Second, a chat model that can see images, for the screenshot critiques — the cheapest tier with vision is fine.

Budget a weekend, and take screenshots of your five most important screens before you start. You’ll want the before pictures — partly to check progress, mostly because the difference is the payoff.

One step in this guide is worth a stronger model: the “decide once” session in pass two, because it is the only step that is judgment rather than mechanics. Spend there if you want to spend anywhere. Everything else — audits, sweeps, states, rewrites — is precise, mechanical work that a mid-tier model does better per dollar.

The weekend needs only those two. What keeps the result consistent as you grow is the supporting cast, and each earns its seat the moment a second surface appears: Figma as the visual source of truth — even one page of your components beats none; GitHub as the memory, so the rules file lives beside the code and every version keeps its reason; Notion or any shared page for the decisions your next session reads; one motion engine — GSAP or Motion — reading one duration token instead of ad-hoc CSS scattered everywhere; and Remotion when brand video should come from the same system as the product, which is its own essay. This is the skeleton of a real design system, and it is how the same rules file ends up governing your app, your site, and your launch video at once.

Pass 1: the bones

Styling a page with the wrong structure is polishing the wrong thing, so structure goes first. Vibe-coded sites over-generate: the model has seen a million landing pages, so you get all of their sections at once — two feature grids, a stats strip with invented numbers, a “why choose us”, two CTA banners. Nine sections saying three things.

Start with an inventory, then run every section through the one-job test. Write one sentence per page — this page exists to ______ — and hand it over:

Here is each page's one job: [paste].
For every section, tell me whether it serves that job,
duplicates another section, or serves no job.
Recommend cut, merge, or keep - one reason each.
Do not redesign anything yet.

Expect pages to get shorter — cutting is the win here. Then two rules that finish the pass. Borrow boring bones: structure is a solved problem, so a landing page runs hero (what it is, who it’s for, one proof) → how it works → evidence → pricing → one CTA repeated, and your novelty budget gets spent on content, never on structure. Order is an argument: sections run in the order a skeptic asks questions — what is this, is it for me, does it work, what does it cost, how do I start. A section that answers none of those is decoration.

Insight: The one-job test is the structural version of everything that follows: you are not asking the agent to be creative, you are asking it to hold each piece against a criterion you wrote down.

Pass 2 starts with a count

Before touching a single style, make the agent count what six months of improvisation produced:

Scan the entire codebase and count every distinct value
in use for: text colors, background colors, font sizes,
font weights, spacing values, border radii, shadows, and
button styles. Output a table: category / distinct values /
the values themselves / where each appears.
Count, do not fix.

The table is the motivator. Twenty-three grays. Eleven font sizes. Four button styles. None of them wrong exactly, none of them chosen — each one is a session that needed a value and invented one, because nothing told it the value already existed. You cannot see “inconsistent” by looking; you can see 23.

Then the one judgment step of the whole guide: decide once. Collapse each list to a closed set — one accent, a neutral ramp of at most six steps, four spacing values, two radii, three text sizes, one or two fonts. Three shortcuts make this safe without a design degree: steal proportions from a product you admire, never its look; when unsure, pick the quieter option; and one accent means one — if two things are accent-colored, neither reads as the action.

Write it down, once

The decisions go in one file — design-rules.md in the repo root, or the platform’s instructions box — and every future session reads it before touching UI. One page is the right length: a page gets read, a binder gets skipped. Three blocks: the sets (the closed lists you just chose — never add values, only use them), five lines of judgment (one primary action per screen and only it wears the accent; when two options work, ship the quieter one), and the never-list — no raw values outside the sets, no new fonts or radii, and the motion and copy bans from the next sections.

This file is the entire mechanism. It is why the tenth screen will match the first, why corrections stop repeating, and why the cheap model stops improvising — the context it was missing now travels with every session. The full template is in the download at the end.

Insight: The test of every line you write: a stranger with no context could follow it and produce work you’d keep. An agent session is that stranger, every single time.

Sweep, one family at a time

Now apply — but never as one big “restyle everything,” which produces a diff too large to check and mistakes you find weeks later. One family per session: colors, then spacing, then type, then components.

Read design-rules.md. Sweep the codebase for COLOR only:
replace every value with its mapped replacement from the
sets. Change nothing else. Then list every file you
touched and any value you could not map.

The “change nothing else” line is load-bearing — it is what keeps each diff small enough to actually review, and the could-not-map list catches the stragglers instead of letting the agent guess. The components sweep is the same move at a higher level: one button recipe, one card recipe, defined once, reused everywhere.

When all four families are swept, re-run the audit from the previous step. Watching 23 grays become 6 is the most satisfying moment of the weekend, and it is also your proof — the numbers are the receipt that the product now matches a set of decisions instead of a pile of rolls.

The one-thing pass

Consistency makes a product clean; hierarchy makes it look designed. The rule fits in a sentence: per screen, one thing is loudest, and it is the thing you want done. Vibe-coded screens fail this constantly — a discount banner, a “New!” badge and a logo all shouting while the actual call to action sits in gray.

Name the one action per screen, then have the agent demote everything else by one step — secondary actions lose the accent, decoration loses contrast. Then run the check that replaces a trained eye. Paste a screenshot into your vision chat model and ask:

List the three visually loudest elements in this
screenshot, in order. Then tell me where the eye lands
first, second, and third.

If the model’s answer isn’t your primary action, fix and re-run until it is. A fresh model with no context is a decent proxy for a first-time visitor — it reports what is actually loud, not what you meant to be loud. The human version costs nothing: squint at the screen until it blurs. Whatever survives the blur is your hierarchy, whether you chose it or not.

While you’re here, have the agent enumerate the states nobody generated — empty, loading, error, focus — and build the missing ones inside the rules file. A product is judged in its worst state, and vibe-coded products ship with placeholder text in theirs.

De-vibe the motion

Motion is where vibe-coded products out themselves fastest, because the models all reach for the same four tricks: floating gradient blobs, typewriter headlines, cards that tilt on hover, and everything fading up on scroll. Each one is a tell — decoration that reports nothing — and the last one is self-defeating on top: if everything animates, nothing reads as important.

The replacement rule is small enough to go in the rules file verbatim: one duration (around 200ms), one easing, entrances only — motion exists to report that something arrived, left, or is working. Nothing loops, nothing floats, nothing moves to be admired. Delete the four tells, apply the one rule, and the product instantly reads a year more mature — calm is the tell of designed software the way blobs are the tell of generated software.

Pass 3: de-AI the words

The words are the last tell, and the most fixable. You know the voice: Unleash. Seamless. Elevate. Empower. Emoji bullets, exclamation marks, “in today’s fast-paced world,” and benefits so generic any product could claim them. Ban the words in the rules file — the list is in the download — and add one voice line: we sound ____, ____, and ____; we never sound ____. Three adjectives you’d use for a person, one you’d fire them for.

Then run every page through the test that does the real work:

Rewrite this page's copy saying only things that are
specifically true of THIS product. Test every sentence:
if it could sit unchanged on a competitor's site, cut it
or replace it with something only we can say - a number
with a unit, a concrete object, a real constraint.
Follow the voice line and banned list in design-rules.md.

“Unleash seamless productivity” dies under this test. “Send an invoice from your phone in 30 seconds” survives, because no competitor can paste it. Specificity is the entire difference between copy that sounds generated and copy that sounds like someone who knows the product — which, conveniently, is also the copy that converts.

Insight: Notice that all three passes are the same move at different altitudes: hold the work against a written criterion — a job, a set, a voice — instead of asking the model to have taste.

Take it, and keep it

Two habits keep the weekend from unwinding: every future session starts by reading the rules file, and every correction you find yourself making twice becomes a new rule line the same day. Re-run the audit monthly — the counts creeping back up means a decision is leaking out of the file. That’s the whole maintenance plan; it fits on an index card.

And the honest limit: this pass gets you to clean and credible — consistent values, real hierarchy, states that exist, copy that sounds human. It does not get you to distinctive. That last mile is taste, and taste is a person. But credible is what converts, and credible is a weekend.

Everything above as one file — the tool menu, all the prompts, the rules-file template, the banned lists, and the done-when checks for each pass. Hand it to whichever agent you already have.