In the age when anyone can build, what makes the difference

Ahead of the seminar "UX·UI in the Age of Vibes: 2026 Second-Half Trends and AI-Native Practice Strategies," held on June 29 at the Advertising Culture Center in Jamsil, I sat down for a pre-event interview. These two posts organize my answers, grouped by topic.

Q. What trends should working UX/UI practitioners watch in the second half of the year?

So much is changing so fast that it's hard to pin down second-half trends, but looking at the arc so far, I see three big ones.

1) Design-system-driven workflows

These days there's a clear movement toward keeping a design system in code and using it to speed up planning and prototyping. In the first half of this year alone, services with built-in design systems, like Pencil, Stitch, and Claude Design, shipped one after another.

Building a design system is resource-heavy work whether you do it in Figma or in code. Beyond sheer workload, you have to plan the overall structure and set shared rules across the service, so it was never something every organization could easily attempt. But recently, approaches like DESIGN.md have emerged that support the early stages of a design system well enough that small teams can adopt one quickly, with far fewer resources.

I use DESIGN.md a lot in my own prototyping. Because it lays out design principles, tokens, and component structure in an organized document, it's a great starting point for a discussion with AI. You can start from another brand's DESIGN.md and swap out colors, fonts, and so on. Apply designs and build prototypes on top of a DESIGN.md made this way and you can keep consistency across screens at a fairly high level. It also acts as a bridge the AI can read and translate into different frameworks, which makes it flexible to work with.

That said, DESIGN.md isn't a system precise enough for actual production use; parts of it stay fluid, and long-term maintenance practices still seem unsettled. So once a service matures, the ideal is to build the design system in code and maintain it there. I recently built one in code from scratch myself. Working out which tokens are needed, how to structure components, how to define the various cases, implementing each piece and making it reusable: it genuinely takes time and effort. But with AI's help it has become entirely doable, and the important part is that once it's in place, collaborating with AI gets dramatically more efficient.

2) Not delegation but ensemble: designing the process agents take part in

The second is the question of how to redesign the design process itself, now that agents are entering it as collaborators. AI is often seen as merely an automation or efficiency technology, but that's not the point. What matters is where in the process you bring the agent in, and in what way: designing the weave of the collaboration. In a UX design process full of visual tasks, this matters even more.

There's an important premise here. Coding ability itself is not the essence; you're not writing code to deploy straight to production, it's just one means of making ideas concrete. Ideating in code and drawing screens by hand are not substitutes for each other. For some tasks, sketching in Figma is overwhelmingly faster than drawing a screen in code. The discernment to mix code, Figma, image generation, DESIGN.md, and design systems in the right places is what counts; the mere fact that you had an agent automate something is not.

To explain with a personal service I built recently: I started by shaping a DESIGN.md. From there I drew screen mockups with an AI agent, sketched some of what I wanted in Figma, and let the agent read those through the Figma MCP. When I then asked it to reapply the DESIGN.md, the agent could take my rough wireframe sketches and produce a working prototype with a fair amount of the design applied. In the actual build phase, I defined a simple design system and styles in code, made tokens and basic components like buttons, toasts, and cards, and built the service.

The view of AI as an unconditional efficiency or mass-production tool feels a bit dated now. The core discussion has shifted to how to use it to change existing workflows and design new processes. I recently watched a demo of Meaghan Choi, a designer working on Claude, prototyping with Claude Code; she stressed that because most LLMs, Claude included, are still weak at design, humans have to stay in the loop for craft and decision-making. Today's workflows are built on the premise that people decide what goes into the product.

3) After the fatigue of speed, back to fundamentals

Honestly I think this is the most important trend, more than any technology. For over a year, with vibe coding in the spotlight even in Silicon Valley, the dominant mode was to get results out fast. But as that experience accumulated, fatigue set in, for two reasons: 1) it's only fast at the start, and the further you go the more there is to fix; 2) plenty of results look plausible on the surface while basic UX principles go unmet.

So the keywords rising fastest right now are taste and craft. Cat Wu, Anthropic's head of product, said on a podcast that they hire engineers with good product taste first. Taste is a highly developed standard, and the discussion of how to acquire it, who has that sense, and how it shows up in products has only grown louder. We've reached a point where basic UX principles and sensibility matter more, not less, and a recognition is settling in that building products fast with AI is, to some degree, an illusion.

On taste and craft: innate sensibility is an advantage, but these are also abilities you can absolutely develop. Many UX practitioners, myself included, have trained for years in two ways.

• ·Accumulating visual experience: keep encountering good design (not just aesthetic beauty but well-made micro-interactions, precise buttons and UI) and you learn to see the difference.
• ·An analytical approach: study design principles themselves and you develop the sense to judge analytically whether a given behavior follows them.

UX practitioners have trained this sensitivity from early on, which is a real advantage. It may be an era when anyone can produce output, but the experience, perspective, and finely tuned sense a UX practitioner has built up is not overtaken in a short time.

Q. "An age when anyone can build; what makes the difference." What's the most essential message you'd give UX/UI designers who must prove their expertise in the AI wave?

If I had to put it in one line: "the average is made by technology (AI); the difference is made by people."

AI produces universal, average results. A person's value is proven only at the point where they exceed that average. I see three forces that make the difference: taste, craft, and an understanding of the technology.

1) Taste

In Silicon Valley you hear "taste is the new moat" and "taste is the new 10x" quite often these days. Because anyone can build, what you build is what matters. Taste here isn't a single simple attribute; I think of it as the sum of three things: 1) the points you find appealing and attractive, 2) particular modes of expression and composition, 3) the direction of appeal you pursue.

The power of taste seems to keep growing in the AI era. Some people use the same AI as everyone else and still produce results no one else thought of. The YouTube channel Kim Hamzzi is a prime example: even though its videos are AI-generated, it combined taste so well, with sharp editing, narration, and storytelling that invites empathy, that it strongly appealed to a wide audience. Countless copycat channels appeared, and none caught up with the original. Another example: when GPT-image-2 came out, one user's "shabby doodle style" prompt went so viral on Threads that it ended up as an official GPT image-generation preset. Neither created something the world had never seen; they combined their own preferences in an appealing way.

2) Craft

As AI mass-produces universal results and people grow tired of them, craft has become important again. Craft is the work of making something different by a hair's breadth, and it spans many layers: the visible UI, the UX and its design, the performance of the features themselves.

On the UI side: ask AI to build something and you often get a screen where, just as you're about to press a button, content loads above it and pushes the button down, so you tap the wrong thing. There's no sense that a screen should settle and hold still. On the UX side: a restaurant reservation flow that has you pick the date and time first, asks for party size at the very end, then tells you there's no table at that time and sends you back to the start. If an earlier choice constrains a later one, that question has to come first; AI doesn't think about these dependencies and just lays out questions in the most generic order. Craft is precisely this matter of detail.

Interestingly, there's a line of discussion that as AI makes the average free, craft becomes a kind of luxury good (craft-as-luxury). Building fast is something anyone does now; polishing to the end is becoming rare. And the rarer it gets, the higher its perceived value climbs; a paradoxical situation.

3) Understanding the technology

I hope this isn't misunderstood. It doesn't mean you need to code well or hold deep engineering expertise. The core is understanding, at a high level, how LLMs actually work. Most technologies until now could be used well enough without knowing the principles; learn the usage empirically and you could still produce good solutions. LLMs are not that kind of technology: without the principles you can't use them properly. So we should move past framings like "should designers learn to code?" What matters is not code-writing ability but a general feel for the core concepts of LLMs and for software engineering as a field.

Understanding the technology doesn't mean suddenly digging into transformer architecture. It means checking whether you precisely understand the AI terms you see, hear, and use every day. A simple self-check helps: without looking anything up, could you explain the concept to someone for five to ten minutes? If you can't explain it adequately, it's hard to say you truly know it. Do you actually know what a harness means, or an everyday term like context? Worth checking for yourself.

For example, think about a designer drawing screens with Figma connected over MCP. What I see is the Figma canvas, but the LLM receives that screen broken down into a textual topology. It computes, in text, which elements should go at which coordinates and sends that out, and the Figma MCP converts it back into coordinate values to create components. The way we think about drawing a view and the way the LLM actually operates through MCP are completely different. Without understanding this, you'll never know why the AI can only do this much even though you clearly gave it examples and showed it templates.

If you don't know these terms and principles, you can't judge why the edge cases you hit while working with AI happen. There's no one to ask and no one to answer. In the end you have to know it yourself, and without the underlying principles you can't tell whether it's a system error, something the model fundamentally can't do, or something you're doing wrong. Know the principles, and you can identify the cause yourself and decide how to route around it next time. AI stops being a tool you try once and abandon when it fails, and becomes a tool you steer to your own intent.

Q. You've said that as tools level out, the difference comes from a practitioner's sense and expertise. Concretely, what kind of judgment is that sense?

With little planning experience or a shallow understanding of UX, you end up accepting whatever AI produces as-is. In that light I'd describe the sense as two powers: the power to discern and the power to set direction.

The power to discern is the ability to look at a result, pinpoint what's wrong, and propose how to fix it. For example, AI designs often make a button whose label changes into a spinner that keeps looping inside it; it's actually a fairly awkward UX. Most people either don't feel the awkwardness at all, or feel it but can't say what the problem is or why. A UX practitioner with a good sense can say it clearly: a button is an element that triggers an action, and trapping progress state inside it pins the user's gaze and clicks to that narrow area, and the longer the task runs the harder it becomes to read what's happening. So it's better to show a brief loading state and then announce the result with a toast or a modal, and for hard-to-reverse changes like deletion, better to show a confirmation modal or offer undo for a while: they can carry the judgment that far. What matters is the power to tell right from wrong in the output and to know the reasons.

The power to set direction is the ability to read a single pattern in multiple ways. Some people know something is wrong but feel lost about where to go; some come up with one or two alternatives and stop; some unfold the same situation into three or four frames. What divides that range is expertise and domain knowledge. Even a delete confirmation carries different weight by domain: if the data stays in the DB and is only removed from the UI, the judgment changes completely. 1) Deep knowledge of the domain, 2) how your service concretely behaves, 3) judgment about the situations where the service is actually used: only when these three come together does the right direction emerge. And this decision-making is the most important part of planning, and still an area AI struggles to do on its own.

Part 2 covers where slop comes from, how not to be dragged along by AI, and what UX practitioners should do right now.