A client sent us 62 Midjourney images as a moodboard last spring. Sixty-two. Three of them were usable, and the other fifty-nine were the same hero shot with slightly different lighting. That project ran two weeks over, not because the AI was bad, but because nobody had decided what the images were for before generating them.

That’s the shape of most AI failures in design work right now. The models are good. The generation step is nearly free. What’s expensive is everything on either side of it: deciding what to ask for, and deciding what to keep. An ai web design workflow that actually ships is mostly a curation and constraint system with some generation bolted into the middle.

Here’s how we run it across client projects in 2026, including the parts that still don’t work.

The honest ledger of what AI saves

We track hours per phase on client work. On a typical 12 to 18 page marketing site, the split before we used AI seriously looked roughly like: discovery and direction 15 percent, visual design 35 percent, markup and styling 30 percent, content and QA 20 percent.

After two years of restructuring around ai design tools, the visual design block shrank hard. Exploration that used to take three days of comping takes an afternoon. The markup and styling block barely moved, and QA got bigger. Generated code needs more review than code a developer wrote, because the failure modes are subtle: a plausible-looking heading hierarchy that skips from h2 to h4, a focus style that was silently removed, a grid that collapses at 390px because nobody tested a real phone width.

Net saving across the project: somewhere between 20 and 30 percent of total hours. Real, worth having, and nothing like the 10x that tool marketing implies. If someone tells you they’ve cut build time by 80 percent, ask to see the accessibility audit.

Moodboards: generate less, decide more

The failure with that 62-image moodboard wasn’t volume, it was that no constraints existed. A moodboard’s job is to eliminate directions, not collect them. So we now write the constraint document first, before anyone opens an image model.

It’s short. Six lines, usually:

• Three adjectives the brand must feel like, and two it must never feel like. The negatives matter more.
• Named references with reasons. “Like Linear’s spacing discipline, not like Linear’s colour palette.”
• The actual content constraints: longest headline in characters, whether there are real product photos or stock, how many nav items.
• Technical constraints: dark mode required, RTL required, must run on a shared host with no build step.

Then we generate maybe 12 to 16 images across four distinct directions, kill three directions by lunchtime, and develop one. The point of the AI here is that killing a direction now costs twenty minutes instead of two days, so you can afford to be ruthless. Clients pick faster when you show them three genuinely different options instead of nine near-identical ones.

One warning that has bitten us: never show a client an AI-generated hero image unless you can reproduce it in the real build. We’ve had to talk a client down from a photographic composition that would have required a two-day studio shoot. Label every generated image as “mood, not asset” on the board. In writing.

Tokens are the contract

The single change that made generated code usable was moving the design system definition upstream of everything else. Before any markup gets generated, we have a token file. Colour, type scale, spacing scale, radii, shadow, breakpoints. Nothing else is allowed into the CSS.

// tokens/build.js  -- compiles tokens.json to CSS custom properties
import { readFileSync, writeFileSync } from 'node:fs';

const tokens = JSON.parse(readFileSync('tokens/tokens.json', 'utf8'));

// Flatten nested groups into kebab-case var names: color.brand.500 -> --color-brand-500
const flatten = (obj, path = []) =>
  Object.entries(obj).flatMap(([key, value]) =>
    value && typeof value === 'object' && !('$value' in value)
      ? flatten(value, [...path, key])
      : [[--${[...path, key].join('-')}, value.$value ?? value]]
  );

const vars = flatten(tokens)
  .map(([name, value]) =>   ${name}: ${value};)
  .join('\n');

writeFileSync('src/css/tokens.css', :root {\n${vars}\n}\n);

That file is then the only source of truth you hand to any generator, human or otherwise. The rule we enforce in review: if a generated stylesheet contains a raw hex value, a px font size or a magic margin, it gets rejected. Not debated. Rejected.

This is boring and it’s the whole trick. Models are excellent at pattern-matching to an existing vocabulary and terrible at inventing a consistent one. Give them the vocabulary and the output quality jumps. Give them a blank canvas and you get seventeen shades of grey across four pages.

An ai web design workflow that survives a real project

Here’s the actual sequence we run, with the tool at each step and, more usefully, the gate that has to pass before moving on.

1. Constraint doc (human, 45 minutes). Gate: client signs the adjectives.
2. Direction exploration (image model, half a day). Gate: three distinct directions, one chosen.
3. Token definition (human, half a day). Gate: contrast ratios checked against WCAG 2.2 AA before a single component exists.
4. Layout comps for key templates only (Figma plus AI assist). Home, one interior, one form page, one dense data view. Not every page. Gate: responsive behaviour is annotated, not implied.
5. Component generation (coding assistant with repo context). Gate: markup passes the semantic checklist below.
6. Assembly and content (human). Gate: real copy, real image weights, no lorem ipsum in a review build ever.
7. Automated audit (CI). Gate: axe-core clean, Lighthouse performance above 90 on throttled mobile.

Step 4 is where most teams over-invest. You do not need comps for twenty pages. You need comps for the four layout archetypes the site actually uses, and then a component library those pages are assembled from. If you’re building anything with a dense interface, the patterns in our admin dashboard layout guide will save you from designing the same sidebar three times.

Design to code AI: what the generators still get wrong

Every Figma-to-code product has improved. Visual Copilot, Anima, Figma’s own code output, plus the general assistants reading a screenshot. They all share the same three defects, and they’re structural rather than incidental.

1. Absolute positioning instead of flow

Design files store coordinates. Translators reach for those coordinates. You get nested divs with fixed heights that look perfect at one viewport and shatter everywhere else. Fix: explicitly instruct output as flex or grid with logical properties, and reject anything with a hard-coded height on a text container.

2. Non-semantic elements

A button drawn as a rectangle becomes a div with a click handler. A list becomes six sibling divs. This is the failure that costs the most later, because it also takes your keyboard navigation and screen reader output with it. We see the same handful of issues in audits repeatedly, and most of them trace back to this one root cause. Our write-up on the five accessibility failures auditors always find is basically a list of things generators do by default.

3. Class explosion

Twelve utility classes on every element, no reusable component class, nothing you can restyle globally. Fine for a prototype. Miserable at month six.

The counter-measure is giving the model an existing component as the target shape. Not a description of the component. The actual file.

<!-- Reference component passed as context. Generator must match this structure. -->
<article class="card">
  <a class="card-media" href="{{url}}">
    <img src="{{src}}" alt="" width="640" height="360" loading="lazy" decoding="async">
  </a>
  <div class="card-body">
    <h3 class="card-title"><a href="{{url}}">{{title}}</a></h3>
    <p class="card-text">{{excerpt}}</p>
  </div>
  <footer class="card-footer">
    <!-- datetime attribute is machine-readable; visible text stays human -->
    <time datetime="{{iso}}">{{human_date}}</time>
  </footer>
</article>

This is also the strongest argument for starting from a mature component library rather than generating one. When we build on Canvas, the Bootstrap 5 structure is already there, the dark mode variables are already wired, and the assistant’s job shrinks to composition rather than invention. Composition is what these models are good at.

If you’re wiring assistants into your repo properly, standardised context servers are worth the setup. We covered the mechanics in why MCP matters for tooling.

The review gates, in order of how much they save you

Run these automatically. Manual review of generated code degrades fast because it all looks plausible.

# Fails the build on any serious a11y violation in the built HTML
npx @axe-core/cli http://localhost:4173 --exit --tags wcag2a,wcag2aa

Catches skipped heading levels, missing lang, duplicate IDs
npx html-validate "dist/**/*.html"

Budget enforcement, not vanity scoring
npx lhci autorun --collect.settings.preset=desktop

Add one custom check that has caught more regressions for us than any linter: grep the built CSS for hex values outside the tokens file. Three lines of shell, and it enforces the contract from earlier.

# Any hex literal in component CSS means the token contract was broken
grep -rEn '#[0-9a-fA-F]{3,8}\b' src/css --exclude=tokens.css && \
  { echo "Raw colour found. Use a token."; exit 1; } || exit 0

Who does what now

The job that evaporated is production comping: producing the twentieth artboard so the client can see the About page in the agreed style. Nobody should be doing that manually in 2026.

What got more valuable is unglamorous: writing the constraint doc, owning the token file, doing the content audit, and reviewing generated markup with actual judgement. Designers who moved into systems thinking are busier than ever. Designers who defined their value as pixel output are having a hard year, and pretending otherwise doesn’t help anyone.

For developers, the shift is that prompting is now a maintained artefact. We keep component generation prompts in the repo next to the components, versioned, because when a model updates the phrasing that worked in March might not in September. The patterns that hold up across model versions are covered in prompt engineering for developers, and the maintainability side in using AI to write code you can actually maintain.