Most AI-generated UIs look the same. Purple gradients on white backgrounds, Inter font everywhere, predictable card layouts, and that unmistakable "I asked an AI to build this" finish. We call it AI slop, and it happens for one reason: the agent had no design system to follow.
At Enpitech, we've been shipping React and Next.js frontends with AI agents for over a year now. The single biggest lever for output quality isn't a better prompt, a smarter model, or a fancier framework. It's a file. A plain markdown file sitting in the project root called design.md.
The Problem: Agents Without Boundaries Build Garbage
Here's what happens when you ask an AI coding agent to "build a dashboard" without design constraints:
It picks whatever font it saw most in training data. It reaches for safe, generic color palettes. It defaults to the same component patterns every single time. And if you're building fifty screens across a product, which is what real projects look like, every screen drifts a little further from the last.
You end up with a Frankenstein UI. Technically functional, visually incoherent. And then a developer spends two weeks reconciling the mess into something shippable. That's not AI-assisted development. That's AI-assisted technical debt.
The Fix: A Single Source of Truth the Agent Can Read
A design.md is exactly what it sounds like, a markdown file that describes your design system in a format both humans and AI agents understand. It includes design tokens (colors, typography, spacing, radii), component patterns, layout rules, and crucially the reasoning behind them.
The concept was recently formalized by Google when they open-sourced their DESIGN.md specification from the Stitch tool in April 2026. But the underlying idea isn't new to us.
I wrote about this on my site months before the Google announcement:
That wasn't a prediction. It was our workflow.
How We Actually Use design.md at Enpitech
Our approach goes beyond dropping a token file in the repo. We treat design.md as a living constraint system — part of the same infrastructure as our CI pipeline, our linting config, and our frontend coding behavior guidelines.
Here's the practical workflow:
1. Define Before You Build
Before a single component gets generated, we write the design.md. Tokens first: primary colors with semantic roles, font stacks with size scales, spacing units, border radii. Then component-level guidance: what a card looks like, how navigation behaves, what states a button has.
This isn't busywork. It's architecture. The same way you wouldn't start coding a backend without a data model, you don't start coding a frontend without a design system.
2. Instruct the Agent to Use Only Those Tokens
The key word is "only." It's not enough to provide the tokens — you have to constrain the agent to them. In our AI Hub skills, we show exactly how to set up these constraints so the agent treats the design.md as law, not a suggestion.
This is where most teams fail. They create a beautiful design system in Figma and expect the coding agent to somehow absorb it through osmosis. Agents don't read Figma files. They read text. Markdown is the format LLMs process best, and a well-structured design.md is the most efficient way to transfer design intent into generated code.
3. Evolve the System as the Project Grows
A design.md isn't a one-time artifact. As the product grows, the system grows. New component patterns emerge. Color tokens expand. Spacing needs adjust for new screen types.
We treat design.md changes like code changes — they go through review, they're versioned in Git, and they propagate to every subsequent generation. When you update the surface color from warm limestone to cool slate, every new screen the agent builds reflects that change. No manual find-and-replace across fifty files.
Why This Matters More Than You Think
The Google Stitch open-source announcement legitimized what practitioners already knew: design systems need to be agent-native. The specification defines nine structured sections — from visual theme and color roles to typography rules and component patterns — all in a format any AI tool can consume.
But here's what the hype cycle misses: the format isn't the hard part. The discipline is.
Writing a design.md is easy. Enforcing it across an entire product, across every agent interaction, across every developer on the team — that's the real skill. It requires:
- Upfront investment in defining tokens before you start building
- Continuous enforcement — checking that generated code actually uses the system
- Evolution without drift — growing the system without breaking what's already built
- Human judgment — knowing when the agent got it right and when the output needs a push
This is what we do at Enpitech. We're a frontend consulting team specializing in React, Next.js, and TypeScript. We sit at the intersection of product thinking and technical execution. And increasingly, that intersection runs through a markdown file in the project root.
The Bigger Picture
The ecosystem is moving fast. The awesome-design-md repository on GitHub gained tens of thousands of stars in its first weeks. Tools are emerging to convert Figma designs into design.md format. Google ships a CLI for validating and exporting design files. And the specification itself, released under Apache 2.0, is open for community contributions.
We see design.md as part of a broader pattern: the agent configuration layer. Just as CLAUDE.md tells a coding agent how to behave in your codebase, and AGENTS.md defines persona boundaries, design.md tells it how your product should look and feel. Together, these files form the instruction set that turns a general-purpose AI into your team's AI.
At Enpitech, we've built skills, workflows, and CI review tools around this exact philosophy. If you want to see how we structure a design.md for real projects and how we teach agents to follow it, check out our AI Hub.
Design system is law. Pixel-perfect follows.
Enpitech for Startups. React · Next.js · TypeScript · AI Integration.
