Two writers looked at the same tool and reached opposite conclusions, and both were right.
One ran a test. He pointed Claude Fable 5 at a hard brief—a mobile app for travelers whose flights get delayed, canceled, or broken by a missed connection—and asked it to build the whole concept: target audience, user journey, information architecture, edge cases. Then he asked whether it could replace a product designer. The answer was two words: "Short answer: Yes."
The other writer, working with Claude Code, described a slower horror. The model generates polished screens fast, which makes it easy to believe AI can run the whole process—during which it builds "a lot of locally reasonable decisions over time that, when implemented in your product, will destroy it." The worst part, the writer adds: "you only notice product design degradation after a while, by which point it's too late."
This week we get the sharpest version of the same fight: a concrete "yes, it replaces us" verdict, and the reason that verdict measures exactly the wrong thing.
Start by conceding the point, because pretending otherwise is how designers lose the argument twice. The Fable 5 test is real, and the result is honest. Point a competent model at a clear brief and it returns a plausible concept in the time a person would spend on a single screen. The production layer—the wireframe, the boilerplate, the competent first draft—is collapsing toward free. That's not opinion; it's the shape of the tools now.
But look at what the test actually measured. It measured an artifact: a concept produced in an afternoon, coherent on the canvas, complete enough to demo. It did not measure a product—something that ships, holds up under real data, and survives the tenth edge case nobody prompted for.
A Figma frame has never shipped revenue. It promises a product; it is not one. For a decade the industry mistook the two, and the Fable 5 verdict inherits that same confusion at machine speed. "Yes" is the right answer to "can it win the artifact." It's the wrong answer to "can it own the product."
The trap is that the same fluency produces both outcomes. The tool that concepts a flight-disruption app in an afternoon is the tool that quietly rots a real one, and it does so through decisions that each look correct in isolation.
That's the crucial word in the Claude Code warning: locally reasonable. Add a filter to a table. Build a confirmation dialog. Create a settings page. Every task is defensible on its own. But product design is not a collection of isolated tasks—every decision lives inside a journey, a set of prior patterns, a history of why earlier calls were made. A model optimizing each local task toward the shortest reasonable path will skip the part where those calls add up to something a person trusts. And you don't see the damage until it's cumulative, which is the point at which it's too late.
A model optimizing each local task toward the shortest reasonable path will skip the part where those calls add up to something a person trusts.
This is why the replacement question is really a question about where judgment lives, and today's models are structurally worst at exactly that layer.
Consider a scene laid out in one recent essay to make it concrete. A problem-resolution flow in a complex product: a user files a complaint. A model trained to optimize reads the ticket and proposes the statistically most efficient resolution—close it with a one-click refund. Logical. Expected. The highest-probability move.
A person with judgment does the opposite. They read the frustration between the lines and add deliberate friction—a slower flow, designed so the user feels the product is taking responsibility for the failure. Because here the user doesn't just want their money back fast. They need to know someone acknowledged the error.
That is the whole argument in one interaction. The efficient answer and the right answer are not the same answer, and knowing the difference—choosing friction over speed on purpose—is the work AI is built to route around. Probabilistic systems are extraordinary at finding the expected. The most valuable design decisions run the other way: not to build something that could be built, to sense that something's wrong before you can explain why.
So the crisis isn't the how. It's the what. What to build, for whom, with what judgment—and which single option, out of the thousand a model can generate before lunch, deserves to exist at all.
That last skill is the one that actually got scarce. Breadth used to be expensive; you explored two directions and committed early, often to the wrong one. Now breadth is free—ten directions in the time it took to mock up one. The skill is no longer generating options. It's killing the weak nine fast, before anyone gets attached, and the only reliable way to kill an option is evidence from someone not on the team.
Which is why the survivor isn't the designer who makes screens faster. It's the one who can, as one design leader puts it, look at a brief before a line of code exists and say "this will fail someone, and here is how"—the judgment that got quietly cut when design scaled to feed agile delivery and got rewarded for velocity instead of prevention.
None of this is a comforting fiction that AI leaves design untouched. It doesn't. It replaces the parts of the role that were, as Neeman puts it, production wearing craft's clothes: the polish, the asset assembly, the competent first draft. That work is genuinely gone. Pretending otherwise is how a portfolio ends up as thirty-two flawless screens without a single visible decision in it.
Here's the falsifiable version, and it's already running in production. Decagon, the AI customer-service company reportedly on the CNBC Disruptor 50 list, has pushed AI deep into its build loop. Coding agents read directly from Figma through MCP, map to design-system components, and produce high-fidelity starting points without the old designer-to-mock-to-dev relay. Production, absorbed.
But watch where the humans stayed. Roughly 70 percent of Decagon's roadmap reportedly comes straight from customers, and instead of gathering requirements and presenting one end product, the team now builds ten different prototypes and shows them to ten different customers. A PM feeds an old chart into Figma Make, describes the changes, and checks with engineering and the customer-facing team whether the change is actually useful—before anyone commits real resources.
That is the relocation, made concrete. The machine absorbed which screens get generated. The humans kept which prototype gets shown to which customer, and whether the change is worth building at all. The job didn't vanish. It moved to the decision AI is structurally worst at.
So take the UX writer's "Yes" seriously, then finish the sentence. Yes—it can replace the production. No—it can't own the outcome, because owning the outcome means adding friction where the model would refund, killing nine options where the model would ship the tenth by default, and naming the one that deserves to exist.
Fable 5 wins the artifact. It loses the product. The designer who understands the difference isn't the one racing the machine on screens. They're the one holding the what while the machine takes the how—and making the call the statistics will never make on their own.