Where value survives when software becomes easier to build

It is becoming easier to show a customer something that looks like the software they asked for. The screens work, the buttons respond and a demonstration can cover an impressive amount of ground. Then someone asks how it handles a duplicate payment, a failed migration or an employee who left six months ago. The conversation becomes more familiar.

If AI continues to lower the effort required to produce software, the economics of software businesses will change. The interesting question is where customers will still pay for scarce capability. Working code will remain necessary. Its mere existence may become less persuasive as an explanation for a large recurring bill.

The premise needs care. Progress in coding assistance does not produce a uniform improvement in every development task. In its February 2026 research update, METR said its later experiment could not reliably measure the current productivity effect because of selection and measurement problems. It believed developers were likely gaining more than in its early-2025 study, while emphasising the weakness of the evidence about the size of that change. Anyone claiming a universal multiplier is doing rather more rounding than the research permits.

Still, it is worth considering the direction of travel. When a useful feature becomes easier to reproduce, competitive advantage has to draw more heavily on other parts of the service. Those can include knowing which problem deserves attention, reaching the people who have it, integrating with their working environment and accepting responsibility when the service fails.

Take a hypothetical scheduling product for a specialist maintenance business. A basic calendar is straightforward to describe. The difficult part is understanding qualifications, travel times, spare parts, customer access windows and the consequences of postponing a particular job. The value sits in making a day's work run properly. A customer may never see most of the decisions that make that possible.

Domain knowledge helps, although simply possessing a large pile of documents is unlikely to be enough. Knowledge must be current, usable and connected to the actual decision. A product that learns from real outcomes can improve its understanding of what works. That advantage depends on having the right to use the information and on doing something useful with it. Calling a database proprietary does not improve its contents.

Reliability becomes part of the product rather than an appendix to the sales presentation. NIST's Secure Software Development Framework sets out practices for incorporating security into software development. Generating more code does not remove the need to maintain dependencies, address vulnerabilities and manage releases. As output grows, the ability to examine and operate it may become more valuable.

There is a related finding in DORA's 2025 report, which describes AI as magnifying the strengths and weaknesses of the surrounding organisation. A team with clear priorities and good feedback can put faster development to use. A team already struggling to decide what customers need can simply accumulate more unfinished ideas.

Established suppliers should avoid getting too comfortable with this argument. Distribution, integrations and trust are advantages, but they can also become excuses for high prices and poor service. If rebuilding an adequate alternative becomes cheaper, customers gain another option. A small team with a focused product may be able to serve a neglected group more effectively than a large incumbent carrying years of compromise.

There is also more scope for customers to build modest tools themselves. Many internal applications never needed a venture-funded company around them. They needed a reliable way to complete a fairly specific task. Easier development could make that economically sensible for more organisations, while leaving room for suppliers that handle complexity customers would rather avoid.

The commercial test is whether the product continues to earn its place after the novelty of its construction has worn off. Does it save an identifiable cost? Does it reduce a recurring risk? Can the customer run an important activity with less uncertainty? These questions are less flattering than counting features, which is one reason they are useful.

Software may become more plentiful while dependable service remains difficult. The opportunity is to be specific about the work a customer wants done and build the whole arrangement needed to do it well. A faster way to write code is a considerable advantage. Deciding what deserves to be built, and remaining responsible for it afterwards, will still require attention.