Anyone Can Build It Now. That Was Never the Point.

An LLM can now generate the work each role used to make by hand — the PRD, the mockup, the code — which makes it fair to ask whether the role is still needed. But producing the artifact and exercising the judgment behind it used to be one act. Pull them apart, and you find out which half was the job.

The argument showed up in my team a few weeks ago, and I didn’t have a good answer for it. It went like this: design matters less than it used to. A PM can vibe-code a working prototype in an afternoon, so the work that used to need a designer doesn’t. And our products lean less on screens anyway — APIs, MCPs, agents, fewer interfaces — so there’s less for a design team to do. I watched someone make that case about a function I value, and the uncomfortable part wasn’t that it was hostile. It was that I couldn’t immediately say why it was wrong.

It bothered me for another reason, too. If the argument worked against UX, it worked against me.

Strip it down and it isn’t about design at all. An LLM can produce what almost any function produces — the PRD, the mockup, the test plan, even the code. So once the model can make your output, the same question lands on every function: if a model produces that now, what’s the team still here to do? It’s a fair question. I just think it’s aimed at the wrong thing.

Here’s what I keep coming back to: the artifact was the job codified. Making it by hand — slowly, with effort — was inseparable from the work that mattered. You couldn’t write the code without reasoning about whether it would hold up under load, or draw the screen without reasoning about whether a person could use it. The thing you could see carried a stack of qualities nobody measured directly, because producing it and producing them were the same act. That’s what’s changed: the model can produce the artifact without any of that work happening at all.

Take the friction away and the output gets cheap. The qualities it used to carry don’t come with it.

Look at what each function is on the hook for. Engineering’s output is code; the job is whether the thing is secure, whether it scales, whether anyone else can maintain it. UX’s output is screens; the job is whether a person trusts the system, catches it when it’s wrong, and can find their way without a tour. None of that shows up in a demo, and none of it comes free when a model generates the surface. The output looks finished. The qualities just go missing quietly.

You can watch it happen at a handoff. You vibe-code a working app in an afternoon and pass it to engineering to ship. They say no — it’s not ready. On the surface it feels like gatekeeping; the thing runs, what’s the problem? The problem is everything the demo hid: it isn’t secure, it won’t scale, no one can maintain it. The friction at that handoff isn’t politics. It’s the missing qualities showing up at the seam between two teams — usually the first place anyone notices they were never there.

Which is where I have to stop pointing at other people’s functions. A model writes a serviceable PRD. A roadmap. A backlog, groomed and pointed. So the question comes for product just as hard: if the doc writes itself, what’s the PM for? The honest answer is the bet — the judgment about what’s worth building and what isn’t. That’s real work, and it’s mine. But I can’t put a number on it. I can’t fail it on a dashboard the way an engineer fails a load test. Product has the same exposure I just described for everyone else, and less to show in its defense.

When the question lands, the reflex is one of two moves, and it’s the same mistake both times. Defend the output — insist that only you can write the real PRD, the real spec. Or go produce someone else’s output — become the PM who just vibe-codes now. One clings to its own artifact, the other reaches for the neighbor’s. Both still treat the artifact as the point.

There’s nothing wrong with a PM writing code. Vibe-code the prototype to make a bet concrete, to pressure-test a direction, to show people what you mean instead of describing it — that’s using the tool to do your own job better. The mistake isn’t crossing the line. It’s crossing it and thinking you’ve done the other person’s job — handing engineering your afternoon’s work and expecting a deploy. You made the artifact and skipped every quality it was supposed to carry.

And when a function does that — chases the output, drops the quality — the loss is quiet. Nobody notices the judgment going missing the way they’d notice a missed deadline. The bets just get worse, slowly, and the misses get blamed on a dozen other things. Because no single failure points back to “we stopped doing the work,” the org concludes the function was never needed — which was the premise that started all this. The wrong response doesn’t just lose the job. It manufactures the proof that the job never mattered.

The better response is unglamorous. Name the quality you own. Make it measurable, or as close to measurable as it gets. Then own it at the seam, where the handoffs happen — because the seam is also where accountability lives. Who owns whether it scales. Who owns whether a person can use it. Who owns whether it was worth building at all. When everyone can produce everyone’s output and no one owns the quality underneath, accountability is the first thing to go.

The question going around — if the model makes your output, what are you for? — is fair. It’s just been pointed at the artifact, and the artifact was never the answer. The output was always the cheapest thing the work produced. It only looked like the job because, until now, making it was the hard part.