How To Reduce AI Drifting In Design
What's the real source of truth in your design system — the components in Figma, or the code in Storybook? AI in the loop tends to widen that gap rather than close it. Here's how to reduce drift, using component contracts and harness engineering.
What's the real source of truth in your design system — the components in Figma, or the code in Storybook? In theory, they should both be the same thing. In practice, they almost never stay that way for long, and AI in the loop tends to widen that gap rather than close it.
TJ Pitre and Christine Vallaure wrote wonderful pieces on exactly this — how to reduce drift between design and code, and cut down on AI hallucinations in prototypes, by taking AI out of the loop at the right moment. Let's see how it works.
Specs, a free/pro Figma plugin by Nathan Curtis, turns a selected component into a plain-language spec — with anatomy, props, layout, modes, styling and data.
A New Source Of Truth For Design Systems: Component Contracts #
Christine Vallaure is right: design in Figma and front-end code are supposed to be the same. But with looming deadlines, busy teams and little design system governance, in practice, they never quite stay that way.
Eventually, changes stop making their way into the design system, and design and implementation start drifting apart. Most teams try to fix drift by picking a "winner" — a more recent implementation, or a more recent design. Whoever loses has to catch up with the other side to stay up-to-date.
With Design System Contracts, each component gets a plain description: a readable list of properties, tokens, states, interactions. No visuals, and no code either — merely an agreement about what the component is.
These contracts become the source of truth. With them, the Figma view and the front-end view get built automatically. And with every committed change, a checker automatically compares the contract, the Figma library and the code to flag where they've stopped matching.
Christine has a detailed overview of the concept in her Substack.
Where AI Comes In, and Leaves The Scene #
But what do contracts have to do with AI drifting?
Well, in practice, only a few AI products are AI-only, or even AI-first. Most of the time, AI features work alongside deterministic, reliable, old-fashioned software — software that's repeatable, predictable, highly efficient and doesn't burn tokens every time it runs.
Many design system tasks don't need AI at all — what token colors the primary button, what properties a card accepts, whether Figma and code still agree. In the words of TJ Pitre, those are better served as "deterministic look-ups, not probabilistic judgements. Asking a model to re-derive them on every request is slow, expensive and different every time."
The idea behind design contracts, component specs and token specs is similar: use AI to produce a spec and extract contracts — that's authoring — then step aside, while deterministic tools do the rest — that's enforcement. AI is great at first, but is a liability at second.
- Example: Design System Contracts on GitHub.
- Playground: ds-contracts-playground.pages.dev.
The result then is reliable output every time, reviewed by a non-AI checker, rule by rule. In an A/B test, an ungoverned agent building screens scored 69/100, with 90 violations, invented props, hard-coded colors and restyled components. The same model, working from a generated contract catalog, scored 100/100.
Six Layers Of AI Experience #
Getting AI to work well is hard. If we want AI prototyping to work well with our design system, it will require quite some work. As it turns out, AI needs better guidance that minimizes assumptions and reduces ambiguity — with specs, mandated audit and automated spec updates after approval.
To get better results, AI needs better guidance that minimizes assumptions and reduces ambiguity. Guide by Hardik Pandya.
It's another reminder of how intentional the design process for AI experiences really should be. Emily Campbell's Six Layers Of AI Experience reflects it well — it's a practical model of how the different attributes of AI shape the product's experience — and how good design work can influence each of them individually.
The Six Layers Of AI Experience, by Emily Campbell — User Interface, Context, Harness, Model, Governance, Emergence. Source.
To design a good experience, we have to understand the limits and boundaries of what AI can do — and how to guide it to shape and ship AI experiences that meet expectations and actually work for people. One critical layer in Emily's model to get it right is Harness — and it requires a separate explanation.
Setting Up Guardrails With Harness Engineering #
Over the years, we've learned that to reduce hallucinations, we need to do more than just tell AI to respect certain rules or guidelines. At times AI will do so, but eventually it will be drifting, producing inconsistent results (e.g. in AI prototypes).
Harness Engineering vs. Context Engineering vs. Prompt Engineering — what the system allows the model to do, what it can see, and what you tell it to do. Source.
Instead, we need to engineer deterministic guardrails within which AI can freely operate. That's also the cornerstone of what's called harness engineering — the new practice of designing the environment, tools, and feedback loops surrounding an AI model.
In other words, a harness is everything around the AI model that isn't the model itself: the tools it's allowed to call, the memory and context it's given, the rules it can't override, the checks that run before its output ships, and the recovery path when something goes wrong.
- Prompt engineering shapes what users say to the model,
- Context engineering shapes what AI model can see,
- Harness engineering shapes what the system can and can't do.
The goal isn't to better explain to AI what rules and guidelines it should follow. Instead, we're building an environment where we keep AI on the leash, and where its drifting stays small, detectable and reversible.
There is a wonderful (albeit technical) guide to the topic in the handbook Learn Harness Engineering.
Wrapping Up #
As TJ Pitre notes, authority belongs to whatever layer can refuse deterministically, not whatever layer instructs loudest. A model can be talked around. But a schema can't. If we want to eliminate drifting, AI must operate within the boundaries of non-AI software.
The future of design systems might be AI-first at times, but it's certainly not going to be AI-only. And that's a good thing — fewer tokens, less drifting and design in the hands of designers, who establish and enforce guidelines to be followed every time. Personally, I'm looking forward to that future.
Useful Resources #
- How To Use AI To Need Less AI, by TJ Pitre
- How Design System Contracts Work, by Christine Vallaure
- Specs For Figma, by Nathan Curtis
- Design Systems Need Evals, by Murphy Trueman
- Design System Contracts, by TJ Pitre
- The Six Layers Of AI Experience, by Emily Campbell
- Harness Engineering, by Walking Labs
