When Everyone Can Build, Who Owns Quality?

The PM shows up with a prototype they built in Cursor over lunch. The engineer generated three versions of the settings page before standup. The designer pushed a PR.

Nobody is waiting on anybody anymore. That part is good.

The part nobody planned for is what happens to quality when everyone can build. When a first draft costs nothing, you get a lot of first drafts. Some are great. Most are fine. A few ship with an API key in the code.

We asked three design leaders who live in this every day how they keep the work good: Kevin Wong, Head of Design at Webflow; Karl Koch, design engineer at DuckDuckGo; and Jessa Parette, Head of Design at Byte by Yum!, the platform behind KFC, Taco Bell and Pizza Hut. Their answers point the same way. The bottleneck didn't disappear. It moved from making things to deciding what good looks like.

Start by writing down what "good" means

Kevin's team at Webflow didn't start with tools. They started with a definition.

The practical move was making Webflow's design system machine-readable, so anything built with AI draws from the same components, principles and patterns. For straightforward projects, that gets people 80 to 90 percent of the way there. Then a designer reviews the rest.

That changes what a design system is. It used to be documentation people were supposed to read. Now it's infrastructure the tools actually use. If your system only lives in a Figma library and a wiki, every AI-assisted build is starting from scratch, and you'll get a different button on every screen.

Jessa sees the same thing from the product side. Byte by Yum! is moving from responsive experiences to anticipatory ones, and she's blunt about what that requires:

The last 10 percent is the design work

A shared system gets everyone to good-enough faster. It doesn't get anyone to great. Karl explains why:

That's the real job description for design now. The system handles the average. Designers handle the distance between average and right.

At Webflow, that shows up as timing. In the best cases, Kevin says, PMs and engineers bring designers in early with whatever they sketched in Cursor or Claude. Instead of a spec, there's a working thing to react to, so design shapes it while it's still soft instead of fixing it after it ships.

Define the floor, not just the ceiling

If more people are shipping, someone has to say what can't ship. Jessa thinks that someone is design:

A minimum viable experience is a short list of things every release has to meet, whoever built it: accessibility basics, clear error states, consistent language, the brand. It turns design review from taste-based debate into a checklist anyone can run.

Karl's work on DuckDuckGo's Search Assist shows what this looks like for AI features specifically. Every answer gets a few extra milliseconds of vetting before it's shown, and the team keeps hand-scored datasets to check against whenever the model changes. The design job is the escape hatch: a set of error states for when the answer isn't good enough to show. Nobody gets to skip the error states because the happy path looked great in the demo.

More output means more noise

The next problem arrives quietly. When building gets easy, volume goes up, and keeping track of it becomes its own job.

Kevin built an internal place to host prototypes so people can see what exists, track it and leave comments, because links scattered across Slack disappear the moment you scroll. He's candid that it's still being figured out: it takes new habits, not just a new tool. But the principle is clear. If the team can't see what's being made, it can't hold the quality bar on it.

Judgment is the skill that's left

All three leaders end in the same place. AI didn't remove the need for designers. It removed the part of the job that used to hide the important part.

Jessa puts it most sharply. The designers who thrive won't be the fastest in Figma:

Karl adds the warning. Building something with AI and learning nothing from it is just a faster handoff. Designers don't all need to code, but they need enough fundamentals to spot a mess of nested divs, the same way engineers who design need to understand hierarchy, layout and typography. You can't judge output you don't understand.

And Kevin brings it back to people. When more and more can be created easily, the real question is what's worth creating at all. His team built a library of AI research skills so PMs and designers can run their own evaluative research, but the point isn't the tooling. It's building enough empathy for users to know what they're actually worried about.

The bottleneck moved

For years, design teams fought for more capacity to make things. Now making things is nearly free, and the scarce resource is the judgment to know which things are right.

That's good news for design, but only for teams that treat quality as a system: written down, built into the tools, and owned by someone. Everyone can build now. Someone still has to decide what's good.