Ask an LLM to build you a landing page that is on brand, then open a new window and ask it again. Now do that with every component on the page, down to a simple text link.
You’ll get a different result every time.
It may all be defensible, and roughly on-brand, but no two will be the same, and if you’re building one page, that’s fine; pick the outcomes you like and move on.
Now do that within an established ecosystem, or across multiple team needs, hundreds of times, week in and week out, across any platform.
That’s where vibe coding stops being magic and turns into a liability. The model didn’t get worse; the input never got better.
The problem isn’t the model. The problem is what you’re feeding it.
Most teams ask an LLM to visualize a specific client by providing it with a PDF of its brand guidelines, a few screenshots, and written creative direction for the brand’s vibe. “Modern but warm.” “Confident, not loud.” “Think Scandinavian, but for insurance.”
That language is doing real work, but only for humans. A Creative Director reads “confident, not loud” and knows exactly which of the four brand colors to reach for, because they’ve absorbed a decade of context about what that phrase means in practice.
A model has no such context. Give it a vibe, and it returns a plausible sample, one that is different every time you ask.
You cannot prompt your way out of this. Better prompts narrow the distribution; they don’t collapse it. As long as the brand serves only as a guidepost, the output will be only an approximation.
What a brand looks like when a machine can read it
The fix is to stop describing the brand and start defining it.
“Here’s our primary blue” is still too coarse. It tells the model what the color is, not when to use it, what it means, or what it becomes in dark mode, a disabled state, or an email client that doesn’t support custom properties.
You have to go further down past components, past styles, to what I’ve started calling the subatomic layer: the smallest decisions a brand makes, expressed as structured, named, machine-readable values, with the relationships between them made explicit. It’s the underdrawing, the sketch beneath the painting that nobody sees and everything sits on.
Not #C08765.
But a primitive that holds the value. A semantic token that says this is the action color. An appearance state that says what happens on hover, on focus, when disabled. A mode that says what all of that becomes on any system. And a component that consumes those tokens rather than hardcoding anything.
Now the brand isn’t a description but a data structure.
There are now rules in place the model must follow. Ask for a button ten times, and you get the same button ten times, because “the action color for a hover state of a medium button” resolves to exactly one value.
That’s the whole trick: you don’t make an LLM more consistent by constraining the output. You make it consistent by structuring the input and providing an underdrawing it must follow.
Guardrails, not vibes
The instinct when an LLM output goes sideways is to add more review. More human QA at the end of the pipeline, catching drift before it ships.
That scales linearly with volume, which is another way of saying it doesn’t scale at all. If your output goes up 10x, your review burden goes up 10x, and the humans doing the reviewing are the same people you needed for the actual creative thinking.
Tokenization moves the control point. Instead of catching mistakes at the end, you make certain mistakes structurally impossible at the beginning. The model can’t invent an off-brand blue if the only blues available to it are the ones in the system. It can’t misuse a spacing value that doesn’t exist.
You’re not asking the LLM to behave; you’re building a room it can’t behave badly in.
The part nobody expects
The second-order effect is the one that actually pays for the work.
Most of what used to be “work” was repetition: a developer rebuilding, from a Figma file, decisions that had already been made three times before on three other pages.
When your brand is expressed as tokens, and your components consume those tokens, the design is the code. There’s no translation step, because the translation happened upstream, once, as an architectural decision rather than a per-project handoff. Do that once, and it’s a nice efficiency story. Do it across a portfolio, and it changes what the team has time to focus on. The people who were rebuilding buttons and packaging handoffs are now doing the thinking only they can do.
What this means if you’re staring at an AI mandate
Most organizations right now have an AI directive from the top and a pile of pilots at the bottom, and a gap in the middle where the strategy should be. The pilots demo beautifully but don’t survive contact with real volume, and nobody’s quite sure why.
Usually the demo works because one person prompted carefully once. Production fails because two hundred people are prompting carelessly, constantly, against an input that was never structured to hold them.
So before you buy another tool:
- Ask what your brand looks like as data. If the honest answer is “a PDF and some Figma files,” you don’t have an AI problem yet. You have a foundations problem that will present as an AI problem in about six months.
- Ask where your control point is. If your only guardrail is human review at the end, you’ve capped your ceiling at the number of hours your senior people can stay awake.
- Ask what happens the second time. Any workflow that produces a good result once is a demo. A workflow that produces the same good result the tenth time is a system.
Don’t get me wrong, vibe coding is great, I used it to build this page. But it’s a solvent, not a foundation. It will dissolve the boring parts of a build faster than anything we’ve ever had, and in return it will also dissolve your brand’s consistency just as fast if there’s nothing structural holding it in place.
The work isn’t learning to prompt better.
The work is making your brand something a machine can actually read.