I spent the past year trying to replace my UI & front end workflows with GenAI

Nine months of pushing Figma Make & Cursor to their limits on real client projects — and understanding why it can’t replace us.

I don’t think anyone expected design to be one of the first industries to be threatened by generative AI.

Our assumption was that creative work was inherently human. Of course, useful tools would arrive and workflows would get faster. But turning an idea into a structured, usable interface felt hard to replicate.

Then, I remember seeing Uizard and Galileo AI for the first time.

These weren’t tools that could tidy up a workflow or automate a small task. They could generate interfaces. The outputs were rough, and had that unmistakable AI genericness, but the potential was clear as day.

Fast forward a few years, and the industry giants have made it their battleground.

Figma Make, Cursor and Claude Code didn’t just promise faster mockups. They leveraged the gap between UI design and front-end implementation. The outputs aren’t visual mockups — they’re fully functioning code.

The rate of pace of these tools’ development has been disconcerting.

On one hand, we’re questioning what this means for designers. On the other, we’re wondering if these tools could finally help designers move beyond static mockups and get closer to front-end implementation.

Over the past year, I have been testing that second part directly and intensely.

I’ve used the aforementioned tools to build interfaces, generate components, create project template kits, define system rules and stress-test whether a designer with limited front-end knowledge can produce production-ready UI. I’ve also dabbled in other ‘Figma Killers 🙄’ like UX Pilot, Google Stitch and Claude Design along the way too.

The goal wasn’t just to build a prototype that looks good in a demo. I wanted to create something an engineer could pick up, review and ship.

My honest conclusion: we’re still not there — yet.

I can create something that looks great. But no engineer would be happy shipping it for a client.

The main problem is these tools love workarounds. They’re incredibly useful in some areas, fragile in others, and very good at producing work that looks more complete than it actually is.

They don’t work in the same way humans do.

The Gartner Hype Cycle

Source: BMC

The Gartner Hype Cycle perfectly demonstrates where we are with GenAI. It describes a familiar pattern: first comes the hype, then disappointment, and finally a more practical understanding of what the technology is actually good at.

At first, the demos looked unbelievable. One prompt could generate a fully working prototype. But the outputs were inconsistent. The styling drifted. Interactions broke.

The tools were still impressive, but the early expectation that they might cleanly collapse the gap between design and front-end engineering started to feel naive.

So for me, the trough was not a loss of belief.

It was the gap between what I initially thought the tools could do and what they should actually be used for.

I’ve started this article with my conclusions, so let’s take a step back. Over the past 9 months, I tested a range of hypotheses on real projects at a leading Applied AI firm to see how close I could get to creating production-ready interfaces solely using GenAI.

Stage 1: Exploring the capabilities of GenAI design tools

October 2025

My first reality check came from using Figma Make on a real project.

At that point, I was still using it naively. I was winging the setup process, had no rules, component guidance, or a strong sense of the tool’s shortcomings. I was mostly doing what these tools naturally encourage: prompt generation and tweaking the results.

This drew me to the first question that would kickstart my experimentation:

Could GenAI produce user interface code that a developer could pick up and use?

The outputs were extremely convincing.

What would normally take me hours to design now took minutes. It helped me explore the flow I had mapped out, and made my idea feel much more real traditional Figma prototyping could. As a design artefact, it had immense value. On top of that, these interfaces were built using code — something Figma Design could only imply via dev mode.

As the sole Product Designer on the project, I worked on that prototype for around 6 weeks — amongst other research and ideation activities — sending around 500 prompts in total. But when our front-end engineer picked it up, the gap became obvious.

The work was useful as a reference, but not as something to build directly on top of. Too much had to be rebuilt.

That was the first important distinction for me:

Generating a coded prototype is not the same as generating production-ready front-end work.

At first, I was asking whether GenAI tools could generate solid interfaces using code. The answer to that was clearly yes.

The next question was whether they could generate interfaces in a way that respected the structure, constraints and quality bar of a real front-end project.

Stage 2: What Happens When You Design In Code?

January 2026

After the first Figma Make project, I wanted to test the problem from the other direction.

Figma Make demonstrated how you could prototype using code. It was building a working coded prototype inside Figma’s environment. It was also using (or at least referencing) shadcn-style components.

So the next experiment was a move from a design-native coding environment into a developer-native one.

I moved into Cursor to see what would happen if I worked closer to a conventional front-end repo from the start: real files, real components, dependencies, build errors, commits, and a structure that looked more like the environment an engineer would eventually work in.

My question then became:

Would the output become more reliable if the AI was working inside a more constrained codebase?

I downloaded the shadcn GitHub component library as a foundation. Instead of relying on the tool to draft everything from scratch, I wanted it to assemble screens from known parts.

In practice, this felt less like making screens and more like directing a front-end system. Code quality became the main concern, the designs were secondary.

It was a strange shift. As a designer, I lost the immediacy of visual exploration. But I gained something else: a closer relationship with the environment the product would actually be built in.

Outputs became more grounded. Not perfect or production-ready, but more predictable.

But this also revealed the next problem:

The components were not usually where things broke. It was in the way those components were composed into real screens.

Stage 3: The component layer held. The composition layer broke.

February 2026

This was one of the biggest issues with the Cursor experiment. The reliability of outputs varied massively.

The core components were great. Buttons behaved like buttons, tables like tables, and so on.

It suggested that GenAI tools were much better at working with proven, well-defined units. On a component level, the tool had a much smaller decision space to operate within.

But the problems started one layer above that.

The weakness was in composition.

How should the screen be structured? What should sit together? What should be primary or secondary? Should this be a table, a side panel, a form, or something else entirely? Which parts of the interface should be visible up front, and which should be revealed later?

Outputs were unreliable. It would also opt to choose the same components and layouts for almost every problem it faced.

One example I noted was what I like to call “death by cards”. The system kept reaching for cards as the default way to structure sections, even when a card was not the right design or product choice.

Example of shadcn card design. Source: https://next.jqueryscript.net/shadcn-ui/interactive-glow-card-effects/

At first, I treated that as a tool failure. But as I looked into it, I realised it was partly a rule failure. I had created one rule ‘not to use cards as a default information structure for everything’, but then I quickly realised I’d need rules to break other bad habits.

My prompts became more informed, filled with guidance relative to the task.

It started to demonstrate how GenAI was evolving the design process. I was no longer manually building layouts, but I was now responsible for spotting when the system had made a weak design decision, understanding why it did that, and introducing rules so it was less likely to happen again. Very much like critiquing a junior designer’s work.

That informed one of the most useful conclusions from the whole experiment:

GenAI tools perform better when the unit of work is clearly defined: use this button, don’t use that table.

They are much less reliable when the work requires judgement across those units: what should be grouped, what should be prioritised, and above all, what best fits the user’s task.

Stage 4: I turned failures into rules

February 2026

The more I progressed, the more habits I started to pick up on.

Weak layouts, overused patterns, components used in the wrong context. Each failure showed me something the system failed to understand.

At this point, I was treating those moments as one-off corrections. I would spot the issue, tell the tool to fix it, and move on.

But as you can imagine, that process was insanely tedious. The same issues would happen again and again.

So I started turning repeated failures into reusable rules.

This is where I learned the importance of markdown files known as ‘Skills’. I began creating guidance the tool could refer back to: setup instructions, component usage rules, design token usage.

The aim was to stop carrying all of the judgement in the prompt. Instead of explaining the same things every time, I wanted the repo to hold the context.

This changed the workflow.

The tool was no longer just responding to prompts. It was working with a rulebook. It didn’t make it perfect. But it did make the failures more useful. Every time something went wrong, I would ask: is this a one-off mistake, or is the system missing a rule?

That lead me to my next conclusion:

The improvement did not come from crafting a magic prompt. It came from making the system harder to misuse.

Stage 5: Trying to make the system repeatable

March 2026

Once the rules started helping, the next question was whether this could become repeatable.

It was one thing to improve a single project as I went through it. It was another to create a foundation that could be reused from the start of the next one.

So I built a project template.

The idea was to stop treating every new AI-assisted build as a blank canvas. Instead, a new project would start from a known foundation: the same components, rules, and assumptions about how the system should behave.

At its most developed, I created a repo with ~50 shadcn components, markdown knowledge-base files, Cursor rules, and a browsable system app for reference. All stuck into a GitLab repo for good measure.

The workflow became: clone the repo, install it, and start building on top of that foundation.

And it did help.

The AI had fewer basic decisions to make. It did not need to invent a button or guess how typography should work. Those decisions already existed.

But the real test was not whether the template looked neat. It was whether the system could survive a real project.

So I used a previous project brief and research to see how the template would fare. I already knew the shortcomings I had faced before, and where earlier attempts had fallen short.

I found that the template helped, but it didn’t make the workflow reliable.

I was still finding new issues all the time. The difference was that I was now treating those issues as system feedback.

I was doing my best to turn every failure into something reusable.

I introduced an audit skill with a decision log. Getting it to inspect the code, evaluate it’s own work, and log the decisions we made in a separate file.

It made the system better, but also made the process heavier.

Every new issue created a new rule. And let me tell you, the amount of new rules coming from every check was staggering. What started as a way to reduce ambiguity became another layer of complexity.

It exposed my next problem: I might have been over-engineering the solution.

Stage 6: I pushed things too far

May 2026

At this point, the system had rules, numerous markdown skills, template files, component instructions, decision logs, audit checks and workflow expectations. Each part had a reason for existing, derived from a real failure.

There were two major issues I noticed.

First: I was asking the tool to follow a process that required a lot of judgement — understand the design goal, use the right components, avoid weak patterns, respect the typography system, log decisions, preserve context, run checks, and know when to stop.

It could follow parts of that process, but not reliably follow everything to the level I had hoped for.

Second: Design judgement is inherently very complex.

It sounds obvious writing this now, but showed me that the tricky parts of UI and front-end work are not just a set of instructions waiting to be automated. The value sits in the judgement between the instructions: knowing when to use a rule, when to bend it, when a layout is technically valid but wrong for the task, and when something needs engineering review.

So, I stopped trying to automate the design & development process, and took a step back.

Stage 7: Comparing the strengths and weaknesses of each tool

June 2026

Cursor gave me control. It put the work closer to a real front-end environment. That made it better for testing whether an output could become reliable enough for engineering approval.

But it also pulled me into implementation too soon.

Once something existed in code, it was easy to start treating it as the set direction. I was so focussed on ensuring the code was solid that I’d lost the exploration of visual design.

Figma Make had the opposite strength.

Even though it was generating code, it kept me closer to the design process. It was easier to generate alternatives, inspect the interface visually, make small adjustments and stay in a more exploratory mindset. Plus, interfacing with Figma Design made me recognise why that part of the process is still so important to us.

So the question stopped being “which tool is better?”

It became “where does each tool actually help?”

Every project is different. Sometimes you have a full design team, others you’re the only designer. Sometimes you have a lengthy discovery period, others required wireframes yesterday.

Stage 8: The current limitations of AI-Assisted coding

June 2026

By this point, I had a more balanced view of the tools.

Figma Make was useful for exploration. Cursor was useful for control. Figma Design still mattered for deliberate visual work. Engineering still mattered for production confidence.

But this exposed the biggest limitation I kept running into:

Even when the everything seemed right, I could not always trust what was happening underneath.

That is another major gap for front-end implementation.

A designer can review the things designers are trained to review: hierarchy, layout, interaction flow, visual quality, usability, consistency and whether the interface supports the task.

But production front-end work has another layer.

Is the component implemented in the right way? Are refs being preserved? Are classes being merged correctly? Are tokens actually being applied in the rendered output? Are dependencies clean? Are interaction states reliable? Is the code maintainable enough for another engineer to inherit?

Those questions still require an engineer to evaluate.

One example came from a prototype kit in Make that I was building with shadcn and Radix components. Popups, tooltips and dropdown menus appeared to render correctly, but would immediately dismiss on click.

The issue was the generated components had been written in a way that did not preserve refs correctly in the React environment I was using. That meant the component appeared right, but the interaction was structurally broken.

Another example came from typography.

I had created custom text tokens for fluid and dense type scales. On the surface, the system looked like it was applying them. But a deeper audit showed that some classes were being dropped because of how the class merging behaved.

Again, this was not a visual issue, it was a technical issue hidden underneath.

That’s where I think the current limitations are clearest.

GenAI tools can help you ‘vibe code’ a direction. They can help you get to something polished, interactive and convincing. They can build the bones of an application much faster than before.

But they still struggle to guarantee the things that make front-end work safe to ship.

A designer can get a product much closer to implementation than ever before. But there’s still a significant gap that GenAI tools aren’t able to bridge yet.

So, where does that leave us in July 2026?

After almost a year of testing these tools, my view is less dramatic than when I started.

GenAI tools will replace certain tasks in our processes, but they won’t replace the roles of our current descriptions of designers and engineers — potentially until an incredibly complex set of agents are created at an accessible level, or we achieve AGI.

The major shift right now is the breakdown of the barrier between the two disciplines.

That’s an important shift we’ve needed for decades.

A designer can now get much closer to front-end implementation than before. Not in a theoretical way, but practically: generating coded prototypes, exploring flows in higher fidelity, assembling known components, testing different directions, and building the bones of a front-end application.

That is a big deal.

A lot of the routine work gets faster. Drafting a visual direction. Turning a rough idea into something interactive. Building a first pass. Creating enough structure for a conversation with engineering to start from something more concrete than a static mockup.

But none of that means the work is production-ready.

These tools can generate something useful. They can generate something convincing. They can even generate something that behaves enough like software to support real design thinking.

But getting from that to something safe, maintainable and ready to ship will still requires specialist knowledge — at least for the foreseeable.