Vitalii KhomenkoPublished inOctober 2, 2026
The AI briefing for Developers
Stay up to date with AI tools, model releases, and developer workflows that matter.
Weekly. Free. One click to leave.
SitePoint Premium
Stay Relevant and Grow Your Career in Tech
- Premium Results
- Publish articles on SitePoint
- Daily curated jobs
- Learning Paths
- Discounts to dev tools
7 Day Free Trial. Cancel Anytime.
With 250+ client engagements across both agency and embedded in-house roles, Vitalii Khomenko has seen product teams from the inside in a way few designers have. Here he makes the case for a new kind of design workflow built for the AI era, and explains why the window to adapt is narrower than most founders think.
For the last decade, every startup conversation about speed eventually became a conversation about engineering. Hiring more developers, cutting scope, choosing a simpler stack, it was almost always a dev-side problem. Vitalii Khomenko, Principal Designer at Orizon Design and founder of Fluente LLC, argues that’s no longer true. And he has a specific view on what teams should do instead.
What makes Khomenko’s perspective worth taking seriously isn’t just seniority. It’s the specific shape of his experience. Over a career spanning 250+ client engagements, he has worked both as an external specialist brought in to deliver and as an embedded designer who became the single connective thread between product, brand, and execution. That dual vantage point is rare. Most designers live on one side of that line. Khomenko has operated extensively on both, which gives him an unusually clear read on where friction actually originates inside product teams, and where it doesn’t.
His work spans early-stage startups finding their first visual language and established brands managing complex, multi-disciplinary design systems. Across that range, certain patterns repeat. And the pattern that started becoming impossible to ignore this year pointed him toward a conclusion that is reshaping how he thinks a modern design workflow should actually be structured.
The bottleneck didn’t disappear. It moved. And the workflow needs to move with it.
The Problem With How Design Teams Are Currently Working
When shipping code was slow, the existing design workflow made sense. Multiple rounds of revision, user testing, iteration, all of that fit naturally into the window while engineering caught up. That window is now gone, and most design workflows were never updated to reflect it.
“Founders are asking design teams to move at the same speed as an AI-assisted dev pipeline, and design doesn’t compress the same way code does,” Khomenko says. The result is a workflow that was built around a constraint that no longer exists, applied to a pipeline that has fundamentally changed around it.
The forced choice between polish and speed that product teams are now navigating isn’t new as a concept. What’s new is how stark it has become, and how directly it traces back to a workflow problem rather than a people problem. “Because development is cheap and fast now, there’s constant pressure to ship the next thing immediately,” he explains. “But the products that actually retain users are still the ones where the details were considered carefully. Fewer revision rounds isn’t a process improvement if it means shipping avoidable friction.”
Khomenko has watched this play out across enough teams, at enough stages, to be specific about where the existing workflow breaks down. The issue isn’t design judgment. It’s where that judgment sits in the process, and what format it’s expected to produce at the end.
Why Figma Handoffs Are Now the Bottleneck
To understand Khomenko’s proposed fix, it helps to understand exactly where the current workflow stalls. For most product teams, the end of the design process looks like this: a designer produces polished, dev-ready screens inside Figma, and hands that file to engineering. Engineering then interprets those screens, translates the visual decisions into code, and builds from there.
That translation step, Figma file to working code, is where the pipeline now breaks down. AI-assisted engineering has made the building part dramatically faster. But the translation step hasn’t changed. An engineer still has to read a Figma file, interpret spacing, extract assets, make judgment calls about component structure, and write the implementation from scratch. That process takes the same amount of time it always did.
“The manual workflow inside Figma simply isn’t keeping up with AI-boosted engineering,” Khomenko says. “The design handoff is quietly becoming the thing everyone is waiting on.”
The result is a pipeline where everything around the handoff has accelerated, and the handoff itself has become the single point of drag. Figma, in other words, was built for a world where engineering was the slow part. It wasn’t designed to feed a pipeline where engineering moves at AI speed.
The Fix: Final Delivery in Code, Not in Figma
This is the core of what Khomenko is proposing, and it’s a more significant structural shift than it might first appear.
In his workflow, Figma doesn’t disappear. It moves. Rather than serving as both the exploration environment and the final delivery artifact, Figma becomes the visual exploration layer exclusively: the place where brand identity is established, layout logic is worked through, and design direction is validated. It remains the right tool for figuring out what something should look and feel like.
But the final delivery, the artifact that actually goes to engineering, is code. Specifically, components built into prepared libraries that engineering can work from and scale directly, without any translation step in between.
The difference in implementation speed is the point. When a designer delivers a coded component library rather than a Figma file, engineering doesn’t need to interpret anything. The decisions are already expressed in the language they’re building in. What previously required an engineer to read, interpret, and re-create from a visual reference now arrives ready to use. In a pipeline running on AI-assisted development, that difference compounds fast.
“Figma is still the right place to explore what something should look and feel like,” Khomenko says. “But handing over a Figma file and asking engineering to implement it is now the slow path. Delivering in code is the fast path. That’s the shift.”
The Designer This Requires
Executing this workflow requires a different kind of designer, and Khomenko is direct about that. The UI/UX designer becoming a Design Engineer is, in his assessment, not a distant possibility. It is a matter of time, and the teams treating it as a future consideration rather than a present reality are the ones most likely to find themselves stuck at the handoff.
But Khomenko is equally clear about what this shift doesn’t mean. Delivering in code is one part of the role, not the whole of it. The full design cycle isn’t going anywhere. Applying branding to imagery, producing animations, building marketing materials, these remain essential creative tasks that require a broad and varied toolkit well beyond code. “The designer of the near future isn’t just generating code,” he says. “They’re moving across the full cycle, brand, motion, marketing, product, with design engineering as an important and growing part of that stack, not a replacement for it.”
What changes is that code-ready delivery becomes a core expectation within that stack. The designer who can move fluidly from visual exploration in Figma to component delivery in code, while also carrying the brand thinking, motion, and marketing creativity that differentiates products at the surface level users actually experience, is the profile that the new workflow demands.
An Honest Note on Where Things Stand
Khomenko is candid that no single version of this workflow has fully standardized yet. Every team is figuring it out differently. The tools are evolving, the handoff expectations are shifting, and the processes teams are building around all of it vary considerably. There is no off-the-shelf playbook.
But this is precisely where his 250+ engagements become more than a credential. They’re a dataset. Having watched enough teams, at enough stages, through enough cycles of tooling change, Khomenko can see through the noise of individual variation and identify what’s directionally true even when the specifics are still in flux. “Each team’s workflow is really custom at this stage,” he says. “But some general patterns of how this is going to look in the near future are already visible.”
Those patterns consistently point in the same direction: design judgment moving earlier, final delivery moving into code, and the designer’s role expanding in technical range while staying broad in creative scope. The exact tools and sequences will keep shifting. The underlying logic of the workflow Khomenko is describing is already taking shape in the teams paying closest attention.
What Founders Should Do Now
For founders and product leads, the workflow Khomenko is describing has direct implications for how teams are staffed, budgeted, and structured.
Front-load design judgment. The biggest leverage in the new workflow isn’t faster execution, it’s better problem definition before generation starts. Bring senior design thinking in earlier, when it can shape what gets built rather than polish what’s already done.
Separate exploration from delivery. Figma and the visual exploration phase serve a distinct purpose from the final delivery layer. Treat them as separate stages with separate expectations, rather than collapsing them into a single step expected to produce everything.
Shift the delivery expectation to code. Whether that means hiring for Design Engineer range, developing it internally, or restructuring handoffs, the end of the design pipeline needs to arrive in a form engineering can work from directly. The translation step is where time goes to die, and it’s now the most avoidable part of the process.
Protect the full creative stack. Design engineering matters more than it ever has. It is not, however, the whole job. Teams that reduce design to code generation will lose the brand thinking, motion, and marketing creativity that differentiates products at the surface level users actually experience.
Stay flexible. The workflow is still forming. Teams that build rigidity into their process now will find themselves redoing that work within a year. The teams getting this right are the ones building enough adaptability into their structures to absorb what’s still coming.
“The Figma handoff made sense when engineering was the slow part,” Khomenko says. “Engineering isn’t the slow part anymore. Delivering in code isn’t the future of design workflow. For the teams paying attention, it’s already the present.”
Vitalii Khomenko is Principal Designer at Orizon Design and founder of Fluente LLC. Across more than 250 client engagements, spanning agency work and embedded in-house roles, he’s worked with early-stage startups and established brands alike, giving him a close-up view of how design and engineering actually collide inside product teams.
