My name is Olena Ivlieva. My professional path has taken me from UX/UI Designer → UI Engineer → Front-End Developer.
Today, I work at Kavita Systems and live somewhere between two worlds: design and its implementation in code.
I started working on the web before Figma and before many of the tools we now take for granted. Back then, the workflow was much simpler: a designer created a mockup, handed it to a developer, and much of the connection between design and code depended on agreements between people.
Today, watching AI enter both design and development, I sometimes get a strange feeling:
It’s as if we invented a time machine and started moving backwards.
A founder with little experience in design or software development may assume AI can handle both.
A developer, on the other hand, may understand components, architecture, and system logic extremely well, while visual design remains a different kind of expertise: composition, typography, rhythm, hierarchy, and interface behavior.
AI generates screens. Those screens quickly become code.
And suddenly it feels like the product is finished.
But a draft is not yet design, and code that runs is not yet a finished product.
We Already Learned How to Build Products Systematically
The early web was built primarily by technical specialists. Design was often handed to developers as static mockups, while in some projects the interface was created directly in code.
I have worked with systems like this myself, and I know how quickly they can start falling apart.
When a team consists of one or two people, a surprising amount of information can live in their heads. But once the product grows, styles drift, components get duplicated, random values appear, documentation becomes outdated, and the design system stops matching the real product.
Now add the reality of modern development: several people working with AI agents at the same time, able to generate much more code in the same amount of time.
And then comes the temptation:
Why do we need a design system at all if AI can generate everything?
Because without shared rules, every new request can produce its own components, values, states, and patterns.
Speed increases.
And chaos can increase with it.
My principle is simple:
System first. Code second.
A product needs not only a technical system but a visual system as well.
Components, states, tokens, rules, and constraints need to be defined and maintained before every team member — or every AI agent — starts interpreting them differently.
Over more than 30 years of web development, the industry gradually arrived at design systems, component libraries, design tokens, documentation, version control, automated testing, CI/CD, and analytics.
None of these practices appeared by accident.
They help us build products that remain consistent, maintainable, and scalable.
And then AI arrived.
It seemed like the perfect moment.
We already had rules and established processes, and now we had a tool capable of removing repetitive work and accelerating documentation, design, code, and testing.
But instead of adding a turbocharger to the engine, we somehow decided to ask: “Do we even need the engine anymore?”
A Product Is Not Just a Collection of Features
AI can generate a screen — but that is not yet design.
It can write code — but that is not yet quality software development.
It can combine several features into a service — but that is not yet a product.
A product starts with a system: user needs, business logic, architecture, a design system, user flows, metrics, and constraints.
If a person does not understand those fundamentals, AI does not automatically compensate for the missing expertise.
It works within the context, rules, and tasks it receives.
So the most important question today is not:
“What can AI do?”
It is:
Who gives AI the task, what context does it receive, and who is capable of evaluating the result?
What Happens When AI Is Used by a Professional
AI expands what a professional can do.
It can help test hypotheses faster, compare alternatives, experiment, document, test, detect inconsistencies, and automate repetitive work.
But AI does not automatically guarantee either speed or quality.
I have a simple rule:
I delegate to AI what I can break down into steps, explain, and verify myself.
Otherwise, I have no reliable way to know whether the result is actually good.
A professional today is not necessarily someone who does everything manually.
It is someone who understands what “correct” looks like and knows how to use AI to do more — and do it better.
AI Between Figma and Code: My Experiment
In 2026, Figma opened its Canvas to external AI agents through MCP.
Agents gained the ability to work directly with Figma files, use design-system context, and create or modify objects on the Canvas. Codex is among the MCP clients supported by Figma.
I wanted to see how this workflow behaves on a real project.
I already had:
- a design system in Figma;
- a working frontend;
- a component library.
I opened PhpStorm, connected Codex to Figma through MCP, and gave myself one specific task:
How well can AI maintain the connection between a design system and its actual implementation in code?
My first conclusion appeared very quickly:
Working with AI does not start with a prompt. It starts with rules.
Context Comes First
My design system is based on Atomic Design principles.
I manually defined the design-to-code mapping:
which Figma component corresponds to which component in the codebase, how variants, states, properties, and props relate to one another, and which tokens should be used.
AI helped formalize that information by updating component descriptions, implementation paths, and documentation.
In other words:
I defined the architecture, relationships, and rules. AI handled as much of the mechanical work as possible.
For a direct connection between design components and code, Figma provides Code Connect.
It links Figma components to their actual implementation in a repository and gives MCP agents more precise implementation references.
Code Connect is currently available on Organization and Enterprise plans and requires a Full or Dev seat.
My experiment was conducted on a Professional plan, so I did not use Code Connect.
Instead, I built the mapping through naming, descriptions, paths, documentation, and rules for the agent.
This is not a replacement for Code Connect.
It was a deliberate constraint of my experiment.
And this is where the structure of the Figma file really matters.
Reusable components and blocks, meaningful naming, Auto Layout, properties, variants, variables, and component descriptions all give the agent useful structure.
The clearer the system is, the less logic the agent has to reconstruct on its own.
Test #1: Code → Figma
For the first test, I did not choose a simple button.
I chose a small composite component containing a responsive grid, cards, nested components, icons, text, a CTA, a button, and several breakpoint states.
The task was not:
“Draw something similar.”
The task was:
Take the existing implementation from the codebase, move it into Figma, and preserve the structure of the design system.
In my test, the agent completed the transfer in approximately 29 minutes.
The result was good.
The component did not become one flat frame. It preserved hierarchy, layers, instances, responsive states, tokens, spacing, typography, and an editable structure.
But there is one very important detail:
This was far from my first attempt.
Those 29 minutes represent one successful iteration.
Before that came documentation, rules, mistakes, rewritten documentation, new attempts, and more reviews.
That preparation is what made the result predictable enough.
The More Complex the Component, the More Important It Is to Break the Task Down
The limits of AI become much more visible with complex components.
Nested components, custom logic, abstractions built on top of Tailwind, custom utility classes, and unusual responsive rules all increase the amount of context the agent needs to interpret correctly.
It may transfer the main structure while missing a subcomponent, a state, or a specific layout rule.
And even if one component transfers perfectly, that does not mean the next one will behave the same way.
So my workflow became iterative:
small component → transfer → review → next component → review → composition
Atomic Design turned out to be useful here for more than organizing the design system.
It naturally helps divide the agent’s work into smaller, verifiable pieces.
The same principle applies to reusable blocks: the more layout, spacing, and token logic already encoded in the system, the less the agent has to invent.
Test #2: Figma → Code
Then I ran the experiment in the opposite direction.
I removed the documentation that explicitly mapped this particular component to its existing code implementation.
Then I asked the agent to create a new frontend implementation based on the Figma component.
After approximately 8.5 minutes, I had code.
In my test, the visual result matched the design, the responsive states worked, and the structure was close to what I expected for the project.
That is a good result.
But it does not mean Figma can now automatically generate production-ready code.
My conclusion is different:
A well-structured Figma component gives the agent better input context.
Generation Is Not a Finished Task
I would not automatically transfer ten or fifteen complex blocks and think:
“I’ll quickly review everything tonight.”
At least I cannot.
After generation, I still need to review:
component reuse, props, tokens, responsive behavior, accessibility, dependencies, naming, and whether the implementation fits the architecture of the specific project.
So my actual workflow looks like this:
Figma → component → code → review → next iteration
Once the system and documentation are prepared, it becomes fairly convenient to move a component between Figma and code in both directions.
But the most expensive part of this workflow is not generation.
Most of the time went into rules, mapping, documentation, and iterations before the automation became predictable enough.
The Biggest Risk: Error Propagation
A bidirectional workflow introduces another problem.
Imagine this cycle:
code → Figma → changes → code
During the first step, the agent introduces a small error.
Nobody notices.
In the next iteration, people are already working with that Figma version. More changes are added, and the component is sent back into the codebase.
To the agent, the previous mistake does not necessarily look like a mistake.
It is simply new input.
The error returns to the code together with the new changes.
That is error propagation.
Every iteration can reinforce the mistake instead of fixing it.
This is why every iteration needs a validation layer.
And validation does not mean opening Figma next to the browser and saying:
“Looks close enough.”
You need to understand the actual system: components, variants, states, tokens, responsive rules, code architecture, dependencies, and constraints.
To properly review AI, you need to know what the correct result should look like.
Documentation Helps, but It Does Not Make AI Deterministic
One area where AI has been especially useful for me is documentation.
I change a component, property, token, or prop, and the agent can update descriptions, paths, and find outdated references throughout the codebase.
A task like:
“We renamed this component. Find every place where the old name is still used, replace it, and update the related documentation.”
I am very happy to delegate to AI.
But documentation does not turn an LLM into a deterministic program.
You can make agent behavior significantly more stable through:
context → rules → examples → tokens → tests → validation
But I still review the actual result.
My workflow is simple:
give the task → get the result → review → accept or correct
I Did Not Become Faster — I Started Doing More
This is probably the most interesting result of the experiment.
Did I become faster?
Not always.
In the past, I probably would not have created eight or more checkpoints, documented components in this much detail, reviewed every state, or prepared several alternatives for the same solution.
Not because those things were unnecessary. I simply did not have enough time.
Now I can delegate part of the mechanical work to an agent.
And I spend that time differently:
I break components down more carefully, review more states and responsive scenarios, synchronize Figma and code more precisely, test alternatives, and catch problems earlier.
So my work did not necessarily become faster.
It became deeper and more systematic.
The same applies to design exploration.
AI can generate more rough directions very quickly.
That does not mean those directions are automatically good.
But instead of spending all my time manually producing one option, I can inspect more alternatives, discard weak ones, and develop stronger ideas further.
AI is useful here not because it “made the design decision for me,” but because it increased the amount of material available for professional analysis.
And that is exactly why the design system has not become less important to me.
Quite the opposite.
In my workflow, Figma remains the visual source of truth, while the codebase is the source of implementation.
In Figma, I can see components, variants, states, tokens, and hierarchy as one visual system.
In the codebase, I see their actual technical implementation.
There needs to be clear mapping between the two.
And do not assume that simply opening the technical implementation will make the entire system obvious.
Spoiler: it will not.
Code is distributed across components, files, dependencies, styles, and logic, so reconstructing the complete visual system from code alone is much harder.
AI will not automatically “understand the entire system for you” either.
It only works with the context provided for a specific task and within the limits of that context.
What I Took Away From This Experiment
The most interesting result for me is not that AI can move a component from Figma to code and back.
The point where frontend architecture starts being designed is shifting.
In the past, part of the interface architecture was often defined only when implementation reached the codebase.
Now more of that logic can be defined earlier in Figma:
components, states, variants, tokens, responsive rules, constraints, and relationships.
In this workflow, Figma is no longer just the place where the mockup lives.
It becomes a structured model of the interface, prepared for implementation.
And roles begin to shift as well.
AI can take over part of the mechanical frontend work.
But engineering expertise does not disappear.
It moves higher up the process.
A person building this kind of design system in Figma already needs to think beyond visual design.
They need to understand component architecture, states, tokens, responsive behavior, reuse, constraints, and how all of it will eventually live in code.
So I do not see the future as “the designer replaces the frontend developer,” or the other way around.
Instead, the boundary between design and frontend is becoming thinner.
Some work moves earlier into the structure of the design system.
Some work becomes automated.
And the specialist gradually moves from manually creating every element toward building rules and systems that both humans and AI can work with.
My main conclusion from this experiment is:
AI does not remove architecture. In my workflow, it forces me to define architecture much earlier. And if the system is already well structured in Figma, AI can take over a significant part of the path toward code.
But someone still needs to design that system, understand it as a whole, validate the result, and take responsibility for what ultimately reaches the product.