A developer's perspective on design in the age of AI

As developers, we’ve seen a massive acceleration in AI adoption over the past year. Other areas of IT haven't caught up, though. Especially in the planning and design phase, where AI is still used in a limited, random way.

Yet, messy moments like this often have the most creative potential. Moments when roles shift, when UX engineers start thinking like developers, and vice versa

In this article, I’m going to outline the steps involved in project design, sharing what I've seen work and fail from a developer's perspective.

AI prototyping: validate ideas before development

Writing code has become cheap, so why not use interactive prototypes to validate the raw idea before moving on to final development? It’s reasonable because it allows the customer to test an apparently realistic version of the final interface in a short time, but it cannot be the starting point of development. Vibe-coding platforms produce increasingly cleaner code, but without foundations. If you want to get a solid and scalable application, the prototype must be thrown away and rewritten starting from the software architecture, which at the moment cannot ignore human discretion.

The prototype can be an excellent brainstorming tool with the customer at a very early stage of the design and can be used at the end to quickly validate a rough idea on the market, but it must be clear that even in the design phase, and not just in the development, some steps are skipped: the most important are the wireframe and the design system. And if the design system can always be done later, the wireframe must be done first.

Wireframing: where human input still matters

They say that the best wireframes are created with pen and paper, and that’s absolutely true. This is the most human phase of project planning. Many designers I’ve spoken with think that this is the stage where AI offers the fewest benefits.

First we have to distinguish between creating a project from scratch and evolving an existing one (redesign or replatforming). In the first case, some designers use AI to gather ideas or to help analyze user data and pull together requirements, but the actual wireframing is usually done by hand or with standard tools. Any AI wireframing tool essentially just places black squares on a white background. Doing it by hand is faster, and it doesn't burn tokens.

For existing projects, things are different. Tools like Claude Design can connect to a Design System or a codebase, enabling a design process that takes existing assets into account. However, it’s not wise to give AI too much free rein. Keep in mind that the more technical aspects of the work, including UI design and interactions, can largely be handled by AI later on. Right now, the goal is to lay the foundations, and you want to stay fully in control. For all subsequent steps, we can rely on AI with greater confidence.

Design systems: creating a foundation for AI coding

This is the stage of the design process where AI brings the greatest benefits. The goal is to create a clear Design System that AI coding tools can actually use.

Many designers face a dilemma: whether to revolutionize their workflow by switching to generative design tools like Claude Design, or to stick with existing tools, usually Figma, which are progressively integrating AI into their interfaces.

There is no one-size-fits-all answer, and we are living in a time where today's answer probably won't hold tomorrow. What we can say now is that the more you delegate to AI, the less you are able to do manually. This also applies to code: the more generated code a project contains, the harder it is for a developer to make changes without AI.

Therefore, if you already have a complex project in Figma with a robust Design System and want to retain full control, I recommend sticking with Figma. You can use available AI tools while still having access to the native design features that are unique to Figma. AI add-ons make it easy to extend and reorganize components, add states, identify inconsistencies, and generate mockups.

On the other hand, if you are starting from scratch and need to build the entire Design System, you can use Claude Design. You can generate an initial draft by connecting it to a codebase and using existing components as a starting point for iteration, or by importing existing designs to serve as a base. You can even import a ready-made Design System and apply it to an existing set of components. However, as I mentioned earlier, this approach isn't really worth it because you lose the ability to edit components directly in Figma. You can still use Claude Code to apply a visual style to the code. But that's a development task, one that UX engineers could also take on, building the component library themselves.

Design-to-code: connecting components and code

The main challenge here is establishing a correspondence between design system components and code components. That's particularly hard when not starting from scratch or when working with a complex framework (imagine aligning design system components with Magento templates). Even under ideal conditions, such as software built from scratch with no layout constraints, mapping code components to the design system is far from trivial.

The simplest and most common approach is to specify the desired components directly within the prompt. This works well for developers who work in short and clearly defined sessions. However, for those delegating entire features or even the whole application, this method risks leading to errors and arbitrary associations.

The second option is to use Context Files (that is, Markdown instructions for AI agents): we can map design system components so Claude Code knows which ones to use and when. If we are using Figma, the mapping works by connecting the codebase directly to the design through Figma's remote MCP server. With Claude Design, however, synchronization is native and bidirectional (Claude Code reads Claude Design, and vice versa). The downside is that Claude Design components lack unique IDs (unlike Figma nodes), meaning the mapping is not that strict.

The last option is for when we also want to map component states or when we are dealing with a more complex application where there isn't a single template for each component (think of Magento or Shopware). With Claude Design we have to spell everything out in the prompt or rely on trial and error through progressive refinements. With Figma, instead, we have an extra tool: Figma Code Connect. It creates an explicit mapping between a node (including all its states) and an actual component or code example. Where the codebase lacks a single corresponding component, we can even add text comments to clarify how the component should be used, without getting bogged down in implementation details, which remain the responsibility of Context Files.

Any AI coding tool is now capable of generating components based on the mapped design system. So with any of the options mentioned above (except perhaps the first, where development remains almost entirely manual), a designer can build their own component library independently, or, in complex or legacy applications, with a little help from a developer.

How AI is changing developer and designer roles

Developers, for their part, could focus on software architecture and just 'consume' components built entirely by UX/UI specialists.

This role shift could really improve the quality of the final product, provided that designers and developers work more closely together than they currently do, from wireframing and component development to the crucial step of drafting Context Files.