Google Stitch’s most important idea may not be AI-generated UI. It may be a markdown file.
When Google relaunched Stitch as an AI-native design canvas in March 2026, one of the quieter additions was DESIGN.md: an agent-friendly file for exporting and importing a project’s design rules. A month later, Google made the draft DESIGN.md specification open-source so the format could travel beyond Stitch itself. That changes the story considerably. DESIGN.md is no longer interesting only as a Stitch feature. It is an experiment in making design-system context portable enough for other design tools, coding agents and product workflows to read. (Sources: Google Labs; Google DESIGN.md announcement.)
That matters because design systems are increasingly being asked to serve a third audience. Designers need components and guidance. Developers need production implementations. AI agents need enough structured context to understand why one component, token or pattern is canonical instead of inventing another plausible version.
The interesting thing about DESIGN.md is not markdown. It is the attempt to make design intent portable enough for software to reason about it.
This is the same shift behind our DesignWhine Guide to Design Systems: the system is moving beyond a component library toward shared product infrastructure. DESIGN.md is one possible representation of that infrastructure, not the whole thing.
What Google Stitch Is Now
Stitch began as Google Labs’ experiment for turning text and image prompts into UI designs and frontend code. By March 2026, Google had rebuilt it around an infinite AI-native canvas, a project-aware design agent, interactive prototyping, voice input and the ability to bring images, text and code onto the canvas as context. At Google I/O 2026, Stitch added real-time streaming and steering, plus paths from design into Google Antigravity and web publishing. (Sources: Google Labs, March 2026; Google Labs, May 2026.)
The larger direction is easy to miss if Stitch is treated as another screen generator. Google is trying to compress the distance between product context, interface exploration and implementation. That overlaps directly with the change we described in How AI Is Changing the Journey from PRD to UI: the blank canvas is becoming less important than the context brought into the workflow before generation begins.
What DESIGN.md Actually Is
DESIGN.md is a text representation of design rules that an AI agent can read. Inside Stitch, teams can extract a design system from an existing website or export a project’s rules into DESIGN.md, then reuse that file in another project or another compatible tool.
The exact format is still evolving, but the principle is straightforward. Instead of forcing an agent to infer a product language from screenshots, the file can state the rules explicitly: colour roles, typography, spacing, component conventions and other decisions that define how the interface should be built. Google’s open-source announcement says the draft specification is intended to let those rules work across platforms rather than remain locked inside Stitch. (Source: Google Labs.)
That makes DESIGN.md closer to a contract than a screenshot. A screenshot shows what one screen happened to look like. A design-context file can tell the agent why a colour exists, what a component is for and which decisions should remain consistent when the interface changes.
Open-Sourcing Changes the Story
The first version of this conversation raised an obvious concern: if DESIGN.md existed only as a Stitch-specific convention, it could become another proprietary handoff format. Google’s April 2026 decision to open-source the draft specification makes that criticism less decisive.
It does not make DESIGN.md an industry standard overnight. A draft specification still needs adoption, stable semantics, governance and support from tools that are not controlled by Google. But it creates the possibility that the format can become useful outside the product that introduced it.
An open file format matters only when other tools can trust its meaning. Openness is the beginning of interoperability, not proof of it.
That distinction is important because the design-system ecosystem already has another interoperability effort: the Design Tokens Community Group’s 2025.10 specification. DTCG provides a stable vendor-neutral format for exchanging design tokens across tools and codebases. DESIGN.md is broader and more narrative, while DTCG is narrower and more formal about token data. The two ideas are potentially complementary rather than competitive. (Sources: Design Tokens Community Group; DTCG FAQ.)
Tokens and Context Are Different
A token can tell an agent that color.action.primary resolves to a particular value. It cannot necessarily explain when the primary action is appropriate, how a destructive flow should behave or which layout pattern the product considers canonical.
That is why our guide to design tokens as the API of design treats tokens as one portable layer of the system rather than the entire knowledge model. DESIGN.md is interesting because it points toward a broader package of context: tokens plus conventions, rules and intent.
This is also the practical lesson behind our AI-ready design-system guide. The agent needs explicit semantics, reliable component mappings and rules that explain what it should reuse. Giving a model more pixels is not the same thing as giving it more product knowledge.
Figma Is Solving the Same Problem Differently
DESIGN.md does not make Figma irrelevant because Figma is attacking the same context problem from another direction.
Figma’s MCP server can expose variables, components, layout information and other design context directly to supported agents. When Code Connect is configured, that context can include the real production component import, property values, implementation snippets and custom instructions. In other words, Figma is trying to connect the design object to the code that actually ships rather than reduce the design system to a standalone text file. (Sources: Figma MCP documentation; Figma Code Connect integration.)
These approaches are not mutually exclusive. One future could involve a visual design tool, a portable token format, a text-based context layer and production component mappings all describing different parts of the same system. The important question is whether those layers remain synchronized.
So Is DESIGN.md a Figma Killer?
No, and that framing undersells the more interesting change.
Figma’s value is not simply that it stores colours and components. It is a collaborative environment where teams explore, critique, prototype, document and increasingly connect design to production code. A markdown specification does not replace that social and visual workflow.
What DESIGN.md can challenge is the assumption that the design canvas must be the only place where design-system truth lives. If meaningful product rules can move into portable structured files, repositories and agent context, the centre of gravity becomes distributed. The design file remains important, but it is one consumer and author of shared product knowledge rather than the sole container for it.
The future may not have one source of truth. It may have one coherent set of decisions expressed across several synchronized representations.
What Teams Should Do Now
For most product teams, DESIGN.md is worth experimenting with but not worth reorganizing the whole design system around yet.
- Export one real project. Inspect whether the generated rules describe the product language accurately or merely summarize its appearance.
- Compare it with your existing tokens and documentation. Look for contradictions, missing semantics and duplicated sources of truth.
- Give the file to a coding agent on a contained task. Measure whether it improves component reuse, token compliance and consistency.
- Keep production mappings explicit. A design rule is not enough if the agent still invents components your codebase already has.
- Watch the specification, not just Stitch. The important signal is whether third-party tools begin supporting the open draft and whether the format develops stable governance.
Teams should also avoid turning DESIGN.md into another document that slowly diverges from the system it describes. The value comes from continuity. If the file becomes stale while Figma and production code keep changing, it simply creates a third source of disagreement.
The DesignWhine View
DESIGN.md is still early. The format may change, another specification may win broader adoption, or the useful ideas may disappear into larger design and development platforms.
But the direction is much harder to dismiss. Product teams are moving from design systems that humans can browse toward design systems that software can interrogate. Tokens are becoming portable. Component mappings are becoming machine-readable. Rules are moving into repositories and agent instructions. The system is slowly escaping the canvas.
That is why DESIGN.md matters even if Stitch never dethrones Figma. It makes a larger idea concrete: design intent is becoming infrastructure that can travel, and whichever format makes that intent reliable across people, tools and agents may matter more than the canvas where the first screen was drawn.
