Like many of my design and engineering peers, I have been thinking about the future that looms before us, under the shadow of generative AI. Our creative tools are evolving, and design as an industry is shifting. The coming changes are equally exciting and terrifying.
Many of the designers I have spoken to in recent months feel intense pressure to adapt to a world that suddenly looks unfamiliar. No matter what stage of your career or where you’re currently situated in this space, the threat of being displaced by AI is intimidating. It is daunting.
What is generally being referred to as “the evolution of design” feels less like evolution and more like a gradual extinction, a gutting of the values that designers are fundamentally tasked with defending. If you will allow me to explain my point of view, I hope we can push back against the narrowing of design as a practice and the commodification of design as a source of value.
Give me a chance to right-click and detach from tomorrow (I know, cringe 😬): the “inevitable” future we are being told to accept.
My Growing Frustration
I have been watching from the sidelines, reading blog after blog and watching video after video. It is all “MCP this,” “Claude that,” “Look, I vibe-coded this,” “I was able to create this in 5 mins……” and, by far, the one that really annoys me is “Vibe designed this.” The approach is broken, and it is partly our fault as designers for going along with it.
This is not to throw shade at people exploring the tools. I am genuinely impressed by how many are trying to take this head-on. Many believe we just need to keep connecting the parts, and we will get there eventually. That might be true to an extent.
However, I believe there is a compounding effect as we continually reinforce the framing and starting points set by non-designers. The investment in generative AI is driven by the promise of efficiency: the power to increase the output of a skill set while reducing the number of people required to do it.
Understandably, designers are trying desperately to shoehorn our process into someone else’s model or, increasingly, abandoning the process entirely.
The Fear of Irrelevance
Now, I am not ignoring the fear of irrelevance. It is real. The idea that a single prompt could replace designers has shaken people across the industry. That fear drives the scramble.
We move forward along whatever path is laid out for us, not because it is better, but because we are afraid of being left behind.
I was recently watching a video featuring Jenny Wen, the head of design for Claude. She is clearly operating at the frontier of this technology. But her vision for our future was, frankly, disappointing.
She spoke about the “Death of the Traditional Design Process,” arguing that designers no longer have the luxury of time to create polished mockups or conduct deep research. In her view, the designer’s new role becomes “Execution Support”: polishing code and “jamming” with engineers in real time.
“Execution Support” 😵
Execution support is not a role. It is a pain point waiting to be erased. If we reduce our role to “support,” we are begging for our value as designers to be automated away.
When we are told to abandon process for the sake of “shipping,” we are being led directly into what Pavel Samsonov calls the “Form Factor Trap.” Samsonov argues that design is conceptually an iceberg, where the final output hides the complexity of the work beneath it.
When roles are defined solely by deliverables, the rigor of the design process begins to erode.
We end up with artifacts that superficially look complete, but “don’t carry any meaningful information within them, because the decisions they were supposed to document were never made.”
High visual fidelity in the absence of conceptual fidelity means we are designing things that merely look like apps, while filtering out the part of the work that creates the primary user benefit.
I know some folks will say, “We already cut out user research,” and “Execs and stakeholders decide what gets shipped anyway.” This may be true. But the difference is that, as designers, our responsibility is to coordinate and rationalize intention on behalf of those who are not equipped to speak the language of design. “Make it pop,” “it feels busy,” “can you make it more elegant”… how many of us have heard this kind of vague feedback??
So, when we simply streamline to the finish line, sacrificing what would have been an informed outcome, design is reduced to a few characters in a chat box. Progress?
The Money-Driven Gamble
This erosion of our process does not happen in a vacuum. In fact, we have been seeing it for years, even before AI. But it is accelerated by economic pressure and by the promise of efficiency.
Companies are investing heavily in tools that throw everything at the wall to see what sticks. All of this is shaped by promises of “effectiveness” and “efficiency,” but without a clear path to get there.
The industry is gambling on speed, moving as fast as possible to produce output. When technology disrupts an industry, that disruption is defined IMO by one of two things: the money driving the work or the people doing the work. Rarely do we see them working together. You can guess which one is defining today’s AI implementation in our industry.
As a designer and developer who uses AI daily, I appreciate the beauty of the design process but am disheartened by the discipline’s silent surrender to economic pressures. My background in architecture taught me that when money alone drives work, design becomes a luxury for the elite rather than a balanced process. We must shape a conversation where designers, not just capital, define how AI integrates into our field, ensuring we don’t just produce faster output but preserve the nuance and intention that define true design.
So what is that conversation we should be having? What would it sound like if designers, not venture capital or platform providers, shaped the conversation around AI and design tools?
I thought to myself that we need to examine our industry’s relationship with abstraction and trace it back to where the gap between design and code first began to widen, and why something like AI is appealing in the first place.
The Silent Surrender
Let’s go back to the early 2000s. I remember the Macromedia days. Fireworks and Flash were the GOATs 🐐.
These tools were our first step into abstraction, our first departure from needing to understand HTML or write code by hand. But there is an important difference that we tend to forget: they moved us toward empowerment, not away from it.
Fireworks and Flash gave designers who did not know code the keys and the car. What you built visually was what you got. There was no modern developer handoff model. ActionScript was nice, but not required. Most work happened visually, with very little friction. Tools like Dreamweaver felt unnecessary. (Shout out to Rive for bringing this idea back.)
The Disconnect: From Output to Abstraction
The death of Flash and the decline of Fireworks left designers in a “Photoshop purgatory,” a tool never meant for the web, where “slicing” assets felt like digital manual labor. When Sketch arrived, it was hailed as a savior, but it introduced a fundamental shift: direct abstraction. Unlike its predecessors, Sketch removed the tether between the design tool and the final medium. It was a vector-based “infinite void” disconnected from code and semantic meaning. It prioritized the visual editor over the output, creating a specialized space where designers could work faster, provided they didn’t care how that work translated to a browser.
Figma took Sketch’s blueprint and perfected the workflow. It solved the “handoff chaos” through cloud-native collaboration and real-time version control, turning design into a team sport. Yet, the price of this efficiency was a deeper layer of abstraction.
At its core, Figma remains a vector editor where a “box” is just a box and not a <div>, a <section>, or an <a> tag. We’ve reached a point where best practices replace technical knowledge; you don’t need to understand CSS; you just need to master Figma’s internal logic. Figma’s API is a language unto itself, prioritizing its own proprietary structure over web semantics.
We have achieved unprecedented collaboration, but we’ve done so by moving further away from the medium we are actually designing for. We are no longer building for the web; we are building around the canvas.
The Translation Layer Problem
The abstraction introduced by Sketch and cemented by Figma created a translation layer that didn’t exist in the era of Flash and Fireworks. While those older tools had flaws, they offered a direct relationship between design and output; what you created was the website. Today, we have traded that directness for an interpretation gap.
We accepted this trade-off with the hope that technology would eventually bridge the distance. Instead, the gap has widened. The abstraction is no longer just visual; it is conceptual. Designers have stopped thinking in HTML elements and CSS properties, replacing them with the proprietary logic of frames and auto-layout.
The AI Pivot: Trading One Abstraction for Another
The promise and savior we are told has arrived is AI, with the industry pivoting toward natural language interfaces to solve the design-to-code gap. The pitch is seductive: describe what you want, and AI generates the output. However, I argue this trades a manageable abstraction for an unmanageable one.
Visual tools like Figma are semantically disconnected, but they are precise. A 300px rectangle is unambiguous. Natural language, by contrast, is fundamentally fuzzy. A prompt as simple as “make this button bigger” is a guessing game:
- Does “bigger” mean increasing the height, the width, or both?
- Does it imply more padding or a larger font size?
- Should this change apply to a single instance or the entire system?
We haven’t solved the translation problem; we have simply replaced the manual labor of handoff with the imprecision of prompting. Now, you might be furiously typing, “Better prompts will solve this, MCP! Skills! Context engineering! You don’t get it!” but all of that is still language, still text. I wanted to test how close language can get us to a clear design.
The Visual Mirror Test
The experiment was simple: I had an AI describe a high-fidelity design, then immediately try to regenerate it from its own description. I even set the AI up for success—a closed feedback loop where it basically talked to itself: image → description → new image → compare/refine → repeat. No human intervention.
The result was telling. The AI nailed the form (dashboard, buttons, drop shadows, etc.) but struggled to close the gap. It produced an “uncanny replica,” impressive from a text prompt alone, but definitely not the design. The goal wasn’t to bash AI; it was to verify the ambiguity of language against a clear visual target. I attempted to mimic the designer’s “mind-to-hand” connection, but for AI.
Let’s be honest, if I gave a human designer the same 1:1 recreation task, the outcome would be far closer. I was just “playing scientist” before stumbling across a deeper study on NLP, appropriately titled “A comprehensive review on resolving ambiguities in natural language processing.”
The Cost of Ambiguity
We are attempting to build precision software with the most imprecise tool available: natural language. The paper indicates that NLP requirements fail to eliminate ambiguity. While direct visual tools allow for immediate disambiguation (because a line is simply a line), chat interfaces force us to abandon our most efficient tools. We are trading the mind-to-hand connection for a linguistic gamble.
The MCP Gamble
The industry currently bets on the Model Context Protocol (MCP). The theory is that giving AI more access to the “truth” of a design system will stop the guessing. However, even with a unified context, the “strong AI problem” remains. A library of components does not provide the domain knowledge or organizational purpose required to know why a specific component belongs in a specific place.
The friction in our workflow is not a lack of data. Instead, it is a lack of translation and intent. By forcing more context into these systems, we simply invite context rot and complex RAG implementations (which have their issues, too). We are building Rube Goldberg machines of connectivity while moving away from the simple precision of human thought.
Inspect DetailEmerging Tools and the Path Forward
Many promising emerging tools fall into a familiar trap: they rely on chat interfaces to translate ambiguous language, often failing to capture semantic intent. Visually, a component may look like a button, but without technical context, its underlying purpose is lost. We are then forced back into imprecise dialogue to bridge the gap. Other tools double down on the traditional “designer makes a picture” workflow, using AI simply to interpret the static image. This doesn’t solve the core problem; it merely shifts the labor to the AI, forcing us to spend more time auditing what the machine “thinks” it sees.
The question remains: why are we hesitant to build tools that capture intention while challenging us to design in the actual medium of our products? Our tools must push us as much as we push them. A tool should understand what is being drawn, making frameworks like MCP semantically useful rather than doing the heavy lifting of guessing intention. We have been dealing with the abstraction layer for so long, a debt we have incurred, that we are now sadly paying for it as AI looks to solve or replace us altogether.
There is some hope, though. Some projects are attempting to tackle this problem directly. Honorable mentions like Wix’s Codux, Webflow, Pinegrow, and Webstudio have all been tackling this abstraction for some time, but one tool called Onlook is an open-source project worth watching; while it is currently only focusing on Tailwind and React, it actively builds a shared environment for designers and developers. While others like Pencil, Paper, and Penpot are amazing tools, they lean into open standards and are still just vector tools or rely on AI too heavily. A standard is great, but a standard is only as strong as the community defining it, much like our work with the W3C Design Tokens Spec. We must work together on a spec that serves as a minimal, meaningful drawing layer or do away with it altogether.
I am personally exploring the question: Can we remove the translation requirement entirely? What if what you see is what you get, code-wise, from the very first click? In this model, drawing a box isn’t just an artistic gesture; it is a semantic decision where every visual property maps 1:1 to CSS. It transforms the design tool into a “DOM inspector for designers.”
This shift mirrors the evolution of architecture through Building Information Modeling (BIM). Before BIM, architects simply “drew lines” to represent walls. After BIM, those lines had to be defined: What is the material? What is the structural rating? What is the height? This transition introduced a meaningful friction. While it initially slowed designers down, it forced them to design for the reality of what was actually going to be built. We need a similar evolution in digital design. We must move beyond “drawing pictures” of websites and start defining the semantic structures of the web itself. Intention, the synthesis of conversation, research, and experimentation, is difficult to automate, but it can be codified through design records, research databases, and product-specific guidance. A chat box cannot be the only bridge between our minds and the final product.
The design process must be empowered by AI, not replaced by it. AI is an accelerant, but if we don’t build the full track, including the necessary detours, we will inevitably end up somewhere we never intended to be.
A Call to Action
We must demand more from our tools and ourselves. We need design tools that:
- Understand the semantic web and speak the language of HTML, CSS, and accessibility.
- Capture design intent, not just visual artifacts.
- Close the gap between design and code without requiring natural-language translation.
- Empower designers to think in the medium they are designing for.
This is not a rejection of AI; it is a refusal to accept the gap between design and development as inevitable. Abstraction is a choice, not a requirement. We must stop being reduced to factories producing artifacts and instead create workflows where intent is not lost in translation; only direct expression, supercharged by AI.
Originally published on LinkedIn(opens in a new tab)