There’s a pattern forming in product teams across the world. Someone floats an idea in standup, has a working prototype by lunch, and puts it in front of five customers before the day ends. Nobody waited on a sprint or filed a ticket for engineering time, and the idea went from a sentence to a testable thing in less time than it used to take to get a meeting on the calendar.

That is, genuinely, very exciting and the productivity win is a compelling headline. The part that gets skipped is what happens when the prototype comes back and the answer is no. That’s turning out to be a people and ego problem that’s harder to contain.

What Got Cheap

What changed is the cost (both money and time) of finding out.

As recently as 1-2 years ago, building a prototype meant prioritizing the development lo-fi wireframe in Figma, getting research funding for tools like UserTesting, and iterating. This usually took a sprint or two and enough folks to context switch to get it done.

Today, describing what you want in plain language gets you a clickable version in a few hours by using the same AI tools already living in many engineering workflows. The technical bar for testing a hypothesis dropped from convincing someone to prioritize it to opening a laptop

This is a real shift for innovation teams. The cost of being wrong about an idea used to be measured in weeks; however, now the same wrong guess costs an afternoon and is easier to drop because the prototype exists before anyone’s had time to get attached to it. Cheaper mistakes should be an unambiguous win and they mostly are, but what they still leave untouched is the part that happens after the answer comes back.

Moving Fast Until We’re Not

The iteration speed gain is real, but even the best evidence on it keeps getting revised. A randomized controlled trial from METR, a research nonprofit with no product to sell either direction, published in July 2025 found that experienced open-source developers using AI tools on codebases they knew well took 19 percent longer to finish real work. METR itself now calls that result dated. A follow-up published in February 2026, run at a third of the original pay rate and complicated by enough AI-committed developers opting out that the remaining sample skewed toward people expecting the least from AI, showed some evidence of a speedup instead, on data METR itself calls an unreliable signal. METR’s own read is that the number is probably still an undercount, since the developers most convinced AI already helps them were the likeliest to skip the study.

None of this settles whether AI writes, subjectively, “good code” or creates “good experiences.”

METR’s own comparison table draws a more interesting line: their trial measured work meant to pass review, with style, testing, and documentation requirements attached, while the enthusiasm they cite from elsewhere is mostly about work a developer finds useful “potentially as a throwaway prototype or single-use research code.” Those are different jobs. A disposable prototype meant to answer one question and then get deleted is closer to a sketch than a build, and it’s still the fastest way to find out if five customers care about an idea, regardless of which way the productivity numbers move for production work. The moment a team decides to keep that prototype and build on top of it, the job changes, and the code needs the same review a careful expert would want on any codebase they didn’t write themselves.

What Cheap Testing Doesn’t Buy You

Cheap testing buys you a fast, cheap answer, but it doesn’t automatically buy you the will to act on an answer you don’t like, and it doesn’t work the same way for every kind of idea.

Take an idea that improves something customers already do, a faster checkout flow or a clearer error message. That tests cleanly against a rough prototype and real usage data within days. Now take an idea that’s genuinely new, a workflow nobody’s asked for yet because they don’t know it’s possible. That can’t be falsified that fast, because five customers shrugging at a rough prototype doesn’t mean the idea is wrong. It might mean the prototype is too rough to show what’s different about it, or that the market for it doesn’t exist yet in a form anyone can react to immediately. Treating both kinds of idea with the same one-week test is how good long-shot ideas die of a false negative, and how mediocre incremental ideas survive because they’re easy to make look fine.

The harder failure is what happens when the right test comes back negative and the team keeps going anyway, because someone already told their boss about it, or because deleting three days of work feels worse than shipping something nobody asked for. That’s the same status math a product discovery piece I wrote covers from the other side, where the person who won’t kill a bad idea and the manager who won’t endorse a good one are protecting the same thing. Cheap testing didn’t remove that instinct; if anything, it removed the excuse that used to cover for it. A wasted sprint used to look like bad luck, but a wasted afternoon followed by a decision to keep building past a clear no looks like something else.

I’m not arguing against AI-assisted prototyping. I can’t as I use it every day for countless use cases and testing an idea in an afternoon instead of a sprint is a genuine gift. Teams that don’t use it are paying a real cost for no reason. However, the gift only pays off if the team getting faster tests is also getting more honest about what those tests say. Building got cheap, but believing your own results, especially the ones that don’t flatter the idea you already liked, is still expensive, and AI never touched that part of the bill.

What’s the last cheap test your team ran that actually changed a roadmap, instead of getting explained away?