The power to escape AI slop

This is the second post organizing the pre-event interview for the June 29 seminar "UX·UI in the Age of Vibes: 2026 Second-Half Trends and AI-Native Practice Strategies."

Q. With the same tools, one person's output becomes AI slop while another's is a cut above. What's the most striking 'one-notch difference' you've witnessed firsthand?

Most plainly: start building just to see results, with the initial planning not really done, and you get slop. I see two main ways things turn to slop.

1) The UI side

Go straight into implementation mockups without an initial design guideline, and the style that happens to form early carries into every next screen and the whole thing slides toward slop. The same happens when the details AI habitually gets wrong go uncorrected. That's why building the design system in code first, or at least starting from a DESIGN.md, helps so much these days: you can quickly get visual output that's both consistent and high-quality.

2) The UX planning side

Honestly, UI problems are the easy ones to fix; this side is more serious and slower to improve. The current workflow of making things visible fast and polishing from there plays its part in producing slop. Once a result is visible, humans think about what comes next based on that visual alone, so ideas stop branching in different directions and converge on one path. Early on, your own intent is often not yet clear, and even when AI's output diverges from what you had in mind, you let it slide, figuring you'll fix it as you build. But because it never started from the essence, the gap grows out of control the further you develop it, until it's too hard even to fix. That's how it often becomes slop.

I ran into this a lot when I first used AI, so late last year I overhauled my process completely. In the past I even started the popular way, filling in the blanks of a planning-doc template together with AI. In practice it didn't work, and I ended up dropping it. Now I 1) first pour out everything in my head (it's important here not to let AI steer my thinking, and to draw it out entirely at my own pace), and 2) use what's gathered as raw material to shape a planning document together with AI.

Step 1) is a genuinely hard, painful process. Turning thought into structured language is inherently difficult. So while organizing ideas with AI, the temptation keeps returning: skip the painful part and see results fast. I think you escape slop only by pushing that temptation back as far as you can and enduring it.

One thing I recommend here is a voice dictation app. I use one called Typeless: it takes my rambling speech and has an LLM tidy it up while preserving the context, which is remarkably effective in the early stage of drawing thoughts out. Typing often becomes a bottleneck that hampers thinking and tempts you to skip the planning stage. Ideate out loud, as if talking with a person, and you can move high-quality thinking, full of your original intent, onto the page.

Q. Where does the decisive difference lie between people who use AI well and people who get dragged along by it?

The person who outsources their thinking is the one who gets dragged along. In Silicon Valley, "Don't outsource your thinking / judgment" comes up all the time. The easiest way to hold onto it is this:

"If the discussion with AI doesn't hurt, you're being dragged along."

If the process of drawing out your own thinking during ideation or planning isn't painful, odds are very high you're being dragged along by AI. As I said above, pulling thoughts out into language is inherently hard, and refining them into polished writing is harder still. So without noticing, you come to depend on AI. When the conversation ends you feel your thinking was fully reflected; often it wasn't.

In that sense, one of the AI features I'm most wary of is AskUserQuestion. I say something, the AI offers four or five options, I answer, and we move on. In that instant, the range of our options and our thinking has already narrowed, anchored to what the AI probabilistically generated. So when I'm planning, I often instruct the agent up front not to use AskUserQuestion before we ideate. You have to build the strength to think for yourself, and keep thinking even while talking with AI. The pain is like strength training: if the workout doesn't hurt, it barely counted as one.

Q. Has the very definition of 'UX expertise' changed in the AI era? What has become more important, and what less?

In the past, implementation and execution costs were so high that planning was treated as a mere preliminary step before building. There were plenty of misconceptions about the barrier to entry being low, and when asked what UX expertise even was, people commonly thought "making screens pretty." That UX is not simple aesthetics but the process of designing the right experience for a service and thinking through flows and features was terribly hard to argue, given how qualitative and hard to measure it is.

Then, with the AI era, people began to feel the value of experience design and planning firsthand. As they realize planning is actually quite hard, existing UX practitioners find themselves at an advantageous starting point. But that's only temporary. Planning ability, too, is a domain that training catches up with; give it time and the gap closes. So planning ability alone is no longer a moat. What ends up mattering, I think, is an understanding of agent engineering, and the ability to spread it beyond the individual into the organization.

People often say you should vibe-code, you should build things yourself, but that alone isn't enough. Vibe coding is one method, one phenomenon. To be competitive you need an understanding of agent engineering itself, and underneath that, the understanding of the technology I talked about in part 1: LLMs and software engineering, integrated. Max Schoening, Notion's Head of Product, answered "yes" to whether designers, PMs, and planners should code, and "no" to whether they should write the actual code that ships to production; I think the same. Ask first what the coding is for. Being so taken with the tools that "made with AI" becomes a badge in itself is getting things backwards.

Judging the value of automation is also hard. Building an automated process costs something; so does maintaining it; so does running it. So you have to weigh 1) whether the automation is truly needed, 2) whether the task matters that much, and 3) whether it's worth this much resource. This sense only comes from doing it yourself, so early on it's important to try a lot and find your own balance.

Finally: right now most of us use AI only at the individual level, but carrying it into the organization and converting it into whole-team productivity is becoming important. When a UI prototype is built in code, how do you share it? Should teammates make GitHub accounts and manage it with Git? What are the collaboration rules? Ways of working have to shift toward an engineering perspective. Fortunately, UX practitioners have spent years collaborating with developers, designers, and every other role, so the vocabulary and the technical terrain are already familiar. Starting the change precisely from that familiar ground is what matters.

Q. If you had to pick one or two tools UX practitioners should get their hands on right now, what are they and why?

A coding agent: use Claude Code or Codex, one of the two, without fail. Codex in particular is a well-made app, excellent in engineering and UX alike. If you prefer ChatGPT, use the Codex app; otherwise use Claude Code, through the desktop app's code tab or the CLI. If the terminal isn't familiar, start with the desktop app and move to the CLI. Once you're used to it, the CLI wins on extensibility and efficiency, and you can run several tools together in one terminal. These days the two differ little; it's a matter of preference and task fit, and once you're good with one, switching to the other isn't hard. Along the way, try setting up Git and connecting a GitHub account with AI's help.

The second is a voice dictation app like Typeless, which I mentioned above. It eases, though never erases, the early pain of planning without outsourcing your thinking. At work you're not ideating every day, so one option is to set aside an hour or two in a meeting room and try it there.

Beyond that, I get a lot of questions about dedicated UI design tools. Tools like Claude Design and Pencil keep appearing, but honestly, once you use a coding agent well, they don't feel essential. Handle a coding agent well and you can build things to your own taste; I used many tools before, but these days I converge on Codex and Claude Code. UX practitioners mostly know Figma already, the Figma MCP works well these days, and a Figma AI agent launched recently. Connecting a coding agent to Figma over MCP gets you quite far on its own, so I keep wondering how essential it really is to learn a new dedicated design tool in depth.

And honestly, as important as the tools is the plan you're on. "Tokens are power" is a phrase now, and a company's "token welfare" has become a talking point; that's how much AI costs matter. To really put Codex or Claude Code to work, a $20-a-month plan hits its limits fast. To work properly, something in the $100 range helps a great deal, and even without company support I think it's worth investing that much personally. That said, you don't need to start at $100; start at $20 and upgrade when you hit the usage cap. What matters is the experience of pushing AI all the way on the best model available, and drawing on its ability to the fullest.

Q. In an 'age when anyone can build,' what should UX practitioners do first to turn their expertise into a weapon?

People say anyone can build now, but that means the possibility has opened up, not that everyone has already built. Start by actually making something of your own. That's what makes real judgment possible.

Concretely, I hope you research yourself and build at least one thing that relieves an inconvenience of your own. Solving your own problem is the most authentic and the best-motivated path, and you learn an enormous amount along the way. I still think making something genuinely good with AI, not slop, takes a lot of effort, time, and money. All the more reason to work on your own problem, so you can hold on to the end without giving up.

As fast as it is to start, plenty of people give up and quit just as fast. So to have a weapon of your own, put in the time and do the unglamorous digging; that, I think, is what real expertise means in this era. People who once lacked the skills can now catch up given enough time. So don't stand still while they do: pile up as much singular experience as you can, the kind no one can teach and no one else can know, and pull further ahead. Through that experience you can 1) build your own frame for combining your UX knowledge with AI, and 2) turn it into assets or content. In a time with no settled answers yet, just making something yourself is already a real edge.