The Problem With AI-Generated UI

Every AI coding tool can spit out a UI. You ask for a dashboard, you get a dashboard. You ask for a landing page, you get a landing page. The problem is it looks like every other AI-generated dashboard and landing page. Generic colours, default spacing, system fonts. It works, technically, but it looks like nobody who cares about design touched it. And the moment you try to get two screens to look like they belong to the same product, you're back to manually tweaking CSS until something vaguely coheres.

Google Stitch takes a different approach. It's an AI-native design tool from Google Labs, built on Gemini, that generates high-fidelity UI from natural language prompts and exports real HTML/CSS. It launched at Google I/O in May 2025 as a fairly basic experiment. The March 2026 v2 update turned it into something properly useful: infinite canvas, multi-screen generation (up to five connected screens at once), interactive prototyping, and a voice canvas for talking through your design ideas. Figma's stock dropped 10% the day the update shipped, which tells you roughly how seriously the market took it.

DESIGN.md: The Bit That Actually Matters

The flashy generation stuff is nice, but the feature that got me paying attention is DESIGN.md. It's a plain markdown file that encodes your entire design system. Colour palette with semantic tokens (primary, surface, accent), typography (font families, sizes, weights, line heights), spacing scale, grid conventions, border radius, shadows. Everything your design system defines, written in a format that both humans and language models can parse without breaking a sweat.

When you prompt Stitch, it passes your DESIGN.md as context to Gemini. The model treats those values as hard constraints, not suggestions. Every generated UI follows your system. Brand colours, spacing scale, typography, all consistent across screens. It's the difference between "generate me a settings page" and "generate me a settings page that looks like it belongs in our product."

Why Developers Should Care

Here's why DESIGN.md is more interesting than yet another design tool. It's portable. Completely tool-agnostic. Drop it in your repo root and any AI coding agent that reads context files will pick it up. Claude Code reads it. Cursor reads it. Copilot reads it. Your agent generates UI that respects your design system without you having to re-explain your brand colours in every prompt.

You can extract a DESIGN.md from any existing URL. Stitch scrapes the design tokens from a live site and produces the file for you. Got a client's marketing site and need to build an internal tool that matches? Point Stitch at their URL, grab the DESIGN.md, and your coding agent generates components that feel like they belong.

Think of it as the README.md of design systems. Designers define the system, developers commit the file, agents consume it. No Figma plugin, no design token pipeline to maintain, no arguing about whether that blue is #2563EB or #3B82F6. It's in the file. Full spec is at stitch.withgoogle.com/docs/design-md/overview.

Here's what a minimal one looks like:

## Colors
- Primary: #1A73E8
- Primary Dark: #1557B0
- Background: #FFFFFF
- Surface: #F8F9FA
- Error: #EA4335
- Text Primary: #202124
- Text Secondary: #5F6368

## Typography
- Font Family: Inter, sans-serif
- Heading 1: 32px, 700 weight
- Body: 16px, 400 weight
- Caption: 12px, 400 weight

## Spacing
- Base unit: 8px
- Values: 4, 8, 16, 24, 32, 48px

## Components
- Button border radius: 8px
- Card shadow: 0 1px 3px rgba(0,0,0,0.12)
- Input border: 1px solid #DADCE0

That's it. Your agent reads this and every button, card, and heading it generates uses those exact values.

Getting Started

Free at stitch.withgoogle.com with a Google account. The workflow is straightforward:

1. Generate a DESIGN.md from an existing site URL, or create one from scratch in Stitch's editor.
2. Drop it in your repo root (or .stitch/DESIGN.md if you prefer keeping things tidy).
3. Prompt your AI coding agent to build UI. It picks up the design system automatically.

For quick iteration, Stitch's canvas lets you generate multiple connected screens and prototype interactions between them before you write a line of code. When you're happy, export the HTML/CSS and hand it off to your component framework of choice.

When It Falls Short

The generated code is clean HTML/CSS but not component-ised. You'll want to refactor the output into React, Vue, or whatever you're running. Complex interactions beyond simple navigation need building by hand after export. And the five-screen limit means larger apps get done in batches.

The DESIGN.md format isn't standardised either. It's Google's convention and other tools happen to work with it because markdown is universal. No formal spec. If Google bins Stitch tomorrow, the file is still useful, but the tooling around it disappears.

The Bigger Question

Are we watching the design-to-development workflow get properly rewired here?

For years, the pipeline has been: designer creates in Figma, developer squints at the spec, developer approximates it in code, designer files a ticket saying the padding is wrong, developer adjusts by 4 pixels, repeat until someone gives up or the sprint ends. The tooling between design and code has always been niche, expensive, and full of cognitive load. Figma-to-code plugins. Style dictionaries. Design token pipelines. Handoff ceremonies. None of it flows naturally.

DESIGN.md is interesting because it turns design into an intermediate DSL that makes the whole thing commodity for developers. A markdown file. In your repo. That your agent reads. No Figma plugin, no handoff, no "inspect mode." The design system is code-adjacent from the start.

Now, I've been told many times by design organisations that those extra 10 pixels on a button contribute to 1% of revenue for large companies. Maybe they do. At scale, design systems matter enormously. The pixel-level precision, the A/B testing of border radius changes, the obsessive consistency across 200 screens. That's real work with real business impact, and I'm not dismissing it.

But for the 95% of teams that aren't operating at that scale? The ones shipping MVPs, building internal tools, prototyping features? The Figma-to-dev pipeline is overhead they can't afford. DESIGN.md gives them "good enough consistency" at near-zero cost. Write the file once, every agent respects it, move on.

The question is whether this eventually scales up to replace the enterprise design workflow too, or whether there's a permanent split: DESIGN.md for speed, Figma for precision. I reckon both survive, but the percentage of work that needs Figma-level precision shrinks every time the AI-generated output gets a bit better.

Bottom line: DESIGN.md might be the most consequential thing about Stitch. Not because the design tool is revolutionary, but because a plain markdown file as the bridge between design and code is such a stupidly simple idea that it makes you wonder why we spent a decade building elaborate pipelines instead.