AI Agents

Google Stitch and DESIGN.md

How Google Stitch popularized DESIGN.md as a design-system format for AI UI generation.

April 10, 20267 min read

What Google Stitch is

Google Stitch is an AI UI generation tool introduced by Google as part of its suite of AI-assisted development products. It is designed to take a product concept or an existing brand identity and generate complete UI — layouts, components, pages — that reflects the brand's visual language. Stitch is not a generic image generator; it is aimed specifically at product and engineering teams who need to produce brand-consistent UI quickly, either for prototyping or as a starting point for real implementation. The tool uses design context to anchor its output, and that context is expressed through a DESIGN.md file. Rather than requiring users to fill in a form or connect a design system API, Stitch reads a structured markdown file that describes the visual rules of the product. That design decision — making a plain markdown file the interface between design intent and AI generation — is what gave the DESIGN.md convention its public visibility.

The pattern

Google Stitch made DESIGN.md a visible convention by using it as the interface between a product's design intent and the AI's generation process. The pattern works like this: the product team writes a DESIGN.md that describes colors, typography, component rules, layout patterns, and anti-patterns. The agent reads the file and uses it as a constraint for every piece of UI it generates. The result is not just visually consistent output — it is output that can be iterated with additional prompts while maintaining the same visual system across sessions. Stitch demonstrated that this pattern is implementable at the product level without a full design system toolchain, a Figma-to-code plugin, or an engineering team. A well-written markdown file is sufficient to produce brand-consistent AI-generated UI. That simplicity is why the convention spread beyond Stitch to other tools.

How Stitch uses DESIGN.md in practice

In practice, Stitch reads DESIGN.md at the start of each generation task and uses the file's content to filter design choices. When generating a button, it checks the button rules section for the correct variant, size, radius, and color treatment. When generating a card, it checks the card density rules. When generating a full page, it checks the layout patterns section. The file acts as a lookup table for product-specific visual decisions, and Stitch fills in the rest from its trained knowledge of UI patterns. This means the file does not need to cover every possible edge case — it only needs to cover the decisions specific to the product. Generic patterns that apply to most products are probably already in the model. Product-specific patterns like "this product uses 8px radius on buttons but 4px radius on table rows" are exactly what DESIGN.md should contain. The file's value scales with its specificity.

Beyond Stitch

Stitch popularized the format, but the need for DESIGN.md extends well beyond one tool. Every AI coding agent that generates or edits UI faces the same problem: how does it know what the product is supposed to look like? Cursor, Claude Code, Codex, Windsurf, Bolt, v0, and Lovable all benefit from the same written design contract. A repository can pair AGENTS.md for engineering behavior with DESIGN.md for visual behavior, and that pair governs every tool that touches the codebase. The format is also not locked to any specific tool or platform. Because DESIGN.md is plain markdown, it works wherever an agent can read files. It does not need a plugin, an API integration, or a platform-specific syntax. This makes it a portable standard: a team can switch AI tools and bring their design memory with them, because the file lives in the repository rather than inside any particular tool.

Catalog opportunity

Because the DESIGN.md ecosystem is still developing, a curated directory fills a real gap. Most teams who know they need a design file for their AI tools do not know where to start. They search for examples, find vague blog posts or overly simple templates, and end up writing a file that is either too abstract to help agents or too narrow to serve as a model for other products. DesignMD Directory solves this by cataloging real files from real products. When a developer working on a SaaS analytics tool needs examples, they can browse by category and find files that match their product shape. When a designer at an agency needs to explain the format to a client, they can link to real examples rather than describing an abstract convention. When a team is evaluating whether to adopt the format, the directory shows them what a mature DESIGN.md looks like in practice rather than in theory.

What the Stitch pattern means for your workflow

The practical lesson from Google Stitch is that AI UI generation is a problem of information, not capability. Current agents are capable of producing good UI. The question is whether they have the right information about what "good" means for a specific product. Stitch provided a clear answer: write it in a file and give it to the agent before generation begins. That insight transfers to any tool and any workflow. If you are using Cursor to edit React components, write a DESIGN.md and reference it in your prompts. If you are using Claude Code to add a new product surface, have it read DESIGN.md before planning. If you are using Codex to implement features autonomously, put DESIGN.md in the repo alongside AGENTS.md. The file is not the product of a sophisticated design process — it is the foundation of one. Starting early means every AI-assisted session builds on the same visual system instead of inventing new ones.

Use DESIGN.md with a real product reference

Browse curated DESIGN.md examples from product teams, design systems, developer tools, SaaS dashboards, and AI-native apps. Use them as references before your agent builds the next screen.

Browse directory Submit DESIGN.md

Related guides

AI Agents5 min read