There is a process every product team knows by heart. Spec, design, build, test, ship. Repeated often enough that it stops feeling like a choice and starts feeling like the shape of how things work.
It was never the shape of how things work. It was the shape of how things work when building software is expensive. When being wrong costs six months. When rework is the thing you organize an entire function to prevent. That world ended quietly. Most teams haven't noticed yet.
01What the Assembly Line Was Actually for
The traditional product development process (PM writes requirements → design creates mocks → engineering builds → QA tests → ship) was designed to craft something genuinely good. You define scope progressively, stress-testing your hypotheses at each stage before committing more resource to them. The spec forces you to articulate what you believe and why. Design reveals whether the concept holds up visually and functionally. Engineering makes it real. Each stage is a deliberate act of refinement, building toward a product you're confident will move the needle for users and for the business.
The problem wasn't the intent. It was the cost structure underneath it. The entire apparatus assumed that each stage was expensive, expensive enough that you had to get the previous one right before moving forward. Rework wasn't just inconvenient. It was organizationally catastrophic. So you front-loaded everything: alignment, definition, validation. You exhausted all other options before committing engineering time.
I've spent a decade as a product manager. That discipline made sense. It still makes sense as a philosophy. What's changed is that the cost that justified the process has largely disappeared. A working prototype takes hours, not months. You can now build the thing you were trying to specify, and learn more from it in an afternoon than a week of alignment meetings would tell you.
02The MVP Was the Best Idea in Product Development History
The Minimum Viable Product wasn't about building something small. It was about separating two questions that are easy to conflate: does this meet a real user need, and is this well-built? Its genius was epistemological. Your intuition about what users need is a hypothesis, not a fact, and hypotheses require evidence before you bet the roadmap on them. Build something minimal enough to test the core assumption. Put it in front of real users. Measure whether it solves their problem. Only then invest in scaling what works.
What's changed isn't the logic. It's the cost structure. The "minimum" in MVP was never an aesthetic choice. It was a financial one: a constraint response to expensive engineering time. When building costs hours instead of months, that constraint dissolves. And with it, most of the scaffolding around MVP scope, sprint planning, and v1 prioritization starts to look like process for its own sake.
03The New Risk: Mistaking Taste for Validation
Here is the uncomfortable thing most of the AI-development discourse glosses over. The MVP framework existed partly to protect against a specific failure mode: builders falling in love with their own ideas. AI dramatically lowers the cost of building something you personally love. This sounds like pure upside. But it creates a trap.
When you can go from idea to working prototype in hours, and the prototype reflects your own sense of what's elegant and well-designed, it's easy to feel like you've validated something when you've actually just built a fast expression of your existing assumptions. The speed creates a feeling of progress. The quality creates a feeling of confidence. Neither is evidence of product-market fit.
If anything, the bar for genuine user validation rises in this world. Precisely because the cost of building has collapsed, the discipline of putting things in front of real users before committing to scale becomes more important, not less.
The best teams will treat AI prototyping as a way to get to user validation faster, not as a substitute for it. You're not removing the validate step. You're compressing the distance between idea and the moment when you have something real enough to learn from.
04Prototype and Production Are Different Artifacts
AI-generated code can be slop. It will hallucinate edge cases, ignore security implications, produce brittle logic that works until it doesn't, and miss the kind of architectural judgment that comes from building systems at scale. A real engineer needs to review it before it goes anywhere near production. This isn't a limitation that will be engineered away. It's a reflection of what the code was made for.
Production code needs to handle failure modes, edge cases, security, performance at scale, observability, accessibility. The prototype you built in three hours doesn't need any of that. It needs to be true enough to generate real signal. The 70% that fails production standards isn't waste. It's the scaffolding of the thought. Its purpose was to compress the time between "I have an idea" and "I have evidence worth building on."
The dangerous failure mode is treating AI prototyping as accelerated production: pipelining generated code directly into the codebase without deliberate rebuilding. Teams that do this accumulate technical debt faster than any previous technology has allowed. Prototype and production are not the same artifact. The new process requires being explicit about which one you're making.
05The Real Bottleneck Was Never Building
Here is the uncomfortable implication most of this discourse avoids: if prototyping is nearly free, the primary bottleneck in most product organizations isn't the cost of building things.
It's the cost of deciding.
Most organizations are not slow at shipping because engineering is slow. They're slow because the committee of stakeholders who must align before anything ships is large, and the process of building alignment consumes enormous energy. AI doesn't solve this. When a prototype exists in two hours, the request to "just try a few more directions" has almost no cost, which means it will be made constantly. Cheap prototyping democratizes exploration. It can also paralyze commitment. The teams who win will treat decision-making as a first-class engineering problem: who decides, with what information, by when.
The new constraint isn't building. It's deciding at the pace the building now enables.
The Build → Validate → Scale loop doesn't get replaced. It gets compressed into something you can run in days rather than quarters, repeated as many times as the problem demands. The teams who adapt fastest won't be the ones who moved their existing process to a higher gear. They'll be the ones who understood that process was always instrumental (a means to learning cheaply and deciding well), and redesigned it around what's actually expensive now.
What's actually expensive now is building the wrong thing at scale because you mistook how quickly you built it for evidence that it was worth building.
Everything else is a prototype waiting to be tested.