RN UI from Stitch vs Claude Design: which one ships a committable diff

I had the same prompt open in two tabs this week.

On the left, Google Stitch. On the right, Claude Design. Same onboarding flow, same brand colors, same instruction: make these four screens look like they belong in the app, not like a Tailwind starter someone forgot to theme.

I was going to write you the clean version of this. Stitch vs Claude Design, here is the table, here is the winner, pick one and move on. I ran the test, I had the verdict, the draft was basically written.

Then Anthropic shipped a /design command inside Claude Code and quietly deleted the question I was answering.

I will get to that. But the comparison still matters, because the thing that decides the winner is the same thing that decides whether the new /design command is any good. So let me show you the test first.

Same prompt, two tools

The job was a real one. Four onboarding screens in my AI Mobile Launcher Standard app, currently a generic violet stack of cards, and I wanted them to match the rest of the product. I gave both tools the same brief and timed each from first prompt to "I would actually commit this."

Stitch is a UI generator. You describe a screen, it gives you a layout. And it is good at that. Inside a few minutes I had four mockups that looked tighter than what I would have drawn from a blank file. The hierarchy was right. The accent was used sparingly enough to read as intentional. If I needed something to drop in a deck or send to a designer, I was already done.

Then I tried to use it. The React Native export came back as four standalone files with hardcoded hex values, inline styles, and import paths that pointed at a design system I do not have. None of it knew about my tokens, my Screen wrapper, or where anything lived in my project. So I spent the longer half of the work hand-replacing color values with token references and rewiring imports. The whole Stitch run, cleanup included, came to about three and a half hours. The mockup was a gift. The code was homework.

Claude Design, pointed at the same four screens, was slower to feel impressive and faster to actually finish. No mockup to admire. It read my existing screens, copied the visual direction already in the app, and wrote the refactor back into the original files, using my tokens, my wrapper, my prop types. About 45 minutes, most of it Claude reading and writing, and a few minutes of me reviewing the diff and changing one copy string.

Here is the same screen after that run. Same question, same options, but it reads as the product now instead of a starter template.

The honest verdict, before the news broke: Stitch to explore, Claude to ship. Stitch wins when you have no design system yet and want a strong opinion on what a screen could look like. Claude Design wins when you have a real codebase and need the output to land in the right files without a cleanup pass. They are not competitors. They sit at different stages of the same workflow, and people kept treating them as substitutes.

That was the article. Clean enough.

Then they deleted the question

This week, a /design command landed inside the Claude Code terminal. You create, edit, and sync design straight from where you already write code: design system imports, code round-trips, no screenshot, no rebuild. The same overhaul moved Claude Design from a flashy demo toward something closer to a design-system compliance layer, and it fixed the token burn that made the old version expensive to run.

Read that back. The thing that made Stitch lose my test was that it could not see my codebase. The thing that made Claude Design win was that it could. And now the design step has moved inside the terminal that already has the whole codebase loaded.

The seam between design and code did not get a better bridge. It disappeared. The tool-versus-tool fight I was refereeing became a sub-plot in a bigger story: the harness is eating the stack. First it absorbed the planning step, then the review step, and this week it reached over and took the design handoff too.

One honest caveat, because I would want one from you. /design shipped basically yesterday. Nobody has months on it. I am not going to tell you it is battle-tested, because it is not, and the first person who tells you a day-old command changed their life is selling something.

So here is the part that is proven, and the part that actually matters whether you use Stitch, Claude Design, or the new /design command.

The setup that decides all three

None of these tools output on-brand code because of the model. They do it because of the boring scaffolding underneath, and that scaffolding is the same in all three cases.

Two pieces carry almost all the weight.

Design tokens as one source of truth. A single file that holds your color, type, spacing, and radius, with names instead of hex values. color.bg, color.accent, space.4. Every tool I named can read a tokens file. None of them can guess your palette. The difference between "pretty picture I have to rebuild" and "diff I can commit" is almost entirely whether the tool was pointed at this file before it generated anything.

A CLAUDE.md design-rules block. A short section that tells the agent the things your tokens cannot. Which wrapper component every screen uses. That the accent color is for one call to action per screen, never decoration. That nothing animates faster than 240ms. That danger red never shows up on a celebration. The rules a designer on your team would learn in week one and an agent will violate forever unless you write them down.

Give a tool those two things and it stops generating artifacts and starts producing changes that fit. Withhold them and even the smartest model hands you a cleanup pass. That was true for Stitch, it was true for Claude Design, and it is the exact thing that will decide whether /design is useful in your repo or just another demo.

This is the same lesson as the harness piece I wrote a couple of weeks ago. The model is the swappable half. The structure around it is the half you own, and the half that does the work.

The receipt

I am not theorizing. The onboarding in Morrow Self, my own app, runs on this setup. Same approach, different tokens, a warm rust palette instead of the dark one from the test, and the screens came out of the agent already looking like the product instead of looking like AI.

Same workflow, different tokens. That is the whole trick. When the design rules live in the repo, the tool you point at them almost stops mattering. Which, conveniently, is why I am not panicking that /design just absorbed the comparison I spent a week on.

So which one do you use

If you have no codebase yet, start with Stitch. Get a strong visual opinion on the page, commit to tokens and components, and the day you create that tokens file is the day you switch.

If you have a real codebase, the design step now lives in Claude Code. Build the two pieces above first, then let /design or the design skill work against them. Watch it for a few weeks before you trust it with anything you cannot review, because it is new, but build the scaffolding now, because the scaffolding is not new and it is what pays off.

The tool you pick matters less every month. The setup you point it at matters more.

I wrote up the exact tokens file and the CLAUDE.md design-rules block I actually ship as a one-pager you can paste into your own repo today. It goes out free to newsletter readers at Code Meet AI.

FAQ

Is Stitch better than Claude Design?

Neither, in the abstract. Stitch is better at proposing a look when you have no system. Claude Design is better at landing code when you do. Now that /design lives in the terminal, the second job moved even closer to the code.

What is the /design command?

A command inside Claude Code that lets you create, edit, and sync design work without leaving the terminal: design system imports, code round-trips, no screenshot handoff. It shipped in Anthropic's June 2026 Claude Design overhaul. New, so review its output before trusting it.

Do I need Stitch at all anymore?

Yes, if you are early and want visual ideation before you have committed to a system. Once you have tokens, the center of gravity moves to whatever runs against them in your repo.

What actually makes the output on-brand?

A tokens file plus a short CLAUDE.md design-rules block. That is the part that is proven, and it works the same across every tool here.