Why Designers Make Better AI Builders (And Don't Know It)

Illustration of a maze

Everyone's talking about developers using AI to code faster. Nobody's talking about what happens when a designer picks up the same tools.

When I started building small products myself using AI, something became obvious: holy shit, this is extremely powerful. I know how it's supposed to work and now I can execute it directly. No handoff, no waiting for a developer to interpret a design file into a pull request.

What most people aren't seeing is why designers have an edge here.

The prompt gap

Go on Twitter right now and you'll see a thousand people prompting "build me a note-taking tool." They get a functional app back, they ship it, and they add to the pile of a million identical note-taking tools with no unique spin.

A designer doesn't start there. A designer is thinking about what issues a user is actually experiencing, finding solutions through experimentation with features. Not just building an app and saying yes to every prompt that comes up.

That difference in starting point changes everything about what gets built. Steve Jobs made this exact argument in 1997 when an interviewer pressed him on why Apple wasn't adopting certain technologies. His answer: you don't start with the tech and figure out where to sell it. You start with the customer experience and work backwards to the technology. That was true for hardware in '97; it's true for AI-built products now.

What my process actually looks like

My workflow is probably different from what you see online. I start with research in my knowledge base. Listing problems I'm having, solutions I've thought of, features, nice-to-haves, delighters. Then I head into FigJam and start mapping flows. It's ugly as hell but it gets me to a point where I know how things are going to work. Only then do I have the confidence to open Claude Code and start building.

Compare that to the typical vibe-coding session: open a folder, start prompting, see what happens.

Scribbles in a notebook

I learned this the hard way. I was building a fitness app. The idea was you create a group with friends, earn points for workouts, and the person with the most points wins. Online-first, competitive, social. Instead of mapping it out I just opened a folder and started sharing snippets of ideas with Claude. "There should be a leaderboard." "There should be groups." "People should be able to join."

Claude built it. Backend, frontend, the whole thing. And then it started adding offline syncing, local storage, offline progress tracking. I never specified it was an online-first platform. Never told Claude it should always pull from the database. I wasn't even aware I was supposed to give that instruction. The whole backend had to be refactored.

After that I started mapping things out properly. Listing my assumptions. Mapping pitfalls. Writing down how I actually wanted things to work so I could prompt for it specifically and tackle misunderstandings early. The result: I go much faster now. Not slower.

The soulless husk problem

Not every vibe-coded product is bad. It depends on the original intent, the mindset the builder was in, the purpose. Is it meant to solve a problem, or is it just a way to grab money while these products are popping off?

You can spot the difference. Claude Code uses ShadCN packages by default. You're quickly able to spot frontends built this way because they use the same components, the same patterns. They feel the same. Non-intentional. Soulless. Like there hasn't been a designer who thought about the process, the flow, what it should look like and how it feels and what problem it actually solves.

Products built with intent are better. That intent is what designers bring. It's the difference between a working app and a product someone wants to use.

Unique product illustration

Design thinking is already the framework

Most designers don't realize this: design thinking is the AI prompting framework. The phases map directly.

  • Empathize. You encounter a problem worth solving. You gather research. Maybe that's desk research or interviews in a small setup. In a larger org it's proper user testing. Either way you're embodying the user before you touch a tool.

  • Define. You articulate the core problem. Which, if you think about it, is already some form of prompt. You're stating what needs to be solved in clear specific terms.

  • Ideate. You use AI tools to think of features, explore directions, generate options you wouldn't have considered alone.

  • Prototype. This is where it gets powerful. Instead of a clickable Figma prototype where you say "pretend this works like this," you can spin up working prototypes. Multiple versions. Modal on the right, modal on the left, a popover, no modal at all. Fully interactive, maybe even with real data.

  • Test. You put those working prototypes in front of actual users. Not "imagine clicking here." Actually using it. That's a massive upgrade over anything we had before.

Design thinking framework illustration

From doing to managing

I don't think design or development is going anywhere. But the jobs are changing in nature. From doing to managing.

Where we used to write code, we'll use AI to generate it, verify it works, handle the pitfalls. Where we used to design one version and ship it, we'll test ten working variations and let users tell us which one is right. We give the input that we want something to work a specific way, then let AI do the actual building.

A hackathon I did with friends proved this is already possible. We iteratively built a product to MVP stage, all contributing input while AI did the execution. It also showed the rough edges: when you work linearly on the same project there are moments where you're literally waiting for the AI to finish the next phase. How multidisciplinary teams should work together in this model is something I haven't figured out yet.

Designers who develop some technical literacy have a real advantage here. Not deep expertise. Big-picture understanding. Knowing that API keys in production code is a massive vulnerability. Knowing which backend to choose. Knowing enough to prompt for common practices instead of shipping risks you didn't know existed. You don't need to understand every detail. You need to understand the architecture so you can direct the AI structurally.

The designers who figure this out first won't just design better products. They'll build them.

© 2026 Gragt Design. All rights reserved.

Amsterdam ->

08:17:07

Gragt

© 2026 Gragt Design. All rights reserved.

Amsterdam ->

08:17:07

Gragt

© 2026 Gragt Design. All rights reserved.

Amsterdam ->

08:17:07

Gragt