AI Can Generate UI. Who Keeps It Consistent? — Roman Bakurov’s Developer Journey
“Generating UI is easy. Keeping it consistent is the hard part.”
For more than 15 years, Roman Bakurov has worked across UX, design and software development. That combination shaped the way he thinks about frontend engineering.
For Roman, interfaces were never simply a visual layer. He was interested in why a product worked the way it did, how people interacted with it, and how product decisions eventually became working software.
Today, he is the founder of Vellira, an open-source cross-platform design system for React and React Native.
But Vellira is about more than creating reusable UI components.
Roman is exploring a bigger question:
What happens to software quality when AI can generate UI faster than humans can review and maintain it?
From UX and Design to Frontend Engineering
Roman's journey began at the intersection of UX, design and development.
Frontend development attracted him because it provided an immediate connection between an idea and the person using it.
You could take a product rule or design idea and quickly see how it behaved in a real interface.
React was particularly appealing because of its compositional model. Complex interfaces could be constructed from smaller, predictable pieces with clear contracts.
But as products grew, Roman noticed that creating an individual component was rarely the difficult part.
The real challenge was keeping an entire product consistent.
Different buttons would appear.
Forms would behave differently.
Developers would interpret the same design rule in different ways.
And eventually, web and mobile implementations could begin evolving as if they were completely separate products.
That problem became the foundation for Vellira.
Why Roman Built Vellira
Vellira started from a practical problem.
A component library can provide reusable building blocks, but a library alone cannot guarantee consistency.
Someone can add local styling.
Someone can create a nearly identical component.
Someone can implement an existing behaviour differently.
Roman wanted consistency to be supported by the architecture itself rather than depending entirely on everyone remembering the rules.
Vellira began as a design system for React and React Native, with shared tokens, components, documentation, Storybook and testing.
Then AI changed the equation.
AI could suddenly generate working frontend code in seconds.
That made writing UI less of a bottleneck.
But it created another problem.
If AI can generate more UI, who makes sure all that UI follows the same rules?
One System, Two Runtimes
One of the challenges Roman faces with Vellira is supporting both web and React Native.
The platforms may need to provide similar experiences, but internally they are very different.
The web has the DOM, browser semantics, focus management, keyboard navigation and ARIA.
React Native has a different rendering model, event system and accessibility model.
Roman therefore doesn't believe the goal should be forcing both platforms to share exactly the same implementation.
Instead, the goal is:
One system of rules everywhere.
The meaning, component intent, states, sizes, tokens and core API principles should remain aligned.
The implementation can still respect the platform it runs on.
Consistency vs Flexibility
Design systems have another difficult balance.
Too much flexibility and the system becomes a collection of helpers that everyone uses differently.
Too much restriction and developers start working around the system.
Roman tries to separate the system contract from extension points.
Core states, sizes, intents, accessibility behaviour and design-token usage should remain predictable.
Composition and integration patterns can be more flexible.
The principle is simple:
A good API shouldn't make everything possible. It should make the correct path the easiest path.
Accessibility Is Not a Final Step
Accessibility is another area where Roman believes architecture matters.
It should not be something added after a component has already been designed.
Keyboard navigation, focus behaviour, semantics, screen-reader behaviour and interactive target sizes need to be considered while the API itself is being designed.
Roman also points out that accessibility is more than adding ARIA attributes.
A component can have the correct aria-label and still have broken keyboard navigation or poor focus management.
Accessibility is fundamentally about behaviour and semantics, not just attributes.
Ironically, the individual components are not the hardest part of Vellira.
Writing a Button component is relatively straightforward.
The harder problem is creating a process that makes sure every component:
- uses the correct tokens
- follows API conventions
- supports the required states
- preserves accessibility
- has tests
- has documentation
- works across the required platforms
That changes the nature of the project.
Roman realised he wasn't simply building components.
He was building a production process for components.
CI, testing, documentation, release processes, compatibility, accessibility, developer experience and package distribution all became part of the same system.
When AI Starts Generating the UI
AI coding tools are already extremely effective at local development tasks.
They can implement components, refactor code, generate tests and help developers understand unfamiliar codebases.
The problem appears when those local solutions accumulate.
An AI-generated component might work perfectly while introducing a second way of doing something the system already has a standard solution for.
It might use a different token.
It might introduce a new pattern.
It might change an API.
It might implement the same principle slightly differently somewhere else.
Each decision can look reasonable on its own.
Together, they can slowly create a second architecture that nobody intentionally designed.
The more code AI produces, the more important that problem becomes.
Turning a Design System Into a Contract for AI
Roman believes the next stage of AI-assisted development needs more than better models.
It needs systems that define the boundaries of acceptable solutions.
Today, telling a human developer to “use our design system” may be enough.
For a machine, it isn't.
AI needs to understand the allowed component variants, tokens, states, composition rules, accessibility requirements and API constraints.
This leads to an interesting evolution:
A design system can become a contract between the product and AI.
The system is no longer only documentation for developers.
Its rules can become machine-readable and verifiable.
Humans and AI may use different representations of those rules, but the underlying system should remain consistent.
AI-Generated Code Needs More Than a Successful Build
Roman doesn't believe AI-generated code should be trusted simply because it compiles or looks correct.
He sees production validation as a series of independent layers.
That can include:
- type safety and builds
- unit and interaction tests
- accessibility checks
- visual regression testing
- design-token validation
- API conventions
- required component states
- platform-specific behaviour
- documentation
- unexpected changes outside the intended scope
But even these checks are not always enough.
A component can pass tests and still implement something different from what the developer originally intended.
That creates another question:
Did the result preserve the meaning of the original task?
For Roman, reliable AI-assisted development needs to validate not only whether the code works, but whether it matches the intended outcome.
Building Vellira in Public
Open source has also changed Roman's understanding of what makes a project successful.
Code is only part of the developer experience.
A project also needs to explain why it exists, make installation understandable, provide useful examples, communicate its API clearly and help developers understand the architecture.
Documentation therefore becomes part of the product itself.
So do naming, package structure, examples, error messages and onboarding.
Building in public also creates another challenge.
Something that seems obvious to the person who has worked on a project for months may be completely unclear to someone opening the repository for the first time.
A good system has to make sense even to someone who wasn't present when the architectural decisions were made.
From Developer to Architect to Founder
Building Vellira has also changed Roman's role.
As a developer, he asks:
“Does this implementation work?”
As an architect:
“Will this still be the right decision for the whole system one or two years from now?”
And as a founder:
“Are we solving a problem that actually matters to other people?”
That last question is particularly important.
A technically interesting problem isn't automatically a valuable product problem.
Every architectural decision can affect documentation, tests, examples, multiple platforms and existing users.
The result is that Roman has become much more careful about decisions that appear convenient today but create hidden costs later.
The Future of UI Development
Roman's work with Vellira points toward an important shift in frontend development.
For years, developer productivity was largely about helping people write code faster.
AI has changed that equation.
Now machines can produce enormous amounts of UI code very quickly.
The challenge increasingly becomes deciding what should be generated, what rules it must follow, and how the result can be verified.
That makes the design system more important, not less.
It becomes the layer that defines consistency.
It provides the constraints.
It gives both humans and AI a shared understanding of how the product should behave.
And perhaps most importantly, it helps prevent speed from becoming chaos.
About Roman Bakurov
Roman Bakurov is the founder of Vellira, an open-source cross-platform design system for React and React Native.
His work focuses on design systems, developer tooling, accessibility and reliable infrastructure for AI-assisted UI development.
Vellira brings together shared design tokens, component tooling, documentation, automated quality checks and cross-platform development with the goal of making UI more consistent and maintainable.
View Roman Bakurov's profile on CoderLegion
Visit Vellira
CoderLegion Developer Stories
Real developers. Real journeys. Real experiences.
Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.
Interview & Story by Mehadi Hasan
