Blog

AI design tools keep promising the mythical city. Every few months, something new shows up and for about ten minutes it feels like this might be it. The tool that finally collapses the gap between idea, design, prototype and build. Google Stitch, Claude Design, Figma Make, MCP workflows, and whatever OpenAI has bubbling away in the background are all circling the same patch of dirt. Everyone can smell gold, and fair enough. We have already watched AI agents muscle their way into IDEs, terminals and development workflows with frightening speed. Design was always going to be one of the next big fronts.

The player who cracks this properly does not just get a nice little UX tool. They get to be one of the main suppliers of shovels in the broader AI gold rush. Most of the shovels still feel like they come with assembly instructions. Useful? Absolutely. Impressive? Often. But still not quite the thing.

Prompt-to-UI tools are great for getting momentum. Design-to-code tools can save real time. MCP is genuinely powerful plumbing. But most of this still feels like we are trying to make handoff less painful, rather than asking why handoff is still the centre of the workflow.

I recently sat in a Figma webinar where they showed off some genuinely powerful MCP-driven features. The loop between a vibe-coded prototype or product and the design canvas looked fairly frictionless, at least compared to the messier version of this workflow I see real people trying to use today. But it was still a loop. There was still a handoff, still a chain of tools, and still a sense that the designer needed to understand which platform owned which part of the process, what the agent was doing, what failed quietly, and why this magical future of design work suddenly needed someone to explain MCP, GitHub, plugins, markdown files, or whatever else had wandered into the room.

That is where the dream starts to fray for me. I have found myself in impromptu upskilling sessions with lifelong designers and product thinkers because these workflows are still unintuitive enough to slow people down. These are not people who are bad at technology. These are smart, experienced people who know how to think about products, users, systems and trade-offs. But a lot of the current AI design tooling still asks them to meet the machine more than halfway.

Designers and product managers are used to well-crafted, human-centred tools. The irony of the current AI design wave is that a lot of the workflows being sold to designers are not especially designer-friendly. They are powerful, but they often feel like technical plumbing dressed up as creative freedom.

This is also where the Figma Make question gets a bit awkward. If the most streamlined workflow is a handoff from one AI-coded environment into Figma, or from Figma out into another agentic environment, then what are we really saying? Clearly, the design canvas still matters. Figma’s justification for it holds water. Prompting to perfection is painful, even in tools like Claude Design and Google Stitch where you can target a component and tweak it. But that gap has also closed enormously in a very short amount of time, which is exactly why I do not think “handoff to another tool” is the final answer.

AI in development took off when it became native to the places developers were already working. Inside IDEs, terminals, repositories and the flow of the work itself. The agent became useful because it could act where the real work was already happening. For designers, the real work still mostly lives on the canvas.

So, to me, the endgame is not another connector, plugin, export flow, or translation layer. It is a design canvas where the thing being designed is already real, interactive, renderable software. Something Figma-like, but code-native. That does not mean designers all need to become full-time engineers, and it definitely does not mean dumping everyone into VS Code and wishing them luck. The canvas matters because direct manipulation matters. Frames matter. Components, variants, layout tools, comments, flows, interaction states and tiny spacing tweaks all matter. Yes, even the three-pixel nudge that makes everyone else roll their eyes.

The dream version keeps the parts of design tools that designers actually need, but underneath it all the work is alive. You are not making a picture of a product, then asking someone else to rebuild the real thing later. The thing you are designing is already the interactive prototype.

That is where a design based AI platform becomes much more interesting to me. The agent should live inside that same environment. It should understand the canvas because the canvas is the product taking shape. It should be able to make broad sweeps, generate alternatives, clean up inconsistencies, wire up states, suggest responsive behaviour, apply a design system, and help expose the weird bits before they become someone else’s problem. And when it gets something wrong, which it absolutely will, the designer should not be trapped in prompt-and-pray mode. They should be able to touch the thing, move the button, rewrite the label, change the spacing, override the agent, keep the useful bit and bin the nonsense.

AI gives speed, breadth and iteration. Designers still bring taste, judgement, context and intent. The more the machine can generate, the more important it becomes to know what is actually worth keeping. This is why the “AI will replace designers” version of the conversation feels too flat to me. Real product work is messier than a demo. It has edge cases, accessibility requirements, business rules, legacy systems, competing stakeholders, strange user behaviour and content that refuses to fit into the neat little card someone designed in the happy path.

A shiny generated screen is easy. A good product experience is still hard.

A version of this future is coming. Make, Stitch, Claude Design and whatever comes next are all circling the same idea: an agentic design canvas with granular control, real output and less distance between idea and product. The winning version may not look exactly like Figma, but it will need to understand why Figma became central to the work in the first place.

The future probably asks less of us in raw production and more of us in judgement. Much like we no longer write in assembly for everyday software work, future product teams may spend less time writing line after line of higher-level code and more time understanding how systems come together as a broader experience. The valuable skill becomes knowing what good looks like, how the experience should behave, how to troubleshoot when the magic breaks, and how to keep human intent intact.

That is exciting, and it is going to change the shape of teams. As squads get smaller and tools get more powerful, the coordination effort does not disappear. It shifts. The people using these tools will need to understand design, technology, product logic and the broader experience well enough to steer the machine without being swallowed by it.

The search for El Dorado was relentless, costly and mostly fruitless. A myth powerful enough to keep people marching long after they probably should have stopped. AI Dorado feels different because some version of the destination is probably inevitable.

But that does not mean every shovel is gold.