3 min read
When everyone can build, who decides what ships?
AI has collapsed the product and UX roles into a single "builder" position at many companies. The real problem isn't the role change—it's that the judgment layer, the one that asks whether something should ship at all, quietly disappears with it.
By intermac
The problem isn't that everyone can build. The problem is that nobody is deciding what should ship.
Jeff Gothelf writes about this clearly: companies are collapsing product and UX roles into a single "builder" position and handing those people AI tools that take an idea from conception to production. The trouble is that the old build-and-release process—code review, QA, staged rollouts—wasn't just bureaucracy. It was a quality filter. Its friction was the point. It slowed shipping enough that bad ideas died before reaching customers.
AI has removed that friction. The path to production is now fast, cheap, and wide open.
The discovery problem is worse than it looks
One detail in Gothelf's piece stands out: at least one of the companies he describes has built an AI agent that "does product discovery" by searching competitors, internal analytics, and synthetic user profiles—then produces clickable wireframes. The catch? The agent always concludes the idea is viable.
This is the failure mode in miniature. You haven't replaced product judgment with a tool. You've replaced it with a confirmation engine. A system that never says no isn't discovery; it's rationalization dressed up as process.
That's the real cost of collapsing roles. It isn't that designers can't write code or that PMs can't sketch a flow. It's that the judgment layer—the one that asks should we build this at all—gets quietly removed while everyone celebrates the speed of the new setup.
Shipping rights and build rights are different things
The most useful idea Gothelf offers is keeping the right to build separate from the right to ship. Build whatever you want locally. Show it to users. But each step toward wider release requires evidence, not enthusiasm.
This distinction matters especially for small teams. When you have five people, a feature nobody uses doesn't just clutter the UI—it sits in your codebase, your documentation, your support queue, and your next migration. Pendo found in 2019 that 80% of features in the average software product are rarely or never used. That was before AI made shipping trivially easy. The number isn't getting better.
Gothelf also makes a pointed observation about feature retirement: when pressed, neither of the companies he spoke with had ever killed a feature. One organization kept a feature alive that costs more to support annually than the revenue it generates, because no one wants to be the person who proposes killing a million-dollar line item. That's not a product decision anymore; it's organizational conflict avoidance wearing a business case.
What we'd add
The strategies Gothelf outlines—hypothesis-first shipping, quarterly retirement reviews, success criteria tied to behavior rather than features shipped—are sound. We'd add one more lens: treat every feature as a liability until proven otherwise. Not as pessimism, but as accounting. Every thing you ship carries a maintenance cost, a support cost, and a cognitive cost for your users. Those costs don't disappear when the feature stops being useful.
The builder model can work. But it only works if the people with build access also have the discipline—and the organizational backing—to say no to their own ideas. That's harder than it sounds when the tool in front of you makes "yes" the path of least resistance.
Sources
- How to manage the inevitable mess of running a company where everyone is a builder (original)
- Found via the TLDR newsletter