The issue is not AI skill. It is missing rules.

When AI creates a Figma screen, most people judge the result by how it looks.

That makes sense. Design is visual.

But inside a real team, looks are only one part of the job.

A useful Figma file also needs:

• the right components
• the right variables
• the right text styles
• clear layer names
• clean auto layout
• tokens instead of loose values

Without these, the file becomes a mockup, not a working design.

This is why AI-made Figma files can feel impressive and broken at the same time.

Claude Code may know how to call the Figma API. It may know how to read files, create nodes, and work with design data. Figma’s own docs say the MCP server can provide design context to agents and support writing content back to Figma.

But knowing how to do something is not the same as knowing when it must be done.

That’s the missing layer.

The AI needs a set of rules before it starts building.

Not vague advice. Not “please follow the design system.”

Clear rules.

Search before creating.
Use tokens before raw values.
Bind styles before handoff.
Check the file before moving on.

That is how you turn AI from a fast sketch tool into a design partner.

Why design systems break when AI skips structure

Design systems exist to stop teams from solving the same problem again and again.

They give everyone shared parts.

A button is not just a rectangle with text. It has states, sizes, variants, tokens, and rules. A color is not just #5C6AC4. It may be color/brand/primary, used across hundreds of screens.

When Claude Code ignores that system, it creates hidden debt.

The file still looks fine today.

But tomorrow, someone needs to change the brand color. The token updates. The AI-made layer does not. Someone needs to swap a button state. The one-off button has no variant. Someone needs to build the screen in code. The layout does not match the real component.

Small shortcuts turn into slow work.

I’ve seen this happen with human designers too. A rushed designer detaches a component, tweaks a color, and ships the mockup. It works once. Then the system starts to drift.

AI can create that drift much faster.

That is why the goal is not just “make Claude Code design better.”

The goal is more precise:

Make Claude Code work inside your design system.

Start with a preflight check

Before Claude Code creates anything in Figma, it should check the setup.

This is the first rule.

A preflight step answers a few basic questions:

• Is Figma MCP connected?
• Can the AI read and write to the right file?
• Are the libraries loaded?
• Are variables available?
• Are text styles available?
• Are component sets available?

This sounds simple, but it prevents a lot of waste.

Without this check, you may only find the problem after the screen is built. By then, the file already has loose colors, random sizes, and missing components.

A preflight step gives the AI a source of truth before it acts.

That source of truth can include a token map and a component list. The token map tells Claude which colors, spacing values, radius values, and type styles exist. The component list tells it which parts it should use first.

This changes the whole workflow.

Claude no longer starts with a blank canvas.

It starts with your system.

Turn references into a design brief

Most AI design tasks start with rough input.

A screenshot.
A Loom video.
A few lines of text.
A competitor page.
A quick note from a product manager.

If Claude Code jumps straight from that input to the canvas, it has to guess too much.

That is risky.

A better flow is to ask it to create a design brief first.

The brief should explain:

• what sections need to be built
• which components may be needed
• which tokens should apply
• what states are required
• what layout rules matter
• what needs a human decision

This step slows the AI down in the right way.

It makes the plan visible before the file changes.

Think of it like measuring wood before cutting it. The work still moves quickly, but you avoid the ugly mistakes that come from rushing.

For example, if you ask Claude to build a sign-up form, the brief may list input fields, labels, helper text, error states, a primary button, and mobile behavior.

Then Claude can map each part to your design system.

That is much better than letting it invent a form from memory.

Search the library before making anything new

This is the rule I would make non-negotiable.

Before Claude creates a UI element, it must search the library.

If a matching component exists, use it.

If no match exists, create a new element only when needed. And even then, it should use clean auto layout, clear names, and the closest design tokens.

This one rule fixes a lot.

It stops the AI from creating five versions of the same button. It keeps form fields tied to real variants. It makes the final file easier for designers to edit.

Figma’s Code Connect also points in this same direction. It links Figma components to code components, helping AI agents use more accurate details from real systems.

That matters because design systems do not live only in Figma. They often connect to code, docs, tokens, and product rules.

The AI should respect that chain.

It should not treat every screen like a fresh artboard.

Bind every style to a token

This is where many AI-made designs fall apart.

They look polished, but the values are loose.

A color is added as a raw hex. A font size is typed by hand. Spacing is set to whatever looked close. Radius values are copied from the visual reference.

That may pass a screenshot test.

It will fail a design system review.

The fix is simple in theory: bind every style to the right token or style.

Color should map to color tokens.
Type should map to text styles.
Spacing should use approved values.
Radius should follow the system.

No raw values unless there is a clear reason.

This rule matters because tokens let teams update design at scale. A bound value can change with the system. A raw value just sits there.

That is the difference between a file that grows with the product and one that slowly rots.

The AI should also run a QA pass after writing to Figma. It should check each layer and confirm that values are bound correctly.

Not just “does it look right?”

A better question is:

Can the team keep using this tomorrow?

Separate design mode from prototype mode

Not every AI task needs strict design system rules.

Sometimes you just need a throwaway prototype.

In that case, speed matters more than clean structure. Raw values are fine. One-off parts are fine. The goal is to test an idea, not maintain a file.

But when the work lives in the product design file, the rules change.

Then Claude Code should act like a design assistant, not a sketch generator.

That means:

• use library components
• respect tokens
• keep layout clean
• name layers clearly
• avoid detached parts
• check the file after each major step

The same tool can work in both modes.

But it needs to know which mode it is in.

This is where many teams go wrong. They expect one AI workflow to serve every use case. It won’t.

A quick prototype and a production-ready Figma file need different rules.

What a better Claude Code workflow looks like

A stronger Figma workflow does not need to feel complex.

It can follow a clear order.

First, run preflight. Make sure Claude can access the right file, libraries, styles, variables, and components.

Next, create a design brief. Turn the rough input into a clear plan before touching the canvas.

Then, build section by section. For each section, search the library before creating new parts.

After that, bind all visual values. Colors, type, spacing, and radius should connect to the system.

Last, run QA. Check that the output looks right and is built right.

That is the difference.

Most people only review the surface.

A better workflow reviews the structure too.

The real goal is trust

Claude Code can move fast.

That alone is not enough.

A fast design file that nobody can edit is not a win. A polished screen full of loose values is not a design system win. A set of pretty components that do not match the library will slow the team down later.

The real goal is trust.

Designers should be able to open the file and know what they are looking at. Developers should see familiar parts. Product teams should be able to request changes without causing a layer cleanup session.

AI should not add hidden mess.

It should reduce it.

That only happens when we give it rules.

Not broad hopes. Real working rules.

• Check the system first.
• Plan before building.
• Search before creating.
• Bind before shipping.
• Review before handoff.

Claude Code can already do impressive things in Figma. The next step is making those things usable, clean, and easy to build on.

That is how we stop it from freestyling.

And that is how AI starts working like part of the design team.