Is the design tool becoming irrelevant in the age of AI

[Sulcalibur]

Hey everyone!

I’ve recently been tasked with auditing and exploring the intersection of Design and AI at my workplace. I’m looking at this holistic landscape through the lenses of our User-Centred Design (UCD) team, Product Owners, and Developers.

The goal? Find smart, modern ways to design and build using cutting-edge tech stacks. We’re deep-diving into everything from the handoff process and documentation to accessibility (WCAG compliance), reusable components, and strict, scalable design systems.

I wanted to drop my current thesis here to spark some conversation and gather your insights.

My Hot Take: The De-centering of the Design Tool

I’m starting to lean into a realm of thinking where the specific design tool we use is slowly becoming less important. (No disrespect to Figma, Sketch, or the amazing Penpot team - hear me out! )

Think about how modern software development works:

• You have a team of developers all contributing to the exact same codebase.

• The text editor they use is completely interchangeable. One dev might swear by VS Code, another is testing out Zed, and a third is a purist running Vim.

• It doesn’t matter. At the end of the day, they are all editing the same source files and committing to the same repository and also pulling the latest updates.

The Proposal: A Two-Way Unified Design System

Why can’t design follow the exact same paradigm?

Right now, there’s an artificial wall between design files and code. But what if the Design System itself is the single source of truth, and the design tool is just a themed skin to view and manipulate it?

Imagine a workflow where:

1. The Design System rules the kingdom. It dictates the design tokens, layout logic, and component behaviours.

2. The tools are agnostic. Whether you prefer Figma, Penpot, or Sketch, the tool simply reads from a standardised ruleset (like a universal JSON schema for design tokens).

3. True two-way synchronisation. An update made to a component in Penpot is submitted to the central Design System, which then compiles cleanly into HTML/CSS/JS and simultaneously syncs back to update the component libraries in Figma or Sketch for the rest of the team.

Pipedream or the Next Logical Step?

Instead of being locked into a monolithic ecosystem, this would create a beautifully relaxed, versatile, and interoperable design process. The tool becomes a matter of personal preference, just like a developer’s IDE.

With AI rapidly accelerating how we translate intent into code and UI, this feels like where the puck is heading.

What are your thoughts? Are we moving toward a tool-agnostic future?

• Has anyone successfully bridged the two-way sync gap between code repositories and canvas-based design tools without a massive headache?

Thoughts???

[findut]

Tool-agnostic mindset

Great point, and really interesting perspective! I also agree with the tool-agnostic idea: you can create great work with cardboard, scissors, pencils, and a photocopier just as much as with Photoshop.

That is why I think moving toward a more connected and system-driven workflow is a valuable direction to explore.

Keeping creativity in the conversation

At the same time I feel the creative dimension deserves to stay front and center in the conversation.

It is not that this kind of synchronisation limits creativity in itself, but we should be careful not to treat the design system as something untouchable.

Exploration, intuition, and visual experimentation still need to play a primary role, otherwise there is a risk of repeating the same solutions simply because the system starts to feel more important than the creative process it is meant to support.

Just my point of view as a graphic designer who is not strictly specialised in UX/UI

[mattd7800]

I like the direction you’re going in your thinking. I believe what you’re saying could be possible, the problem is the standardization of formats. Software development, having a long history of open formats and standards, didn’t evolve using proprietary technologies tied to proprietary tools. Any basic text editor could always be used to write code. Where development and design differ is that the files and formats used in design were created as proprietary technologies tied to specific design applications, whether that was Photoshop and Fireworks back in the day or Sketch and Figma more recently. While there has been some effort to standardize parts of the design system, such as design token JSON (which you mentioned), we’ve still got a long way to go until we have truly open design formats that are as tool-agnostic as those on the developer side. It’s also a hard battle because every design tool wants to stay within it’s own formats. Even design token JSON has very limited support in Figma, and most of that is provided by third party plugins. I commend Penpot for at least fitting in as much open standard formats as it can, but more can always be done. We need an open design file format; something that includes features such as frames, layout, pages, components, etc. Maybe I’m just an old cynic, but I’m afraid that even if we eventually get more open design standards, the tools will drag their feet to adapt them, and even then we’ll only get import/export for part of the specification.

[Sulcalibur]

Speaking of formats it reminds me of .psd files that could be opened in various different applications. I used to work in Affinity Designer a few years back and handover my files in PSD’s to a design agency and they bloody loved them. I wasn’t tied to Photoshop but the output was there.

Maybe a standardised format is what is required. One that all apps could and should adopt.

[juan.delacruz]

This is a fascinating conversation. Thanks, @Sulcalibur, for starting it, and thanks to everyone who has added to it.

From my perspective, the most interesting question is whether the design tool will become less central.

Today, we expect it to support exploration, define the final interface, document the product, and act as the source of truth for development. I suspect those responsibilities will become more distributed.

The canvas will still matter because direct manipulation, spatial composition, visual comparison, and collaborative critique are part of how designers think. But the design file may become one representation of a broader product model rather than the place where everything begins and ends.

This is where declarative design becomes especially relevant. Instead of describing only what something looks like, we can also describe what it is and the rules it follows: its semantic design tokens, states, responsive behaviour, content constraints, and accessibility requirements.

That shared model could then be accessed through different interfaces, including a visual canvas, code editor, documentation, design token manager, or AI agent. The canvas would remain valuable, but as one way of reading, exploring, and editing the system.

The missing piece is still a complete, open, and tool-agnostic representation of design intent. Design tokens are an important step, but they only cover part of the product. They do not fully describe component anatomy, variants, responsive behaviour, interactions, semantics, content rules, or accessibility.

This also makes true two-way synchronisation difficult. Generating several outputs from one canonical model seems achievable: a Penpot representation, React components, native components, and documentation. The harder problem begins when all of those outputs can be edited independently and are expected to remain perfectly synchronised.

Changes made in code may include technical decisions that have no equivalent on the canvas. Visual groupings may not map to real components. Different implementations may produce similar results using very different structures. Some information will be lost, conflicts will happen, and the system will need clear rules for deciding what can be merged automatically and what requires human review.

AI can help interpret intent, propose mappings, translate between representations, and explain conflicts. But it makes the need for a source of truth stronger. A prompt is temporary. The underlying model needs to be persistent, inspectable, versioned, and testable.

We also need to preserve space for exploration. Designers should be able to experiment, break conventions, and work outside the existing system. Moving an idea into production should still be a deliberate decision. Not every experiment needs to become a new component, variant, or design token.

So I see the design tool evolving from a closed container into a visual editor, inspector, and debugger for a broader declarative product model.

At Penpot, we are very interested in open standards, design tokens, APIs, plugins, and agent-based workflows. These are useful steps in that direction, although I would not claim that Penpot, or any other tool, has solved the complete model yet. (At least not for now )

The larger question is whether we can create an open, portable, machine-readable representation of design intent that different tools, people, and AI agents can work with without losing its meaning.

That would not make the design tool disappear. It would give it a different role within a new design tooling architecture.

[Sulcalibur]

@juan.delacruz

The larger question is whether we can create an open, portable, machine-readable representation of design intent that different tools, people, and AI agents can work with without losing its meaning.

That would not make the design tool disappear. It would give it a different role within a new design tooling architecture.

Exactly! This is my thoughts also and how I see things moving.

[Nikola]

Very interesting topic. When people get to the point of talking about new standard that will finally solve the issue of having multiple standards it’s obligatory to share this xkcd’s comic (how come no one did it already?). But there are real word examples of successful stories like Universal Scene Description (USD) for 3D industry or PDF format.

The biggest issue I think is that if you want to have a tool that designers can use and cover everything developer can do in code means that designers need to understand all the concepts of the code and be able to do it in design app. Which would bring designers closer to developers, or even make them ones. Which is happening gradually with all the nocode tools and apps similar to Penpot.

I remember my learning path of UX/UI designer. When I started to do UI design, there was only Sketch but I didn’t have Mac, so first of my designs were done in Photoshop and Illustrator, which didn’t support multiple pages back then. It was pure pain. Then Figma came, and it got much better because they had multiplayer, constrains and probably primitive components. I needed time to understand how constrains work, I never seen concept before. Latter they added variants in components, you could have button states in the same component! Only later they added properties. Then they added autolayout (flex), which was total game changer, I needed a lot of time to understand the concept. Then they added tokens, advanced prototyping… All these concepts are mimicking what you can do in code, so I learned what code can do in a way. But still it’s not even close what can be done in code. If you want design=code you would get very complex UI and designer would need to learn more concepts. For example classes and selectors, which can add so much confusion and brake things if they are not used properly. So far tools that use classes did not solve the UX complexity and cumbersome UI (everyone is basically coping what Webflow did 13 years ago).

If you want a tool closest to code I would say look at Webflow, or better say Instatic (just a week old FOSS alternative). All the things you can define to a simple container are crazy, all the new units you need to learn (rem, em, vh, vw, %…). You gain control, but you lose flexibility of the exploration and design. But I still think it can be worked in a way that it had better UX.

What Figma announced few days ago and what Framer already has is Code Layers (custom components in Framer). It allows you to add element with arbitrary code with defined UI controls. This is nothing new with nocode website/app builders but what’s new is that I think we see it first time in a dedicated design app. So this means that you can extend the functionality of your app and allow non code users to control them with UI panel. And of course you can use AI to make those code layers for you. Sounds similar to plugins? Not really, this feature allows you have a new object type on the screen, where plugin gives you new tool to manipulate what’s on screen.

What this does is bridging the gap between what code can do and what you can do natively in the app. Is this a solution? I would say not at all, this is a band-ade made by developers for us designers. As a designer you have limited control over it, use UI given to you by a developer or AI. You can ask AI to change the code for you, but since you don’t know to code you will never have full control, and as always with AI it’s unpredictable what it will do, how long will it take and how many tokens it will spend.

Conclusion? I love what Penpot is doing on this field. Tokens are implemented following W3 standard, flex and grid is actually following css logic and most of all - it’s opensource. I do believe we will get more and more features that are true to existing standards and that will bring us closer to the ideal we are speaking which is design=code, and where it doesn’t matter do you first start with the code or with a design.