Part 1: More than just a pastry chef

In the not too distant future, we will see the last dedicated UX Designer role. Not because the people doing the work will disappear, but because the boundaries that once defined the role are dissolving. And with them, the need for that specific job title.

This isn't a UX specific problem. It's a shift felt across the entire software development lifecycle. From product to engineering, the silos that once organized our work are becoming harder to justify and harder to maintain. The UX designer, who has always lived between the product and engineering worlds, has a particularly clear view of what's coming.

But to be clear: UX design itself isn't going anywhere. As long as software is built for humans and humans remain stubbornly complex, the skills of understanding behavior, reducing friction, and designing for real use will be indispensable. What's changing is who owns those skills, and where they live. The role isn't shrinking. It's spilling over its edges. And the designers who recognize that early are the ones who will define what comes next.

---

Part 2: The open kitchen

Think of it like a busy restaurant kitchen running full brigade. Everyone at their station, working in harmony to prep, cook, and plate. The saucier doesn't touch the grill. The pastry chef is in a separate world entirely. Orders come in, the team moves as one, and the system works because everyone knows their lane.

Software development has worked the same way for a long time. PMs hand off to designers. Designers hand off to engineers. Everyone owns their station and guards it accordingly.

But the kitchen is changing. The designers of today aren't waiting at the pass for their work to be picked up and built. They're closing the loop themselves. They're in the code, in the repository, in the conversation that used to happen without them. The handoff is becoming a collaboration. The lane is becoming a shared road.

In the kitchen of the future, every chef is also a sous chef. They still have their specialty, their sharpest skill, the thing they do better than anyone else at the table. But they can also step across the pass, pick up a pan, and finish the plate. The station doesn't disappear. The wall around it does.

The question stops being who owns this work. It starts being who can just get it done.

---

Part 3: Let's cook

I got the chance to try this out firsthand. A one week sprint, a team I had never worked with before, and a single goal: ship a feature to production before time ran out. We could have just brute forced it. Fallen back on the usual roles, the usual handoffs, the usual rules. But without the org chart looking over our shoulder, it felt like an opportunity to try something different.

The first thing we did was establish a common work surface. One repo, full access, no friction. The less time we spent translating between tools and contexts, the more time we had to actually build. I started using code as a way to test and communicate interactions. Vibe-coding with links to the design library, keeping enough fidelity to be useful without getting precious about it. It wasn't the way I would normally work. It was better.

What surprised me most was what happened to the timeline. Design work didn't end on day two. QA didn't start on day five. When pivots came (and they always do) nobody had to wait for a handoff to catch up. The work moved with us. The stations were still there. We just stopped pretending the walls between them were load bearing.

One week taught me what I think the next few years will confirm. The designers who thrive won't be the ones who hold their ground. They'll be the ones who already left their station, walked across the kitchen, and started cooking with the rest of the team.

---