AI design agents that work from your codebase

Ask a general-purpose AI to "make this page look better" and you'll usually get something that looks fine in isolation and wrong in your app: a new shade of blue, a button that ignores your Button component, spacing that matches nothing else. The model isn't bad at design. It simply doesn't know your design. An AI design agent that works from your codebase starts from what you already have, your tokens, components and existing screens, and proposes changes inside those constraints. This post explains what that takes, what to look for when choosing a tool, and where the limits are.

Why AI-generated UI often looks generic

Without context, a model falls back on the most common patterns it has seen. That's why so much AI-made UI shares a look: the same gradients, the same rounded cards, the same default palettes. In an existing product, those defaults create a second, competing visual language.

The fix isn't a cleverer prompt. It's giving the agent the same inputs a careful human designer would ask for on day one:

• The design tokens: colours, spacing scale, type scale, radii, shadows.
• The component inventory: which components exist, what props they take, and which ones are deprecated.
• The screens that already exist, and the states each one needs.
• The decisions already made: what's been approved, and what's off-limits.

An agent with that context can say "use Button variant="secondary" and --space-4" instead of inventing new values.

What "working from your codebase" should mean

The phrase gets used loosely, so it helps to break it into concrete abilities.

It reads your existing code

A useful agent understands the shape of your project before it suggests anything: where tokens are defined, which components are reused, and where styles are hard-coded. Static analysis, reading files without running them, is enough for much of this, and it avoids executing untrusted code just to look at it.

It finds the inconsistencies you already have

Most apps don't need a redesign; they need consolidation. Typical findings in a React codebase:

// Three "primary" buttons that drifted apart
<button className="bg-[#3b5bdb] px-[18px] py-2 rounded-md">Save</button>
<button style={{ background: '#3d5afe', padding: '8px 16px' }}>Save</button>
<Button variant="primary">Save</Button>

An agent that knows the third one is the real component can propose replacing the first two, rather than adding a fourth.

It proposes changes in your vocabulary

Changes should land as edits to tokens and components, not one-off overrides. Compare these two ways of "making the brand colour warmer":

- :root { --color-accent: #3b5bdb; }
+ :root { --color-accent: #4c4fd6; }

- <Button variant="primary">Save</Button>
+ <Button variant="primary" style={{ background: '#4c4fd6' }}>Save</Button>

The first changes one token and every component that uses it follows. The second adds a new hard-coded value that the next change will miss. If you're not yet working with tokens, design tokens explained for developers covers the basics.

It produces something reviewable

Design changes to a live product should arrive the same way code changes do: as a pull request with a clear scope that a human reviews and merges. An agent that pushes straight to your main branch removes the step where someone checks the result.

How agents get context: MCP

The Model Context Protocol is an open-source standard for connecting AI applications to external systems. In MCP's architecture, an AI application (the host) connects to MCP servers, which expose three core primitives: tools (functions the AI can invoke), resources (data that provides context) and prompts (reusable templates).

For design work, that means a coding agent you already use can read your design system and approved screens from a design tool's MCP server, instead of you pasting screenshots and hex codes into a chat. It also means the design tool decides which tools it exposes. A well-designed server can let an agent read and draft while keeping approval, billing and access control out of reach.

Guardrails that matter

Giving an agent access to your design system and repository is useful and risky in equal measure. These are the guardrails worth insisting on.

Drafts, not decisions

The agent should be able to propose a token change or redesign a screen state, but a person should accept or reject it. Agent-made changes should be clearly labelled until someone accepts them.

Approval bound to a version

When a design is approved, the approval should refer to an exact, frozen version. If the agent (or anyone) changes the design afterwards, that's a new version needing a new review. Otherwise "approved" quietly drifts away from what was approved.

Spend limits

Agents can run many steps. Small requests running automatically is convenient; large jobs should show what they'll do and what they'll cost before they start.

No path to your default branch

The output should be a draft pull request. Merging stays with your team and your normal CI.

Questions to ask when choosing a design agent

Use these when comparing tools in this category:

1. Does it read my code, or only screenshots? Screenshots show what it looks like; code shows how it's built.
2. Does it use my tokens and components? Ask to see a proposed change. Count new hard-coded values.
3. Which frameworks does it support today? Be specific about your stack.
4. How are changes reviewed? Look for frozen versions, written review decisions and a visible distinction between agent drafts and accepted work.
5. Can my existing coding agent connect to it? If your team uses a coding agent already, an MCP server avoids a second, parallel workflow.
6. What can the agent never do? Approve, merge, change billing, change members, push to the default branch.
7. Does it cover states? A redesign that only covers the happy path leaves loading, empty and error screens behind. Our guide to designing every state explains why that matters.
8. What does it refuse to fake? Tools should say plainly when a feature isn't available, rather than pretending.

How M1rror approaches it

M1rror is one tool in this category, so here is plainly what it does and doesn't do.

It turns design references, an existing React and TypeScript codebase and team feedback into an approved, versioned design system and a scoped pull request your team merges. Code features support React and TypeScript web apps today.

Reading your code. In Code mode you connect a GitHub repository. A static scan reads files without running them and finds components and design issues. Pull request design checks look at added lines and flag off-theme colours, off-scale spacing and typography, re-implemented components, low contrast and missing states. There's also a free "taste check" that finds what makes a project look AI-made.

The in-app design agent. It works on what you select. It runs small requests on its own up to a workspace limit in usage units and quotes bigger work first. When it draws a screen state, that state is badged "Agent draft" until you accept or undo it.

External coding agents. Claude Code, Cursor and Codex can connect to M1rror's MCP server, using OAuth or a personal agent token, on the Studio and Team plans. They can read projects, the design system, screens, the approved release and its build plan, and they can draft: propose a token change, update a screen state, prepare a build plan. They can never approve, change billing or members, or open pull requests. Setup is in coding agents and the MCP server reference.

Approval and shipping. "Send for review" freezes the draft as a release; approvals bind to that exact release, and a changed design means a new release and a new review. In the app, a build plan is authorised by a person and the result is a draft pull request. M1rror never pushes to your default branch and never merges.

The current limit. During the pilot, M1rror itself only runs builds on its bundled sample project. For your own repository, your coding agent builds from the approved plan over MCP. That's a real constraint worth knowing before you start: the design, review and planning happen in M1rror, and the code change is made by the coding agent you already trust, in your repo, through your normal review.

A practical workflow, whichever tool you use

Even without a dedicated tool, you can get much better results from a coding agent by giving it design context explicitly. Put a short rules file in your repo and point your agent at it:

## UI rules for agents
- Colours, spacing, radii and type come from `src/styles/tokens.css`. Never add hex values.
- Use components from `src/components/ui`. Don't re-implement Button, Input or Dialog.
- Every data-driven screen handles loading, empty, error and denied states.
- Pair status colour with an icon and a text label.
- Respect `prefers-reduced-motion` for any animation.
- Open a draft pull request. Don't push to main.

Then work in small loops:

1. Ask the agent to audit one screen against the rules and list issues, without changing code.
2. Pick the issues worth fixing and ask for a draft pull request that addresses only those.
3. Review the diff for new hard-coded values and re-implemented components.
4. Check the states, not just the default view.

A dedicated design agent adds the parts a rules file can't: a shared, versioned design system, review with recorded decisions, and checks that run on every pull request.

Wrapping up

An AI design agent is only as good as the context it works from and the guardrails around it. Look for one that reads your actual code, speaks in your tokens and components, keeps people in charge of approval, and hands back draft pull requests rather than pushing changes. If you want to try that approach, M1rror's free Explore plan needs no card, and the quickstart walks through connecting a project.