Five Prototypes, and Still Not Learning

You can now build five prototypes in the time it used to take to spec one feature.

That sounds like faster learning. It isn't, necessarily.

What learning actually requires

Learning requires contact with reality. Most of these prototypes never leave the building.

They go to stakeholders for a thumbs up. Maybe to a friendly internal user if the team is disciplined. Then they end up in a repo no one touches again, replaced by the next quick build. The cycle runs faster, but the feedback loop that matters — actual users, with actual needs, in actual situations — stays the same length.

The bottleneck was never "how fast can we make a thing that works." It was always "how quickly can we get actual usage data from actual users."

That part hasn't changed.

The new version of the old problem

If anything, it's harder now. Because the prototype looks and behaves so convincingly that everyone mistakes internal consensus for validation.

It's real code. It runs. The UI looks finished. That feels like progress.

So the team shows it to stakeholders who say it looks great. They demo it in Slack. They share it in a review meeting and get positive reactions. And they conclude they're on the right track — without ever putting it in front of someone who wasn't already invested in seeing it work.

The tool made the wrong part easier. You can build faster than you can think. You can ship something that looks like a validated product before you've validated anything.

What actually changes the feedback loop

The PMs and engineers who figure this out will be the ones who stay uncomfortable. Who keep shipping uglier things to real users faster. Who resist the pull toward the polished demo and the internal stakeholder review.

The question worth asking before any prototype is: does this get in front of someone who has no reason to be kind about it? Someone who will ignore it, use it wrong, or tell you the problem it solves isn't actually the problem they have?

If the answer is no, the prototype is for internal consumption. It might still be useful — as a way to test technical assumptions, to align a team, to communicate a direction. But it is not learning, in the sense that matters for product development.

Speed doesn't substitute for validation

The rate at which you can produce working software has increased significantly. The rate at which you can establish whether that software is solving the right problem for the right people has not.

Faster prototyping can help if it gets you to a testable thing sooner. But testable with whom? Under what conditions? With what kind of feedback?

The teams that use AI to compress the build cycle and simultaneously compress the gap to real feedback will move faster in a meaningful sense. The ones that use it to generate more polished artefacts for internal review will feel like they're moving faster while staying in the same place.

The distinguishing question is not how quickly you can ship something. It's how quickly you can find out if you're wrong.