Andrew Martin

Would You Trust AI to Be a “Junior Designer” Inside Your Design System?

by

Most “design AI” tools today act like a junior designer who’s… never met your brand.

They’re great at generating something that looks like UI.

But inside a real product team, that’s usually not enough.


If you own a design system (or work with one), you’ve probably seen AI:

  • Use the wrong components

  • Ignore spacing & grid rules

  • Invent new colours and type scales

  • Create patterns that don’t exist in your product

Fun for inspiration. Painful for production.

It got us asking a simple question:

What if AI behaved like a junior designer inside your design system, instead of a freelancer doing whatever they want?

What “Junior Designer AI” Might Actually Mean

I don’t think “AI replaces designers” is interesting.


What is interesting:


AI that understands your tokens, components, and patterns, and then works like a very fast, very literal junior:

  • It can only use components from your library

  • It respects your spacing, grids, and typography

  • It suggests layouts and variants, but inside the system

  • It produces real, code-backed UIs devs don’t have to rebuild

That’s the direction we’ve been taking with Merge AI 2.0 at UXPin:

  • Grounding AI in real component libraries (MUI, shadcn/ui, Ant Design, etc.)

  • Letting AI create and refine layouts with prompts, not just generate one-off shots

  • For larger teams: connecting a Git-based component library so AI learns your system, not a generic one

But I don’t want this to just be “our hot take.” I’m genuinely curious how other teams see this.

Where Would You Actually Trust AI in Your System?


If you imagine AI as a junior designer sitting inside your design system, where is it allowed to help?

Some ideas I keep hearing:

  • Exploration:
    “Give me 5 on-system variations of this page layout.”

  • States & edge cases:
    “Generate empty/loading/error states using our existing components.”

  • Refinement:
    “Tighten hierarchy and spacing on this screen; keep components as-is.”

  • System policing:
    “Flag anywhere this design is off-system and suggest on-system alternatives.”

But there are also hard no-go zones for teams:

  • Net new patterns without review

  • Changing core components or tokens

  • Messing with accessibility or content tone

Questions for You 👇

I’d love to hear from designers, design system owners, devs, and PMs:

  1. Would you trust AI to act as a junior designer inside your design system today? Why or why not?

  2. What’s the first task you’d delegate to it? (Variants? States? Layout tweaks? Mapping legacy screens to current components?)

  3. Where would you draw a hard line and say: “AI should never touch this”?

We’re about to launch Merge AI 2.0 with this “design-system-aware AI” approach, and I’d love to pressure-test the idea with the Product Hunt crowd before we hit publish.


Drop your thoughts, hopes, or horror stories below 👇

I’ll be hanging out in the comments, and I’m happy to share more about what we’re building if you’re curious.

21 views

Add a comment

Replies

Best
Kari Brooks

If I had to pick the first task I’d delegate, it would be the boring expensive part of the job nobody actually wants to do: state and edge-case generation. If a "jr. AI designer” can reliably produce core interaction & data states (empty, loading, error...) using only approved system patterns, every dev team I've ever worked with would celebrate. That’s the kind of AI that earns a seat on the product team.

Andrew Martin

@kari_brooks ohhh I like it! Keep your eyes peeled for UXPin's next producthunt launch ;) haha