AI Is Making Software Cheaper. The Harder Problem Is Knowing What to Build

As AI agents make software increasingly abundant, the competitive advantage may shift from producing more features to deciding which ones deserve to exist.

When the effort required to turn an idea into working software falls, companies can afford to pursue more ideas. But that also makes it easier to fill products with features that customers never needed. The central product question therefore changes. It is no longer only how quickly a company can build. It is whether the company can identify valuable problems before committing even cheaper engineering capacity to them.

Software development is entering an unusual phase. For decades, companies had to ration engineering time because software took time to design, write, test and maintain. That constraint is now being challenged by AI agents that can work across repositories, generate implementations, write tests and increasingly handle multi-step development tasks. The result is not simply faster engineering. It changes the economics of product development.

The early promise of AI-assisted development was largely framed around productivity. Give developers better tools and they can accomplish more with the same resources. That remains important. JetBrains’ 2026 Developer Ecosystem Survey found that AI coding agents had already become a regular part of professional developers’ workflows, with adoption particularly high in markets including China, Japan and South Korea. 

But greater production capacity introduces a different problem. A product team that previously had to reject an idea because it would consume three months of engineering effort may now be able to prototype it in days. That makes experimentation cheaper, but it also removes one natural constraint on product teams.

Engineering scarcity used to force prioritization. AI can weaken that constraint. The danger is not that companies will run out of things to build. It is that they will build too many things without enough evidence that those things should exist.

The Product Backlog Could Become the New Bottleneck

This helps explain why the next generation of AI development tools is increasingly concerned with specifications, context and prioritization rather than code generation alone. Amazon’s Kiro, for example, has pushed a specification-driven approach to AI development. The premise is that giving an agent a clearer definition of the desired outcome before implementation can reduce the repeated loops created by ambiguous instructions. Recent discussions around agentic development are increasingly focused on this problem of turning intent into reliable execution. 

The significance extends beyond development methodology. A specification is effectively a decision about what the software should do and why. As agents become better at implementation, the quality of that decision becomes more consequential. This creates an interesting inversion. Developers may spend less time physically producing code while more organizational value moves toward defining requirements, establishing constraints, understanding users and determining whether an idea merits implementation at all.

McKinsey’s 2026 research points in this direction, finding that companies seeing stronger results from agentic development are redesigning roles and workflows rather than simply adding AI tools to existing processes. Engineers are moving further upstream into requirements and solution design while also taking on more downstream responsibility. 

The obvious response is to become more customer-driven. But customer information itself has become abundant. A modern startup can collect requests from sales calls, support conversations, product reviews, community discussions and usage data. AI can now summarize and categorize that information at a scale that would previously have required substantial manual work.

Yet a larger volume of feedback does not automatically produce better product decisions. Customers describe symptoms. They do not necessarily describe the underlying problem. The most frequently requested feature is not automatically the most valuable feature. And the customer who speaks most often may not represent the broader market.

The real challenge is therefore interpretation. A product organization needs to determine which signals indicate a meaningful problem, which problems have commercial significance and which can actually be solved in a way that changes customer behavior. That is a substantially harder task than summarizing feedback.

The Customer Conversation May Move Closer to Engineering

This is where the thinking from early-stage founders becomes interesting, even if it is not yet established industry evidence.

Jonathan Tweneboah, founder and CEO of Light Reach, sees the emerging constraint moving toward the quality of customer conversations. While conversing with AsiaTechDaily, he said, “Yes, we believe the bottleneck will shift into which conversations are worth having. We’re currently working on a metric for the expected value of engineering work relative to the market. From our perspective engineering will move to the people who are in direct contact with customers.”

His observation reflects one possible consequence of cheaper software production: the people closest to customers could become more directly involved in shaping engineering work. The traditional sequence often involved several translations: customer problem → sales or support → product team → requirements → engineering → software

AI could reduce some of those translation costs. But that does not mean every customer-facing employee should suddenly become a software engineer. The more important change may be that customer evidence, product reasoning and engineering execution become more tightly connected.

The Next Competitive Advantage May Be Product Restraint

This is where the economics become particularly interesting for startups. If AI makes experimentation cheaper, companies should theoretically be able to test more hypotheses. But testing more ideas only creates value if teams can distinguish between useful evidence and noise. The objective therefore should not be maximum software output.

It should be maximum learning per unit of engineering effort. That changes what a productive product organization looks like. A team may deliberately kill an idea after a prototype, remove a feature that generates little value, or refuse a frequently requested capability because the underlying problem is too narrow. Those decisions can look like reduced output on a traditional engineering dashboard. They may represent better product economics.

DORA‘s latest research reinforces why execution cannot be measured simply through code-generation speed. Its analysis found that AI can accelerate initial development while shifting more effort toward auditing and verification, creating tensions between faster production and software stability. The same principle applies one level above engineering: building something faster does not make the decision to build it correct.

The most important change AI brings to product development may therefore happen before a coding agent writes its first line. When software was expensive to produce, engineering capacity naturally limited the number of ideas a company could pursue. As agents reduce that constraint, companies can explore more possibilities.

That makes another capability more valuable: knowing which possibilities deserve attention. For founders, product leaders and investors, the question is consequently shifting from how much software a team can produce to how effectively it can connect customer evidence, product decisions, engineering execution and measurable outcomes. AI may make software abundant. The harder competitive advantage could be knowing which software should exist at all.

Quick Takeaways

• AI is making software production faster and more accessible, reducing one of the traditional constraints on startups: engineering capacity.
• The bigger issue may become software abundance. When teams can build more ideas quickly, they also risk building features customers do not need.
• Engineering scarcity has historically forced prioritization. AI can weaken that natural constraint, making product judgment more important.
• The key question is shifting from “Can we build this?” to “Should we build this?”
• More customer data does not automatically mean better decisions. The challenge is separating meaningful signals from noise.
• AI could bring customer conversations, product decisions and engineering execution closer together, reducing the number of handoffs between teams.
• Jonathan Tweneboah’s quote provides a founder perspective on this emerging shift, particularly around identifying which customer conversations are worth having.
• For startups, the goal should not necessarily be maximum software output, but maximum learning from each unit of engineering effort.
• The emerging competitive advantage could be product restraint: knowing what not to build, what to test, and what to abandon early.
• Bottom line: As software becomes more abundant, the scarce capability may increasingly be knowing which software deserves to exist.