How to Clean Up a Vibe-Coded App Without a Rewrite

On this page7 sections

• Why a Redesign Beats a Rewrite
• Step 1: Tokens First, Always
• Step 2: Consolidate the Components
• Step 3: Design the States Nobody Generated
• Step 4: Re-Rank Every Screen's Hierarchy
• Step 5: Make Your AI Tools Apply It
• What to Fix First If You Only Have a Week

To clean up a vibe-coded app, keep the working code and replace the default-looking interface with one design system. Work in this order: tokens, then components, then states, then hierarchy. Then have your AI tools apply the system to every screen. Done in that order, the redesign compounds. Restyling screen by screen never ends.

This matters to more founders every month. Tools like Claude Code, Codex, Cursor, Lovable, Bolt and v0 are extraordinary at getting a functional product live in days. They are also consistent in what they leave behind: fourteen shades of gray, three button styles that almost match, spacing that changes per screen, and empty states nobody designed. In our study of 832 websites, 40% of Lovable-built apps carried at least three of five default design markers, against 8% of YC startups, and 86% still ran on shadcn/ui's untouched theme tokens. Visitors notice that sameness before a single feature runs.

The good news: you almost never need a rewrite. Here is the triage order we use.

Why a Redesign Beats a Rewrite

A vibe-coded product usually has two layers in very different condition. The logic layer works: auth, data, the core loop that made you ship it. The interface layer is what the model sampled from every app it has ever seen: plausible, generic, and inconsistent.

A rewrite throws away the layer that works to fix the layer that does not. A redesign does the opposite: it leaves the logic alone and rebuilds the interface as a system your existing stack adopts incrementally. Developers already spend more than 17 hours of a 41-hour week on maintenance such as debugging and refactoring (Stripe Developer Coefficient, 2018), and that number is the whole argument: a rewrite adds a second product to maintain. The redesign is the infrastructure your next fifty AI-generated features will land on.

The exception is real: if the generated architecture cannot support the product you now know you are building, that is a rebuild decision, not a design decision. For everything else, triage.

Step 1: Tokens First, Always

Before touching any screen, define the design tokens: one color scale with semantic names, one spacing scale, one type scale, radii, and shadows. Then do a find-and-replace pass where hardcoded values become token references.

This is the highest-leverage hour in the entire redesign. Every shortcut the AI took becomes visible the moment you diff its values against a scale: the fourteen grays collapse to four, the seventeen padding values collapse to a spacing step. And it is the step that makes every later fix stick, because from now on changed decisions propagate instead of being re-made per screen.

Start with the three defaults our vibe-coded design study found give a product away fastest: the typeface (59% of Lovable-built apps ship Inter or the browser's default font stack, against 25% of YC startups), the shadcn/ui theme values left exactly as generated, and the 0.5rem corner radius a third of them never change. Pick one typeface with some character, set your own colour and radius tokens, and the product stops looking like every other launch that week.

Step 2: Consolidate the Components

Inventory the repeated elements: buttons, inputs, cards, modals, tables. A vibe-coded app typically has several near-identical implementations of each, because every generation session reinvented them.

Pick one implementation per element, rebuild it on the tokens, and replace the others. Do not redesign yet; consolidate. A product with one mediocre button used everywhere looks dramatically more professional than a product with three good buttons used randomly. Consistency reads as intent, and intent reads as trust.

Step 3: Design the States Nobody Generated

AI tools generate the happy path, because the happy path is what you prompted. The states that make software feel finished almost never exist in a vibe-coded app: empty states that tell a new user what to do, loading that holds the layout instead of jumping, errors that say what went wrong and how to fix it, and content that overflows gracefully.

Work through your core flow and give every screen its four states: empty, loading, error, full. This is where a cleaned-up product stops merely looking better and starts feeling engineered.

Forms are the worst offenders, and fixing them is its own pass. Generated forms usually validate on submit only, paint one red message for every field, keep the submit button live while a request is in flight, and drop what the user typed when the request fails. Give each field inline validation with a message that says what to change, one disabled and loading state for the submit button, a success state that confirms what happened, and keep the entered values on error. Those four fixes remove most of the "this feels broken" moments in a vibe-coded app without touching its logic.

Step 4: Re-Rank Every Screen's Hierarchy

The structural tell of generated UI is flatness: every metric in an identical card, every action given equal weight, everything technically present and nothing prioritised. Fix it screen by screen with one question: what is the single thing a user should see or do here? Make that element dominant, demote the rest, and move detail behind a click. Hierarchy is judgment, and judgment is exactly what the model could not supply.

Step 5: Make Your AI Tools Apply It

Here is the part most redesign advice misses: the same tools that created the drift are excellent at removing it, once they have constraints to follow. Point Claude Code, Codex or Cursor at the token file with the instruction that raw values are forbidden. Feed component consolidation as explicit tasks ("replace every button variant with Button from /components/ui"). Then write the conventions where the tool reads them on every run, not in the prompt you type each time.

Each tool has a place for that in 2026, and they overlap more than they used to:

Tool	Where the design rules live
Claude Code	CLAUDE.md in the repo root, plus topic files in .claude/rules/; it also reads an AGENTS.md (Claude Code docs)
Codex	AGENTS.md in the repo root, with AGENTS.override.md files for folders that need different rules (Codex docs)
Cursor	Project rules as .mdc files in .cursor/rules, or a plain AGENTS.md (Cursor docs)
Lovable	Project and workspace Knowledge, and it reads a root AGENTS.md or CLAUDE.md from the repo (Lovable docs); its design systems feature flags raw colours and off-system components as you build

One AGENTS.md that names the token file, lists the canonical components and forbids raw values now reaches most of these tools at once. The redesign then becomes self-maintaining: the next generated feature lands on-system instead of reintroducing the mess. We wrote a full guide to that workflow in handing off Figma designs to AI coding tools.

What to Fix First If You Only Have a Week

A realistic minimum sprint, in priority order: day one, tokens defined and applied to color and spacing. Days two and three, the button, input, and card consolidated on those tokens. Day four, empty and loading states for your primary flow. Day five, hierarchy pass on the two screens buyers actually see in demos: the dashboard and the main workflow.

That week does not finish the job. It moves the product from "AI demo" to "early but intentional," which is the threshold that matters in sales calls and investor meetings.

---

Frequently Asked Questions