Is this the end of Figma as we know it?

I do not think Figma is about to disappear. It is still brilliant for visual thinking, collaboration, component libraries, critique, and getting a team aligned around a shared design language.

But I do think the question is slightly wrong.

The more interesting question is: who gets trusted to make the first convincing version of an idea?

At my current company, we are rapidly prototyping while also developing a new design system. That combination has made the shift feel very real. Designers and UX practitioners can create mid-fidelity ideas quickly. Product owners can get something in front of clients before the conversation has gone cold. Developers can use tools like Cursor and Claude to turn rough product thinking into working UI much faster than before.

That changes the politics of early product work. The first prototype is no longer just a sketch. It can look polished enough to persuade people. It can shape the direction before the team has properly discussed whether it is the right direction.

That is where this starts to feel personal for me.

The bit I want to be honest about

I sit in a hybrid space. I trained in design, and I have taste. I care about hierarchy, rhythm, spacing, balance, content, and whether an interface feels considered. I also work as a front-end developer, so I spend my days thinking about the browser, accessibility, state, performance, responsiveness, edge cases, component APIs, and all the weird little details that decide whether a nice idea actually works.

That combination matters in AI prototyping.

There have been moments recently where I have looked at a prototype direction and felt the uncomfortable internal reaction of: I think I could make this better.

That is hard to say without sounding arrogant. I do not mean "move over, I know best". I mean I can see the gap between the visual idea and the thing it would need to become. I can see when a layout is nearly there but the interaction is going to be awkward. I can see when a prototype looks clean because it is hiding the difficult states. I can see when the AI has produced a believable dashboard, but not necessarily a useful product.

And because I can design and build, I can often test that instinct quickly. I can prompt an alternative. I can try the same idea with real content. I can use the design system instead of inventing a new pattern. I can make the interaction behave in the browser and then judge it properly.

That is not about replacing designers. It is about acknowledging that hybrid designer-developers are unusually well placed for this moment.

Figma is the hook, not the whole story

Figma has been the default prototyping tool for years. If you wanted to explore a flow, show a stakeholder an idea, or build a clickable prototype, you opened Figma. That still makes sense for a lot of work.

But AI tools are pulling prototypes closer to working software. Figma is doing this too with Figma Make, which is designed to generate functional prototypes and web apps from prompts and existing designs. So this is not really Figma versus AI. Figma is also trying to move into the same space.

The problem is that Figma is still not the browser.

I wrote about this in Stop Generating State Props: Figma Variants Are Not CSS. A hover state in Figma is a visual variant. In the browser, it is a pseudo-class. A disabled button in Figma is a visual state. In the browser, it is an attribute with behaviour. A responsive layout in Figma is intent. In the browser, it has to survive content, viewport changes, keyboard navigation, loading states, and actual users.

I also wrote about my first week with Figma's MCP server, and I still think the bridge is useful. Design context in Cursor is genuinely helpful. But a bridge is not the destination.

Figma describes intent. The browser tests it.

Mid-fidelity prototypes are persuasive

The exciting part of AI prototyping is not pixel perfection. It is speed to shared understanding.

A good mid-fidelity prototype can help a team ask:

Does this flow make sense to a client?
Is this dashboard useful, or is it just cards all the way down?
What happens when there is no data?
What happens when there is too much data?
Can someone use this with a keyboard?
Does this idea still work when it uses our real design system?

Those questions sit between design, UX, product, and engineering. They do not belong neatly to one role.

This is where AI can be brilliant, but also a bit dangerous. It is very good at producing something that looks credible. A left nav, some cards, a clean chart, a rounded button, a little gradient. Suddenly everyone is nodding because it looks like a modern SaaS product.

Yes, I know the irony. My own website is purple and uses cards. This was before every AI-generated interface decided purple gradients and card grids were the official uniform of the future. Thank you very much.

But looking credible is not the same as being good. A prototype can be attractive and still be inaccessible, awkward, slow, overcomplicated, or completely detached from the design system it is supposed to support.

Taste plus implementation experience is a real skill

I think this is the part companies risk missing.

Designers bring taste, critique, visual judgement, and an understanding of user experience. UX practitioners bring research, journeys, friction, and user needs. Product owners bring client context, commercial pressure, and the decision that needs to be made.

Front-end developers bring another kind of product judgement. We know what happens when an idea leaves the canvas and enters the browser.

We think about:

semantic HTML
keyboard interaction
focus management
loading and empty states
responsive layout
component reuse
browser behaviour
performance
data shape
validation
edge cases
what should be CSS instead of JavaScript

Those are not boring implementation details. They shape the product.

So when a front-end developer also has a design background, that is not just a nice extra. It is a specific prototyping skillset. It means you can judge the visual direction and the implementation direction at the same time. You can make something that feels good, behaves properly, and has a chance of becoming real without a painful rebuild.

That is the acknowledgement I think I am reaching for.

I am not saying I should own every prototype. I am saying people with this blend of skills should be seen as strong candidates to lead rapid prototyping work, not just brought in later to tidy up someone else's idea.

The awkward part: challenging a prototype

This is where it can get uncomfortable.

Once a prototype has momentum, even a rough one, people start protecting it. The conversation can shift from "is this the best way to explore the idea?" to "how do we make this version happen?"

If you are the person challenging it, you can easily be framed as negative. The awkward developer. The person slowing things down. The one asking about accessibility, state, content, or the design system when everyone else wants to keep the energy moving.

But the challenge is not always resistance. Sometimes it is craft.

A hybrid designer-developer can say, "I think there is a stronger version of this," and then prove it quickly. Not with a long theoretical critique, but with another prototype. Here is the same journey with fewer steps. Here is the same dashboard with real data. Here is the interaction using our existing components. Here is what happens when the empty state appears. Here is the accessible version.

That is a much more useful contribution than simply saying no.

It is also why I think front-end developers need to be closer to the messy, early, mid-fidelity stage of product work. By the time something has been presented to a client, the shape of the idea has already started to harden.

A better workflow

I do not want this to become another "AI is coming for everyone's jobs" argument. I do not think the answer is to collapse design, UX, product, and engineering into one all-powerful prompt wizard.

The better workflow is more collaborative than that:

UX frames the problem and the user need.
Product frames the client value and the decision to test.
Design brings taste, hierarchy, brand, and clarity.
Front-end brings interaction, accessibility, design system realism, and browser judgement.
AI helps the team explore options faster.

The change I want is not fewer voices. It is the right voices earlier.

If a company is serious about AI rapid prototyping, it should not treat front-end developers as the people who arrive after the exciting thinking is done. Especially not the front-end developers who can also design.

Put us in the room while the idea is still soft enough to improve.

So, is Figma over?

No, but its role is changing.

Figma is still a strong place to explore visual direction and document a design system. For many teams, it will remain the shared design language.

But when the question becomes "how might this actually work?", the browser has to enter the conversation sooner. Cursor, Claude, Figma MCP, Figma Make, and coded design systems all make that possible.

The real shift is not just tooling. It is status.

Who gets trusted to prototype? Who gets to shape the version that stakeholders react to? Who gets to say, "I think there is a better way," and then prove it quickly?

I think hybrid designer-developers should be much more visible in that space.

Not because we are better than designers, UXers, or product owners. Because we are standing in a useful place: close enough to design to care about taste, close enough to code to understand reality, and close enough to the product to know that a prototype is never just a picture.

Is This the End of Figma as We Know It?