DEV Community: Ashmeet

The Missing Layer Between AI and Design Consistency

Ashmeet — Fri, 01 May 2026 00:31:37 +0000

By now, "vibe coding" is completely normalized. You describe a thing, AI builds it, you nudge it until it gets it right. Nobody bats an eye.

But what about vibe designing?

The idea has come up in cycles. AI-generated UI, prompt-driven mockups, no-Figma workflows. Every time it almost gets traction, it fizzles. The outputs are too generic, you lose control of consistency, or it only works for throwaway prototypes you'd never ship.

I've been poking at Google Stitch lately, and something about it finally made the concept feel workable. Specifically DESIGN.md, a spec format that quietly reframes how AI and design systems talk to each other. Google open-sourced it last week under Apache 2.0, so any agent that writes UI code can use it, not just Stitch.

What Even Is Google Stitch?

Stitch is Google's AI-native design tool. You describe an app (vibe, colors, features), it generates screens, you iterate on them with natural language. There's code export, a component system, an MCP server, and agent skills that plug into your existing coding setup.

Earlier this year they shipped a significant update: an AI-native infinite canvas, a smarter design agent that reasons across entire projects, voice input, multi-screen generation, and design system support including DESIGN.md.

A Markdown File as Your Design Contract

DESIGN.md isn't merely a style guide you write once and forget. It's a machine-readable contract between your design intent and whatever AI is building your UI.

You export it from Stitch, and it contains your color tokens, spacing values, rounding rules, typography - everything. Structured as YAML, inside a markdown file. It's readable by humans and by agents. It works with Claude Code, Cursor, Copilot, Gemini CLI, anything that writes UI code.

The practical upside: changes to your design propagate automatically. Non-developers can update the design in Stitch without touching the codebase. It's also useful for catching drift, e.g., components that have wandered from the source of truth show up clearly when you have a spec to check against.

Part 1: The Static Export

I started with the simplest path. Export DESIGN.md from a Stitch project (a toy music player) and hand it to Gemini CLI as context in the project root.

A trimmed look at the generated DESIGN.md:

---
name: Lumina Audio
colors:
  surface: '#12121d'
  surface-dim: '#12121d'
typography:
  display-lg:
    fontFamily: Be Vietnam Pro
    fontSize: 48px
rounded:
  sm: 0.25rem
  DEFAULT: 0.5rem
spacing:
  unit: 8px
  container-padding: 32px
---

## Brand & Style

This design system is built for an immersive, high-fidelity desktop music experience. It leverages **Glassmorphism** to create a sense of depth and airiness, making the interface feel like a digital lens over a living, breathing soundscape. 

## Colors

The palette is rooted in a deep, nocturnal neutral to allow vibrant accents to pop. The primary, secondary, and tertiary colors are designed to be used within mesh gradients for the application background, creating a "lava lamp" effect that shifts behind the frosted glass panels.

- **Display Type:** Large headlines use a tighter letter spacing and heavy weights to anchor the layout against the soft glass backgrounds.

## Layout & Spacing

The layout follows a **Fluid Grid** model with high-margin "safe zones" to allow the background gradients to frame the content. 

## Elevation & Depth

Depth is not communicated through traditional shadows, but through **cumulative backdrop blurring** and **border luminosity**.

The question: could the agent generate a UI just from the spec file, without seeing the actual Stitch screens?

Short answer: kind of.

The agent respected the design system. Colors, spacing, and typography all came through correctly. But it didn't reproduce the screens. It's like giving someone the same bricks from your house and expecting them to build the same house but without ever actually seeing it.

There's a gap between "follows the rules" and "knows what the layout looks like." DESIGN.md tells the agent how things should look, not what things should exist.

So if you're hoping the file alone bridges design and code, it gets you maybe 60% of the way there. The tokens are right. The vibe is right. The actual layout structure? That's not in the file.

Part 2: Adding the MCP

To close that gap, I connected Stitch directly to Gemini CLI via MCP. This is the difference between handing the agent a style guide and giving it actual eyes on your project.

Step 1: Get a Stitch API key

Go to stitch.withgoogle.com, sign in, open profile settings, and create a key under the API Keys section.

Step 2: Add the MCP server

gemini mcp add stitch --transport http https://stitch.googleapis.com/mcp \
  --header "X-Goog-Api-Key: YOUR_API_KEY"

Step 3: Verify it connected

Restart Gemini CLI. Inside your session, run:

/mcp list

You should see the Stitch server listed with its available tools. From there, you can prompt it like:

Stitch, extract the design context from my 'Lumina' project into DESIGN.md.

Stitch, give me the React code for the sidebar component.

Once the MCP was connected, the agent wasn't just following rules from a file. It could query actual layout data from my Stitch project. That's when the generated screens started matching what I'd designed in the Stitch canvas.

What Actually Came Out of It

The refinement loop is where this got genuinely interesting. I changed primary in DESIGN.md from #ecb2ff to #00ffcc, told the agent to sync, and it updated tailwind.config.js and the components together. One instruction, consistent everywhere.

The result of adding a fresh page that still convincingly respected the design system of the app:

The outputs were coherent in a way that AI-generated UI usually isn't, because there was an actual spec anchoring everything. I prompted, it generated, I nudged, it regenerated. Nothing drifted. The agent always had something to check itself against.

That's the thing that's been missing from vibe designing. Not better generation, but something to keep the generation consistent.

A Couple of Honest Caveats

Stitch works best when you're incremental. "Make the primary button larger and use the brand blue" lands better than "redesign the login screen." One thing at a time, especially early in a project.

DESIGN.md is also still in a sort of public beta. The spec and token schema are under active development, so things might change.

Why I Think This Is Interesting Anyway

Vibe coding caught on because it lowered the floor for building. You didn't need to know every pattern, you could describe what you wanted and iterate towards it.

Vibe designing always had the same promise but kept stumbling on the same problem: consistency. One-off mockups are easy. A coherent design system, maintained across an entire app, updated by prompts without breaking things, is hard.

DESIGN.md is a direct answer to that problem. It gives the AI something to stay consistent against, not just vibes in, vibes out. And because the spec is agent-agnostic, it's not tied to any one tool in your workflow.

The static export gets you the spec. The MCP gives the agent eyes on your actual design. Together they're the most credible version of vibe designing I've seen so far.

Fair warning: I'm not a designer or a senior dev, I'm still figuring this out too. If you've tried Stitch, I'd genuinely love to hear how you're using it and what else you're pairing it with!

Are you ready to take the Happy Pill? 💊

Ashmeet — Sat, 11 Apr 2026 08:02:08 +0000

This is a submission for the DEV April Fools Challenge

What I Built

Let’s face it. Developers are a moody bunch. You can wallow in your undefined is not a function errors for only so long before that frown holds you back from providing real shareholder value.

This is why I built Happy Pill, an enterprise-grade wellness solution that ensures your engineering team maintains peak performance.

This April, sadness is a privilege, not a right. KEEP GRINNING.

Demo

It plays exactly one song - Happy by Pharrell Williams. This isn't a bug, seriously. Stop smiling? Your listening privilege is immediately revoked until you smile again. That’s your new performance metric. There’s a grace period of 5 seconds at the beginning for a smooth onboarding, so don’t worry!

👉🏼 Live project (fallback no-api-key version with smile simulated through a toggle)

And because misery loves company, your non-compliance for more than 15 seconds will trigger a cup of coffee for you. Of course, to only then be served a 418 I’m a Teapot error instead. Because even the server is judging you.

Code

ashmeet-chhabra / happy-pill

Happy Pill

This is a submission for the DEV April Fools Challenge

Getting Started

Prerequisites

Node.js (v18 or later recommended)
A modern web browser with webcam support

Installation

Clone the repository:

git clone https://github.com/ashmeet-chhabra/happy-pill
cd happy-pill

Install dependencies:
```
npm install
```
Set up a Gemini API key for automatic smile detection:
- Create a .env file and add:
```
VITE_GEMINI_API_KEY=your_api_key_here
```
- If you skip this step, the app will automatically enable the manual smile toggle as a fallback, allowing you to control the smile state manually.

Running the App

Start the development server:

npm run dev

Open your browser and navigate to the local server address provided in the terminal.

Project Structure

src/components/ – UI components (Header, WebcamPreview, StatusPanel, ControlsBar, YouTubePlayerPanel, FrownPopup)
src/hooks/ – Custom React hooks for camera, smile analysis, and YouTube player logic
src/services/ – Service modules for camera, Gemini API, and YouTube integration
src/types/ – TypeScript type definitions
public/418.html – Custom…

View on GitHub

How I Built This Utopian Smile Police

The whole system runs on a carefully calibrated feedback loop: camera detects face → AI analyzes smile → playback responds instantly → UI updates to reflect your current compliance status.

React + TypeScript: Because every project deserves type safety, even this one. I ensure the app fails gracefully with proper error messages when it inevitably breaks.

YouTube IFrame API: To help hold you hostage to Pharrell Williams' Happy on loop.

Tailwind CSS: For that sleek, surveillance-state aesthetic uwu

Gemini Integration: More on that in the next section. (face-api.js who 👎🏼🍅)

Prize Category

Best Ode to Larry Masinter: duh

Best Google AI Usage: The heart of this innovation! I used Gemini 3.1 Flash-Lite, Google AI’s fastest low-latency high volume model.

Using cutting-edge, state-of-the-art AI to monitor your smile is most agreeably the need of the hour, just as it is to scaffold and overengineer an app for a zero-tolerance risk project like this. For that I turned to Gemini Code Assist which came handy right there in my IDE building this revolution with me.