Clause
An AI harness for enterprise product design: a note on why prototypes drift from the design system, and what happens when you make drift structurally impossible.
Clause: a closed space. Older than any grammar book, it just meant an enclosed limit, a fenced-in yard. Grammar borrowed it for a group of words shut around one complete thought, self-contained, cut off from the rest of the sentence. That's the shape I wanted the tool to have.
The drift isn't anyone's fault
Designer hands off a spec. Developer builds something. It ships. It's close, but not quite right. Nobody did anything wrong. The drift just creeps in quietly, one small improvisation at a time, and by the time you notice it, it's already the new normal.
Scale that past one designer and one developer and it stops looking like a handoff problem. An enterprise design system is thousands of components, tokens, and patterns, built up over years, and a good chunk of it undocumented or quietly unmaintained. Point a coding agent at that and it doesn't read the system as a strict source of truth, it reads it as a suggestion. It doesn't reliably know the naming conventions or the governance somebody put in place, so it invents a variant that's close enough, mixes in a style from somewhere else, reaches past a component that already does the job for one it just made up on the spot.
Three different people absorb that cost differently. Designers watch the output drift from the brand and the system, and the time AI was supposed to save goes straight back into review. Engineers inherit code that's more bloated and harder to maintain than if they'd written it by hand. And whoever owns the design system watches the one thing they had, a system that was actually true, stop being true, because what ships never finds its way back in. Most of these tools read Figma or the docs, generate code, and stop there. Nothing carries back as a real component. So the drift doesn't just happen once, it compounds, quietly, the same way it always does.
For a while I assumed the fix was process. Stricter handoffs, better documentation, maybe a Linear ticket that nags people. Then I wondered something simpler, almost dumb: what if the prototype just couldn't drift? What if the thing you showed in the meeting was built from the actual components, with no room left to improvise?
A component is only real if it traces back
The idea I kept circling: every component has to trace all the way back, or it doesn't exist as far as the system is concerned. A published component in the design system has its counterpart in Storybook, a true 1:1 React version that is just plain UI, nothing else. The prototype itself is only a JSON file, a composition of those pieces. It owns no UI of its own.
I caught myself breaking this early on, building one-off pieces that looked like the design system but weren't part of it. They wore the costume. They didn't inherit the fixes when the real components changed. Once I noticed that, the rule clicked into place: a primitive knows it's a primitive. It doesn't get to pretend otherwise.
And because prototypes only fetch from Storybook, which stays synced with the design system, the costume problem solves itself. Fix a component once and every prototype wearing it picks up the fix. There's no version of the prototype that can quietly fall behind.
One conversation, both surfaces
The agent does a full roundtrip. The same chat that edits a prototype's JSON can also edit the library itself, fix a drifted component, adjust a variant, or replicate a brand new component straight from a Figma node. Small thing I liked: prototype edits and design system edits show up as different chips, so you always know which layer you just touched.
Overrides follow the same discipline. Swapping a token means swapping it for another token. Raw hex and px values don't exist in the editor at all, so a spec physically can't drift into magic numbers. It took me a while to accept how strict that is, and then longer to admit it's the whole point.
Where the devs come back in
The old loop: designers build in Figma, developers squint at Figma, and the gap between them is where products go slightly wrong. The new loop, at least the one I'm betting on for fast-moving enterprise SaaS: designers direct Claude, Claude does the labour, and the prototype is already made of the real components.
So developers don't read a mockup anymore. They open dev mode, click anything, and read the spec in tokens, the same tokens sitting in the codebase. Copy CSS exists for the times you need to dig into styles, not for production. Variant toggles ride along in the share URL until someone saves, so a review link can be played with without mutating anything.
The spec stops being a document someone writes. It's just what the prototype is made of. That's the circle closing.
Back into Figma, as itself
Built a small Figma plugin alongside this. A designer exports a prototype as JSON and imports it back into Figma, and it lands as native layers built from the real components, not flattened frames pretending to be them.
That closes the loop the other way. Figma node to Storybook, Storybook into a prototype, and now the prototype back into Figma without losing what it's made of. Same components at every hop, so nothing has to be redrawn just because it changed rooms.
It's two steps on purpose. Harvest once against the design system file to map every component to its real library key, re-run only when the system updates. Then import any prototype JSON against that map, in the actual canvas file, and it lands as the components themselves, not a picture of them.
Constrain the surface, not the intelligence
Near the end I handed a frozen spec to a second model, same node IDs, same tokens, same bar for verification, and it passed clean. Not because the model was especially good. Because the system just didn't leave it room to be wrong.
That's the part worth sitting with, more than the tool itself: an agent is only as trustworthy as the boundaries you give it. The interesting problem was never making the model smarter. It's making the ground it stands on smaller and more honest, every design system component with a real 1:1 code counterpart, nothing invented in between.
Where this stands, honestly: an idea with an MVP in progress. I'm using it internally for a few things, and it's not ready enough to judge the output. But the way of thinking already earns its keep, and it's the way I'd want any coding agent to inherit before it's let near a design system.