Weave Agents Into Design

Ask most people how AI does design and you get two answers: a person with a mouse, or a robot with a prompt. I've spent enough hours in the space between those two to know it isn't a gap. It's a row of doors.

The automation debate had two chairs for years, and both were comfortable lies. Manual design means slow, considered, and expensive. Fully automated means fast, cheap, and a little embarrassing. Agents quietly moved the furniture, and nobody updated the seating chart.

There are at least three distinct ways to put an agent on a design task, and they line up on a spectrum of how much control you keep. On one end, agents that code your prototype directly. On the other, end-to-end tools that hand you a finished screen. In the middle, the complicated middle, connections that reach into the design files you already own.

I gave all three routes the same job: one sentence, one homepage for a startup. What I found isn't that one route wins. It's that you're supposed to weave them, and that all of them share a ceiling you should know about before you bet a roadmap on them.

Route 1: coding agents, the control extreme

On this route, the agent writes the design as working code, and you stay at the wheel. You are designing through a programming language, which sounds wrong until you see the speed. A good agent turns a vague idea into a page you can open in a browser before your coffee cools.

I ran this route with DeepSeek V4 Pro and Kimi K3, both through OpenCode. I gave each one sentence: a homepage for a startup. Then came several rounds of questions, because the agent wanted to discuss themes, colors, the impression the page should leave. It asked before it built, and I liked that. We went back and forth the way I would with a human designer.

The output was a single self-contained HTML file. Drag the file into a browser and the whole design is there, real, clickable, laid out. Ask for a second file and the agent documents the design system behind the first one: color tokens, sizes, the spacing rhythm. That second file is worth more than the first, because it's the part a designer normally has to write by hand.

The drawbacks are real, and I count them in threes. The output has an AI feeling — the stereotype design every model learned from the same internet. The design system lacks strong rationale. The tokens exist because they're plausible, not because they mean something, and I've tried defending that in a room full of people who care. It doesn't survive. And fine-tuning details is nearly impossible. At some point you'd rather grab the mouse and edit by hand than talk your clever agent into one more tweak.

Route 2: end-to-end tools, the other extreme

On this route you type the brief and get a designed result. No code, no file plumbing, only a conversation that ends in something polished. Claude Design is the flagship example, an Anthropic Labs product that turns prompts into designs, prototypes, and slides, powered by Claude Opus 4.7 under the hood ¹. Open Design sits on the same shelf: the open-source Claude Design alternative, agent-native and local-first, that runs your own coding agent as the design engine ².

I gave this route the same sentence, and the experience was entirely different from coding. It feels like running a brand-new design tool rather than arguing with a compiler. The prototype appears, and you click and type comments directly on it to fine-tune. You are gesturing at the design, and the design obeys.

The results can exceed your expectations, especially if you don't expect much. That's exactly when my judgment gets hardest, because a surprising output feels like a finished one. I've learned to sit on my hands before trusting a wow. Underneath, the backbone is still a coding agent, so this route inherits nearly the same problems, only with a better wrapper. Same model, same training data, same inherited taste. Only the wrapper is prettier.

The templates are the real gift. These tools ship with a lot of them, along with skills, so you can start from scratch even without strong design opinions. That's wonderful, and it's the trap. An opinion you didn't have to form isn't yours yet.

Route 3: MCP connections, the complicated middle

This route points the agent at your real design files. Through MCP, short for Model Context Protocol, the agent reads and edits the file you already own instead of drawing a new world from scratch. Figma ships a Dev Mode MCP server, in beta since June 2025, that can pull components, variables, and layout data out of a file. It can also write changes back into it ³. Penpot ships its own official MCP server with the same read-write promise ⁴.

A plain-language gloss for the non-engineer: I think of MCP as a pipe between the agent and the file. The agent doesn't redraw your screen from a screenshot. It reaches into the actual layers, the actual tokens, the actual constraints. That's why this route fits into a designer's existing workflow instead of replacing it.

I wired both tools to OpenCode and ran the same sentence again. Next to the coded HTML from Route 1, the result felt coarse: it lacked the small considerations that make a design feel finished. Pulling a systematic design system out of it was harder than I expected. The file was real, and so were its rough edges.

This route is complicated because it's a two-way street. The agent reads your local files for extra context and the remote design file for detail, then writes back. You translate between two worlds the whole time: the file's constraints on one side, the agent's judgment on the other. I think that's where the coarseness comes from. The same agent that draws a confident page from a blank prompt has to squeeze itself into a file with existing layers, established tokens, and a style that already has opinions — and the file shows the squeeze. Every benefit of the extremes shows up here with their problems attached. That's why I spent the most time on this route — and the most effort explaining it.

Weaving them together

None of this matters until you stop treating the routes as rivals. They aren't a ladder where the newest wins, and they aren't a contest where you must pick a religion. They're a toolkit, and I've stopped asking which one wins.

Each route is cheap at one job and costly at another. End-to-end tools are cheap at exploring directions, coding agents are cheap at making ideas testable, and MCP is cheap at refining a file that already exists. So the fastest workflow isn't the one with the best tool. It's the one where every route does only the job it's cheap at.

Here's the combination I run. Start with an end-to-end tool and its templates, and explore directions fast: different vibes, different layouts, shots on goal. Collect the impressions that survive contact with reality. Then switch to coding agents and turn those impressions into quick prototypes, one direction each, until you can feel which one is right.

Once one survives, distill it into a design system: the tokens, the components, the rhythm. Move that system into Figma or Penpot and refine it where real designers work. Then jump between tools as needed, generating more components or exploring a different page layout without rebuilding anything.

The decision logic is simple once you see it. If you trust the direction, go to the middle: refine in the real file through MCP. If you don't trust it yet, stay at the extremes: explore cheaply with end-to-end tools, test quickly with prototypes. In my experience the question is never which tool is best. It's how much you trust the direction versus how much you need to move.

The honest ceiling

Now the part I promised to say straight. At their best, none of these routes matched high-standard handcrafted design. I ran all three, I was impressed more than once, and I wouldn't hand any of the outputs to a client who cares. Pretending otherwise is how the whole thing loses credibility.

Agents are good at two kinds of design. Stereotype design, the kind with thousands of existing examples to copy from. And modern tech-savvy work, the vibrant colors and industrial product aesthetic that fills every design blog. If your problem looks like those, an agent will shock you with how close it gets.

Where they fail is subtle, nuanced design, the kind that expresses cultural depth and diversity. I don't think that's a prompt problem, and it won't be fixed by a better model next quarter. Agents optimize for plausible and fast, and considered judgment is the slow part they skip. Considered judgment is what asks why the color is this color, why the layout moves the eye this way, why the brand feels like itself and not the other hundred startups. The gap is the part of design that lives outside the training data: context, history, taste that has reasons.

The takeaway

So here's my takeaway, quietly. The binary is dead: manual or automated was always a false choice. There are three routes, they work better than you expect, and none of them replaces the designer's eye. The power isn't in picking the newest tool. It's in weaving all three into the flow you already have, and knowing exactly where the ceiling sits.

Use agents to move faster. Use the designer to decide what deserves handcraft. And the next time someone tells you design is either a human or a robot, tell them there's a whole row of doors in between.