Flaude

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.

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.

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.

hariprasd.github.io/flaude