AI is rapidly changing the way we work.
I used to spend hours on Figma perfecting every tiny detail of a component. But then came the struggle. Translating that perfect mockup into a live version was always a battle, with endless back-and-forth with developers.
Some things are just hard to capture in a flat picture. You can write long notes describing how an interaction should feel, but words cannot show the actual movement.
At its core, Figma is just a picture. It is not alive. When you design a component like an account selector, it looks perfect on the canvas. But it cannot think. It has no actual behaviour and it does not handle real-world scenarios.
The communication gap
This is why I started building live components. I wanted to show, not just tell.
When a developer can click, hover, and test a component in a live browser, the communication gap disappears. They see the actual states and transitions instead of trying to guess from a static screen.
But building these components requires coding, and that brings us to the second challenge.
The federated struggle
We do not have a dedicated design system engineering team. We always struggle to reserve developer capacity.
To solve this, we made our design system federated. This means any product developer can contribute new components or features back to the shared library.
But product developers are busy. When they face tight deadlines, this model breaks down. Contributions become random, with no proper governance to keep the codebase clean. They cannot wait, so they rush and override the component locally in their own codebase.
It is like adding a feature with sellotape. It works for today, but it creates a fragile patch.
Technical debt and breaking changes
In software development, this local patching leads to technical debt. The biggest risk here is what engineers call a breaking change.
A breaking change happens when a core library or system updates in a way that is incompatible with older, custom modifications.
When we push a system-level improvement to our shared components, the update changes the underlying code structure. Because the product team’s custom override was sellotaped on top of the old structure, it is no longer compatible. The update breaks their code, and their feature falls off.
Bridging the gap with AI
I wanted to solve both problems at once. We needed a clear way to show how components worked, and we needed to stop product teams from overriding them.
Now, when we design or improve components in Figma, I build them in Storybook at the exact same time.
AI is the bridge. Since I can use AI to write the functional code, I do not have to wait for design system developers to free up. I can build the component myself, creating a live, coded version that handles every scenario.
Live playgrounds
Storybook is our virtual workshop. It is a separate, safe space away from our live product where we can build, play with, and test components on their own.
In this workshop, we document components using ‘stories’. A story is simply a live snapshot of a component in a specific state. For example, our account selector has one story for its normal state, one for when it is loading, and another for when an error occurs. They are like interactive mockups.
The main story acts as a playground. Think of it like Figma’s component properties but fully live. Developers can toggle switches, type in test text, and see how the component reacts instantly.
When they start their work, the exact code they need is already built and documented.
Stop the override
Using AI has changed my role. We no longer have to choose between design speed and engineering quality.
We bridge the gap between the picture and the code. Product teams get their features on time, and we avoid the breaking changes that crash our product.
Stop sellotaping. Start building.