There's a specific moment a lot of product teams have hit recently: someone asks "could we build this?" and the honest answer, for almost anything, is now yes, quickly. That used to be a genuinely hard question. It rarely is anymore. The question that replaced it is harder to answer and much easier to avoid: should we?
Why isn't faster building solving more problems?
For most of software's history, engineering capacity was the natural filter. Teams could only build so much, so only the ideas with real conviction behind them tended to survive long enough to ship. That constraint quietly did a lot of prioritization work, even when no one called it that.
AI coding tools removed the constraint. A prototype that used to take a sprint can now exist before the meeting where it was proposed has ended. That's a genuine unlock for exploration and it's also why backlogs across a lot of teams have started to look less like a list of commitments and more like a list of things that were merely possible to try.
Does more output actually mean more progress?
Not by default. A team can produce five versions of an onboarding flow in an afternoon without much effort. The part that hasn't gotten any easier is knowing which of the five actually addresses the sharpest problem a real user has, and having evidence for that before committing engineering time to it.
Coding was always one stage in a longer chain, requirements, design review, testing, security, release coordination. None of those stages move faster just because a first draft appeared instantly. A polished-looking AI-generated prototype can, somewhat counterintuitively, create more downstream work: more to review, more edge cases, more code that now needs a maintainer, without necessarily bringing the product any closer to what a customer actually needed.
This shift shows up in recent research. A June 2026 study from airfocus by Lucid found that 48% of product teams still struggle to separate signal from noise, despite near-universal AI adoption across their workflows. The same research cites Bain's 2025 estimate that writing and testing code now makes up only 25–35% of the full idea-to-launch journey, meaning the majority of the work, even before AI, was always upstream of the code itself. AI just made that majority impossible to ignore.
What should a team actually ask before building something?
A short, honest decision brief tends to hold up better than a long list of AI-generated requirements, mainly because it forces questions that generation speed makes easy to skip:
Which specific problem does this solve, and for whom?
How often does that problem actually occur?
What's the smallest version that would tell us whether we're right?
What does this delay or compete with for the team's attention?
What will tell us, after launch, whether it actually worked?
What ongoing cost, support, security, maintenance, does saying yes create?
None of these get easier to answer because the prototype got easier to build. They arguably matter more, since there are now more ideas competing for the same limited capacity to maintain whatever ships.
What does a healthier way to track ideas look like?
One practical shift: replace a flat feature backlog with something closer to an evidence backlog. Instead of just tracking what's been requested, track the problem it solves, how confident the team is, what it would cost to build and maintain, and who's accountable for the call. Sorting ideas into rough stages, explore, validate, commit keeps a prototype from landing on the roadmap simply because it happened to look finished. Looking finished and being worth shipping aren't the same thing, and AI-generated drafts are unusually good at looking finished.
This is also roughly where AI is most useful in this process, just not in the role it's often assumed to play. It's genuinely good at summarizing a backlog of support tickets, clustering recurring complaints, or flagging where two customer segments are asking for contradictory things. It's not well suited to deciding which of those problems the business should prioritize right now, that's still a judgment call, and treating AI output as if it settles that question just pushes the noise problem one step downstream.
It's part of why the current generation of AI development platforms, 8080.ai, Replit, Lovable, and others building in this space have started folding the earlier planning stage into the workflow itself rather than treating it as an optional step before generation begins. Some ask for a requirements document before any code exists. Some are structured so the first output is disposable enough that skipping straight to "build" doesn't feel like the default. The underlying premise is consistent across all of them: generation speed without a decision step in front of it just produces more things to evaluate later, not more things worth shipping.
What changes for the people actually doing the work?
Product managers spend more time validating that a problem is real and less time writing tickets nobody argued about. Designers can explore more directions faster, but the job shifts toward judging whether an option changes user behavior, not just whether it reviews well. Developers get pulled into feasibility and architecture conversations earlier, since those constraints matter before code exists rather than after. Nobody's role disappears, the point where their judgment matters most just moves earlier, before AI has already produced a large volume of work that now needs sorting.
What's actually worth measuring?
Lines of code generated, number of prototypes built, tickets closed per sprint, none of these say much about whether the product improved. What's more useful: time from spotting a real problem to making a decision the team can defend, the share of the roadmap actually backed by evidence, and how much gets reworked after release. Those numbers say more about whether a team is getting better at this specific bottleneck than any raw output metric ever will.
AI has made software cheap to produce. It hasn't made every idea worth producing. The teams pulling ahead right now aren't the ones generating the most, they're the ones getting faster at turning evidence into a decision, and a decision into something worth actually maintaining.
Top comments (0)