Tried Paper last night. It showed me something about where agentic design interfaces are heading.
Some context before I get into it.
I build everything with AI agents now
I'm building Domain Collective, a dashboard that lets you manage domains across seven registrars in one place. The entire UI is built with agentic coding. Claude Code and Codex running together, different agents handling different parts of the interface.
It works. The agents are fast. You describe what you need, answer a few questions, and get a working interface back. Things that used to take days now take hours. I'm not going back.
I've been building user interfaces for 12 years though. Agency work, product teams, my own startups. I've shipped with most of the major frameworks and watched every big shift in how we build for screens, from responsive design through component architectures through design systems.
So when I say something is off with how we're building UI right now, I'm speaking from some experience.
The problem nobody's talking about
Here's how software used to get built: design first, code second.
You'd work out the user experience. Map the information architecture. Build a design system with tokens: colors, spacing, type scales, component patterns. Then you'd code against that spec. The design was the contract. Everyone knew what "correct" looked like before anyone wrote a line of code.
With agentic coding, that sequence flipped.
Now everything happens on the go. You describe what you want, the agent delivers. The output is probabilistic. You don't know what you're going to get until you see it running. You're reviewing output, not directing input.
For a small project, fine. Ship it.
For a growing product with dozens of screens, you start noticing things.
The spacing on the features page doesn't match the homepage. The heading hierarchy shifts between sections. Buttons that looked the same last week now have slightly different padding. The card radius on page A is 12px, page B is 14px, page C the agent went with 16px.
I've been calling this design drift.
The agent optimizes for what's in front of it. It makes something that looks right in isolation. But it has no memory of what it shipped yesterday or three sprints ago. Each session starts fresh. Each prompt produces a slightly different interpretation of your design language.
As the codebase grows and context limits kick in, the drift picks up speed. You end up with a bunch of almost-matching versions of what your design was supposed to be.
Anyone remember Brad Frost's Atomic Design? Atoms, molecules, organisms. That methodology existed because we needed shared building blocks to keep interfaces consistent across teams.
We solved this once with design systems and design tokens.
Now we need to solve it again for agents.
MCPs gave agents a lot of new abilities. Design isn't one of them.
MCPs have opened agents up to all kinds of things. Your agent can talk to Sentry, PostHog, your database, your CI pipeline. It reads your codebase, runs your tests, ships changes that compile.
Consistent interfaces? Still the weak spot.
The code quality from AI agents has gotten good. The design quality hasn't caught up. Not because agents can't design, but because we haven't given them the right tools to stay consistent.
That's what I was thinking about when I opened Paper.
What happened when I connected Claude Code to Paper
Paper is a design tool where the canvas is actual HTML and CSS. Not a proprietary format that gets converted. The design is the code. It's built by Stephen Haney, the person behind Radix UI (4M+ monthly npm downloads) and Stitches.
Paper has an MCP server, which means AI agents can read from and write to the design canvas directly.
I connected it to Claude Code, started my local dev server for Domain Collective, and told the agent to look at my live site and recreate it in Paper.
I wasn't expecting much honestly. I've seen a lot of AI demos that look good in a tweet and fall apart when you try them.
This was different.
Claude Code started building my homepage in Paper. The nav bar showed up. Then the hero section. The feature grid, card by card. Testimonials. FAQ. Footer with all its link columns.
Piece by piece, on the canvas, in real time.
Paper shows these little animations while the agent works, visual cues for where it's operating. You're watching an AI agent put together an interface and the design tool is responding to it live.
One pass. And the result was close. Really close.
Why it works this well
Paper's rendering engine is HTML and CSS. LLMs already think in HTML. There's no translation step, no proprietary API to learn. The agent writes HTML, Paper renders it as a design. That's the whole thing.
Compare this to Figma's MCP, where designs live in a proprietary format and need to be translated back and forth. Paper skips that. The design is already in the language the agent writes.
The output wasn't pixel-perfect. But it was much closer than I expected. The typography hierarchy, the card layouts, the spacing.
What's broken (honest take)
Paper is in public alpha and it shows in places. Here's what I ran into:
The MCP can't pull images reliably. My hero illustration and logo came through as empty boxes. Design without images is basically wireframing. This needs to work.
SVG icons get recreated from scratch as inline SVGs, and they look rough. An icon pack plugin would fix this. Let the MCP call something like "lucide/arrow-right" and get the real SVG back instead of the agent trying to draw it.
And the big one: no design tokens. I couldn't find a way to define persistent tokens in Paper, the kind of thing where your colors and spacing and type scales carry across artboards and agents can reference them by name. For one screen that's fine. For a multi-page system, you need this.
I worked around it by having Claude Code create a Design System artboard first. Color palette, type scale, buttons, spacing, card patterns, radius reference. All on one board that the agent could look at before building the rest.
It's a workaround though. The agent is looking at a picture of tokens, not reading a structured file. If Paper adopted the W3C Design Tokens spec (which went stable in October 2025), agents could reference $color-brand-primary instead of eyeballing #18181b each time.
That alone would go a long way.
What I built before hitting the limit
Claude Code created 10 artboards in Paper:
- Full homepage: hero, features, testimonials, FAQ, footer
- Design system reference board
- Features hub with six color-coded cards
- Six feature detail pages, each with its own accent color and content sections
- Integrations page with seven registrar cards and a feature support matrix
- Roadmap page (got started, then ran out of calls)
All generated by an AI agent working through MCP. All close enough to the live site that the screenshots make the case better than I can describe it.
Ten artboards. One evening. One agent.
Where I think this is going
AI agents can ship UI faster than any team I've worked on. But speed without guardrails produces what people have started calling "AI slop." Interfaces that are fast and generic and look vaguely interchangeable. Good enough to ship, not good enough to care about.
Design systems solved consistency for human teams. But most design systems aren't built for agents. They're written for people to read, not for machines to enforce.
A few things are coming together though.
Paper, Figma, and Storybook are all building MCP servers that let agents interact with design tools and component libraries. The W3C Design Tokens spec went stable last year, giving us a machine-readable format for design decisions. Brad Frost has been writing about "agentic design systems," systems built specifically for agents to consume. The Storybook team showed constrained generation where agents can only assemble from approved components.
The version of this that I keep thinking about: an agent that reads your tokens from a standard spec, references your component library through Storybook, creates designs in Paper, and ships code that matches. Design drift goes away because the agent never had room to drift.
We're not there. But last night, watching Claude Code build a full design in Paper, writing the same HTML it already knows, on a canvas I could inspect and edit, I could see the outline of it.
Paper's bet is that a code-native canvas means agents don't need a translation layer. I think they're right.
What's next
I'm going to upgrade to Paper Pro and spend a weekend doing a real design sprint. Not recreating existing screens this time, but exploring new directions for Domain Collective. I'll steer, the agent will explore.
If you're building with AI tools and you care about what ships looking good and staying consistent, this is the space to watch. The tools are young. The rough edges are obvious. But something real is forming here.