cd /news/ai-tools/i-gave-up-on-making-my-ai-builder-wr… Β· home β€Ί topics β€Ί ai-tools β€Ί article
[ARTICLE Β· art-16881] src=dev.to β†— pub= topic=ai-tools verified=true sentiment=Β· neutral

I gave up on making my AI builder write good media queries

A developer abandoned attempts to make an AI website builder generate proper desktop layouts through prompt engineering after two weeks of failed iterations. The engineer found that large language models consistently produced well-designed mobile experiences but thin, underdeveloped desktop versions, a problem that persisted across four different model endpoints. The solution was switching the generation system to Tailwind CSS via CDN, which forced the model to explicitly define desktop-responsive utilities through its built-in prefix system.

read5 min views21 publishedMay 28, 2026

Every site my AI website builder produced looked great on a phone and weak on a desktop. The hero stretched edge-to-edge in a single anemic column. Features grids stayed at one column on a 27" monitor. Section padding that felt generous on mobile felt empty at desktop widths.

I spent two weeks trying to fix this from the prompt side. None of it worked the way I wanted. Then I gave up on the approach entirely and switched the generation to Tailwind via CDN. The desktop problem disappeared.

This is the writeup of why the original approach was wrong, what I tried first, and the specific change that mattered.

The system prompt told the model to write mobile-first CSS:

Default CSS targets mobile (≀480px); layer up with

@media (min-width: 768px)

and(min-width: 1024px)

.

Models followed the instruction. They wrote good mobile rules. Then they wrote thin, half-hearted desktop overrides β€” a max-width here, a media query for two-column layout there. Critical things were missing: bounded container widths, real multi-column grids, typography that genuinely scaled up, deliberate section padding rhythm. Desktop wasn't broken β€” it was underdesigned. The mobile rules absorbed most of the model's attention budget.

This wasn't a one-model problem. I tested four (Cerebras GPT-OSS 120B, Groq Llama 4 Scout, Cloudflare Qwen3 30B, OpenRouter free auto-router). All four showed the same pattern. The strongest model produced the most polished mobile experience and still had thin desktop.

Round 1: explicit desktop rules in the prompt.

Desktop must be a designed experience, not a stretched mobile view:
- Every major section uses a bounded container (max-width 1100–1280px).
- Multi-column grids on desktop (3-col features, not 1-col).
- Typography scales up: hero β‰₯ clamp(2rem, 6vw, 5rem), body 16–18px.
- Section padding visibly larger on desktop.
- Real horizontal nav on desktop (no permanent hamburger).

Helped, maybe 20% better. Not enough. Models still hand-wrote breakpoints one at a time, often forgot the container, often kept padding mobile-sized.

Round 2: an anti-patterns list.

- Desktop that looks like a stretched mobile view.
- Hero full-width on a 1440px screen with content centered in a phone column.
- Single-column features grid on desktop.

Marginal again. The fundamental problem was that the model had to re-invent responsive CSS from scratch on every generation. With finite tokens of attention, it allocated effort to whatever was first and most reinforced β€” which was mobile.

Asking an LLM to hand-write mobile-first responsive CSS is a bad task to ask an LLM. It's brittle, repetitive, and the model has to make the same dozen decisions every time.

But LLMs are great at Tailwind. They've seen millions of class="grid grid-cols-1 md:grid-cols-3"

examples in their training data. The responsive prefix system is mobile-first by definition β€” every md:

and lg:

utility is a desktop affordance the model adds deliberately, one piece at a time, because the syntax forces it.

I switched the generation system to require Tailwind via CDN. The desktop problem solved itself.

1. Mandate the CDN script and inline config in <head>:

<script>
  tailwind.config = {
    theme: {
      extend: {
        colors: {
          brand: '#3b82f6',
          accent: '#f43f5e',
          surface: '#0a0a14',
        },
        fontFamily: {
          display: ['"Space Grotesk"', 'system-ui', 'sans-serif'],
          body: ['Inter', 'system-ui', 'sans-serif'],
        },
      }
    }
  }
</script>
<script src="https://cdn.tailwindcss.com"></script>

Order matters β€” the config has to be parsed before the CDN script initializes, otherwise custom colors silently fail.

2. Make desktop equally first-class in the prompt:

## RESPONSIVE β€” MOBILE-FIRST, DESKTOP EQUALLY FIRST-CLASS
Tailwind is mobile-first by default. Responsive prefixes (sm: md: lg:) are
how desktop gets designed deliberately β€” not as an afterthought.

- Container: <div class="mx-auto max-w-7xl px-4 sm:px-6 lg:px-8">
- Multi-column grids: grid-cols-1 sm:grid-cols-2 lg:grid-cols-3
- Hero: lg:grid-cols-2 (split) or lg:grid-cols-5 (asymmetric)
- Type: text-3xl sm:text-5xl lg:text-7xl for headlines
- Padding: py-12 sm:py-20 lg:py-28 for section spacing
- Nav: hidden md:flex on the menu, md:hidden on the hamburger

Notice every rule has an md:

or lg:

prefix. The prompt isn't asking the model to invent breakpoint logic β€” it's asking the model to append responsive prefixes to utilities it already knows. That's a much smaller task. And smaller tasks for LLMs produce dramatically more consistent output.

3. A final-check block at the end of the prompt:

## FINAL CHECK
Before emitting your response, verify that <head> contains BOTH:
  1. <script>tailwind.config = { ... }</script>
  2. <script src="https://cdn.tailwindcss.com"></script>
If either is missing, every Tailwind class in your output renders nothing.

This last one matters. Without it, my first round of Tailwind output had models that wrote Tailwind classes but skipped the CDN script. The page rendered as raw unstyled HTML β€” every class a silent no-op. The final-check section dropped that failure mode close to zero.

Desktop output went from a recurring complaint to a non-issue. Single-page sites now have:

None of this is the model "trying harder." It's the model being asked to do something it's good at instead of something it's mediocre at.

When an LLM is producing mediocre output on a task, the first instinct is to fix the prompt. Add more rules. Add examples. Add anti-patterns. Each helps marginally.

The higher-leverage move is to ask whether the task is wrong. Is there a primitive the model is already great at that maps to your problem?

If the answer is yes, the rewrite tends to be smaller than the prompt-tuning rabbit hole you were heading down, and the quality ceiling is much higher.

I lost two weeks before making this switch. The prompt-side fixes felt productive β€” each one moved the needle a little. The structural fix took a few hours and moved it more than all the prompt fixes combined.

Try it live: wiz-craft.vercel.app β€” open source on GitHub. Four free open-source models, generates Tailwind-styled single-page sites from a prompt, streams the iframe live as the model writes. Built with Claude.

More on the four providers I'm using: I tested 4 free 70B-class LLM endpoints for real production work.

── more in #ai-tools 4 stories Β· sorted by recency
── more on @tailwind 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain β€” perfect for shipping the agent you just read about.

$git push zahid main
β†’ Live at https://your-agent.zahid.host βœ“
Get free account β†’ Pricing
from €0/mo Β· no card required
LIVE [news/i-gave-up-on-making-…] indexed:0 read:5min 2026-05-28 Β· β€”