For most of software delivery's history, prioritization was partly enforced by scarcity. A team could only build so much in a sprint, so a backlog naturally got triaged by necessity: the top items got built, the rest waited, and a mediocre prioritization process was masked by the fact that capacity was the real constraint anyway.
AI-assisted development loosens that constraint. A team that can implement more of its backlog, faster, runs into a different problem: the capacity ceiling that used to do a lot of the prioritization work for free is higher now, which means a genuinely bad prioritization call gets built instead of quietly waiting in a queue.
Cheap to build isn't the same as worth building
The risk isn't running out of things to build. Most backlogs have more ideas in them than a team could execute in a year even with meaningfully more capacity. The risk is that a lower cost per feature makes it easier to justify building things that were never actually high-value, just previously too expensive to have that argument settled by scarcity alone.
A feature that would have obviously lost a prioritization debate against higher-value work can now sneak through simply because it's cheap enough that nobody bothers to have the debate. That's not a capacity problem. It's a discipline problem that capacity constraints used to paper over.
What actually needs to tighten
The teams handling this well are treating a lower build cost as a reason to invest more in prioritization rigor, not less: clearer value hypotheses before work starts, a real mechanism for saying no to plausible-but-low-value ideas, and post-launch review of whether a shipped feature actually did what its business case claimed. None of that is about slowing delivery down. It's about making sure the decision about what to build keeps pace with how fast it can now be built.