AI Proposes. The Design System Disposes.

Go to southleft.com, find the palette icon in the header, and type a phrase. Anything. “Children’s coloring book,” “hardcore brutalist,” “cathedral at dawn.” In about a second the entire site rebuilds around your words. Not a preview card. The actual site you’re standing on: its colors, its fonts, its corner radii, its shadows, the density of the layout, the texture behind the hero, even the physics of how things animate.

It’s a fun toy. People have been having a good time with it. But the toy is not the point, and if you walk away thinking “neat AI trick,” I’ve failed to explain the thing I actually care about.

The point is this: an AI wrote none of that CSS. It didn’t touch a single pixel. It proposed a handful of parameters, and a design system turned those parameters into a coherent, accessible, on-brand interface. The same way a design system is supposed to turn any input, human or machine, into coherent output.

That’s the whole business. Let me back up.

What Southleft actually is

We’re a design systems and AI agency. That pairing confuses people, because “design systems” sounds like a 2019 conversation about button components and “AI” sounds like a 2025 conversation about everything, and the two don’t obviously belong in the same sentence.

They belong in the same sentence because of a claim I’ll defend for the rest of this piece: AI is only as good as the structured context it can reach. Point a coding agent at a codebase with clean, semantic design tokens and a well-documented component API, and it ships UI that matches your product on the first pass. Point that same agent at a pile of hardcoded hex values and one-off components, and it guesses. Plausibly, confidently, and wrong. It generates drift. It creates the exact technical debt you hired it to eliminate.

The design system is not a nice-to-have that sits next to your AI strategy. It is your AI strategy’s substrate. The teams pulling real speed out of AI tooling right now are the ones who did the boring foundational work first. Everyone else is generating inconsistency at scale.

So when it came time to rebuild our own site, I didn’t want a brochure. I wanted the site to be the argument. A working proof that a well-built token architecture is what makes AI useful, demonstrated on the one product I could afford to experiment on: our own.

The stack, and why it’s boring on purpose

southleft.com is Astro with Tailwind CSS v4, static output, deployed to Cloudflare Pages. There is no CMS and no database. Blog posts and case studies are markdown files in the repo. The design token layer lives in one CSS file. That’s it.

The boringness is deliberate. Static output means every page is a plain HTML file that loads instantly and can’t fall over. Markdown-as-source means the content is version-controlled, diffable, and, critically, machine-readable, which matters more every month. We publish a /llms.txt at the root: a plain-language map of the whole site for any AI tool that wants to understand what we do without scraping and guessing. We eat our own dog food there too.

But the load-bearing decision, the one everything else hangs off, is how color and type and space are defined. Nothing in this site hardcodes a value. Every color, every font, every radius and shadow and duration comes from a semantic token layer built in three tiers, the way tokens are supposed to be built:

• Primitives. The raw palette. --sl-color-red-500 is a specific hex value and nothing more.

• Semantic aliases. Meaning, not value. --sl-accent points at a primitive. --sl-bg, --sl-fg, --sl-border. These are what components actually consume. A component never knows it’s red. It knows it’s “accent.”

• Component-level. Where a specific piece of UI needs its own decision, it references the semantic layer, never the primitive.

This is Design Systems 101. I’m not claiming novelty. I’m claiming that the discipline of never letting a component touch a raw value is precisely what buys you everything interesting later. Because the moment a component reads --sl-accent instead of #f05735, you can change what --sl-accent means and the entire site agrees, instantly, with no code changes and no components touched.

That property, change one token and everything follows, is the entire thesis of design systems. And it turns out to be the entire mechanism behind the AI demo too. They’re the same fact.

Change one token. Then let AI change all of them.

On the homepage there’s a small interactive panel: flip an accent swatch, nudge a radius, toggle ink-vs-paper, and a little mock product UI re-skins itself in real time. It’s the manual version of the argument. One token moves, everything downstream agrees. No magic, just the alias layer doing its job.

The theme console is that same argument with the ceiling removed. Instead of you moving one token, you describe a vibe, and an AI moves all of them at once. About 44 tokens spanning color, typography, shape, elevation, texture, and motion. Same underlying mechanism. Same alias layer. The only new thing is who’s turning the knobs.

Here’s how it actually works, because the division of labor is the whole insight:

1. The AI is the art director. When you type a prompt, it goes to a small serverless function (a Cloudflare Pages Function) that calls Claude with a strict JSON schema. Claude doesn’t return CSS. It returns decisions: a personality (editorial, brutalist, geometric, luxe, playful, or a hand-drawn “sketch” mode), an accent hue, how much color the background canvas itself should carry, a texture, a motion feel, whether the site should lead light or dark, and a typeface, chosen from a curated catalog or, when nothing fits, any family in the entire Google Fonts library. (”Vintage typewriter manuscript” made it reach for Special Elite, unprompted. It also names every theme it makes, with attitude. “Cathedral at dawn” came back as “matins in gold, light enters slowly, we do not rush the divine.”)

2. The design system is the guardrail. Those decisions are parameters, not output. A small color engine running in the browser takes the hue and chroma the AI proposed and derives the full palette in OKLCH, a perceptual color space where “make this readable” is a math problem instead of a vibe. For every foreground/background pair, it binary-searches the lightness until the combination clears its WCAG AA contrast target. Then it writes the results into the semantic token layer, and the alias re-point does the rest. The whole site follows.

3. Therefore the AI cannot ship an inaccessible theme. This is the part I want to underline. The model proposes, the solver disposes. If Claude suggests a hue that would produce unreadable text, the solver corrects the lightness until it passes. By construction, not by luck, not by hoping the model got it right. The console even prints the receipts as it works: fg/bg 15.7:1 ≥ 7:1 ✓, live, so you can watch it prove itself. Type “electric neon on white” and it will not give you illegible neon-on-white. It gives you the boldest version of that idea that a person can actually read.

A variety of design expression via customized token theming

AI proposes. The design system disposes. That sentence is the product. It’s also, not coincidentally, exactly what we tell clients: don’t ask AI to be the taste and the guardrails and the accessibility conscience all at once. Ask it to propose within a system that already encodes those things. The system is where correctness lives. The AI is where speed lives. You want both, and you get both only if you built the system first.

A few implementation details that are fun and true:

• Themes crossfade, they don’t snap. The semantic color tokens are registered as typed CSS custom properties (@property with a <color> syntax), which means the browser can interpolate them. Change the theme and the entire site melts from one brand universe into the next over about 600ms. The existing light/dark toggle inherited that morph for free. A nice reminder that when you build a mechanism well, benefits compound.

• There’s a deterministic engine underneath the AI. Before Claude answers, a local seed engine derives an instant theme from the same prompt using keyword-to-hue maps and mood-to-chroma rules, so the site never blocks on the network, and if the AI endpoint is ever down, the console still works. The AI refines. It isn’t a single point of failure. (Also: this local engine is the “make it simple enough for a small model to run” version people keep asking about. The JSON schema is the contract. Anything that can emit that shape can be the art director.)

• Fonts load on demand, from a privacy-clean mirror. A normal visitor downloads zero extra font bytes. The moment a theme picks a catalog face, the stylesheet is injected, served from a GDPR-friendly Google Fonts mirror, because a consultancy that will get asked about tracking should have a good answer ready.

• Every generated theme is a shareable URL and an exportable token file. You can copy a link like southleft.com/#theme=cathedral at dawn and send someone straight into a theme, or export the whole generated palette as standards-format design tokens. The output of the toy is real design-system artifact.

The receipts go all the way down

Here’s the detail I’m proudest of, and the one that best captures the whole ethos. We publish our token layer at /tokens.json in DTCG format, the open standard for design tokens, so any tool, human or agent, can consume the exact vocabulary the site runs on.

For a while, that file was a hand-maintained snapshot. And like every hand-maintained snapshot in the history of software, it drifted. It was written before the theme engine existed and had quietly fallen forty-odd tokens behind reality. Someone (fine, it was me) had a hunch and checked. It was stale.

So we fixed it the way you’re supposed to fix drift. We removed the possibility of it. /tokens.json is now generated at build time by parsing the actual CSS. The stylesheet is the single source of truth. The published token file is a build artifact of it, with assertions that fail the build loudly if a future refactor ever breaks the parse. The file can no longer drift from production because production is where it comes from. Its own description says so: “Generated at build time from the stylesheet the site runs on. Yes, we practice what we pitch.”

That’s a small thing. It’s also the entire method. Single source of truth. Generate, don’t duplicate. Make the correct state the only possible state, so nobody has to remember to keep two things in sync. Do that at the token layer, and an AI agent pointed at your system inherits a foundation it can trust. Skip it, and you’re back to the pile of hex values, and no amount of clever prompting saves you.

The site is the pitch

I keep coming back to the same shape. The manual token panel and the AI theme console are the same argument told twice, one at human speed, one at machine speed. The crossfade is just the alias layer doing its job with the lights on. The contrast solver is the accessibility discipline we’d apply by hand, encoded once so it applies everywhere automatically. The self-generating tokens.json is single-source-of-truth taken to its logical end. None of these are separate features. They’re the same principle, decisions live in the system, not scattered across the surface, viewed from different angles.

And that principle is the actual work. When we help a team get “AI-ready,” this is what we mean. Not bolting a chatbot onto a product, but building the token architecture, the component API, the design-to-code parity, and the machine-readable documentation that let AI operate inside a system that makes bad outcomes structurally difficult. The tools we build and open-source, an MCP server that gives agents real access to Figma, a generative layout tool for Storybook, a design-system knowledge base your AI can query, a CLI that audits how AI-ready your system already is, are all downstream of the same conviction. They’re how we test our own thesis in public before we bring it to a client.

We rebuilt our website to prove the thesis on ourselves first. The re-theming demo travels because it’s delightful, but delight was never the goal. The goal was to make something undeniable: this is only possible because the foundation is solid. Take away the token architecture and there’s no demo. There’s just an AI generating inaccessible, off-brand CSS very quickly, which is a downgrade, not a feature.

If your design system can’t do what ours just did, that’s not a knock on your team. It’s a map. The gap between “we have components” and “an AI can re-derive our entire product from a sentence and stay accessible” is exactly the work, and it’s the highest-leverage work you can do before AI tooling is anything other than a liability.

Go type something into the site. Then ask yourself what it would take for your product to do the same. That question is the whole conversation, and it’s the one we like having.

---

Southleft is a design systems and AI-driven product development consultancy. We open-source the AI tooling we use to do the work. If your design system’s readiness is a question you’d rather answer than assume, we built a scorecard for that. Score yourself in ten minutes, no email gate.