AI Coding Agents and the Future of Software: When Customers Become Builders

Software companies have always competed with other software companies. They may soon compete with their own customers.

Consider a small engineering team that needs a tool for a specific calculation, report, or internal workflow. Its members understand the problem. They know the inputs, the business rules, and what a correct result should look like. What they lack is the time or programming capacity to build and maintain the software.

AI coding agents could change that calculation.

With Zimeng Yu and Dr. Tong Qiu at the University of Utah, I examine this possibility in our new preprint, The Customer Is the Builder: How AI Coding Agents Are Rewriting the Economics of Software.

The question is simple: what happens to software markets when more customers can build the functionality they need?

A company buying software may use only a small part of it. A team might need to organize documents, generate a standard report, or move information between two systems. A scientist might need a calculation tool that follows a known physical model.

Replacing the entire commercial application would be a major undertaking. Reproducing the required workflow can be a smaller problem.

This is why we focus on organizations and professional buyers with domain knowledge. They may already know what the software should do and how to judge its outputs. Agents could reduce the programming effort needed to turn that knowledge into a useful tool.

We call the relevant boundary the software substitution frontier: the functions customers could build and maintain at an acceptable standard for less than buying them.

The word “maintain” matters. A working demonstration does not settle the economic comparison.

Our analysis combines public evidence on agent capability, software creation, alternatives to commercial products, and purchasing indicators. These sources measure different parts of the proposed change.

In our analysis of METR's benchmark series, the human task duration that frontier agents could handle at 50 percent success doubled about every 129 days from 2023. This measures performance on a particular task suite. It does not mean an agent can reliably replace a developer or maintain a commercial product.

A broad search also identified 575 potential open-source alternatives to selected commercial products. Some functional matches still require independent validation. The count measures candidate alternatives, not successful replacements or canceled subscriptions.

The Craft suite provides an illustration of rapid creation: 12 application repositories over 12 days of public development. Those projects remained early versions, with completeness and reliability unverified.

Together, these observations suggest that the capacity to create software is expanding. They do not establish how much paid software spending it has displaced. The methods, source records, and limitations are documented in the paper.

The available purchasing indicators do not show a broad move away from buying software. Purchased software gained share in US software investment, and tracked commercial installations grew.

There are also reports of individual purchasing decisions changing. In an organizational survey examined in the paper, 32 percent of respondents reported forgoing at least one software purchase because their organization could build the functionality with coding agents.

That is a reported decision. It is not an audited measure of spending displaced, and it does not establish whether the resulting tools remained dependable.

The distinction is central to our argument. More building can coexist with growing software purchases. Organizations might create tools for previously unmet needs, keep commercial systems for other workflows, or pay for new services around their internal builds.

A team evaluating an internal tool must consider more than its initial implementation.

Someone must verify the outputs, protect the data, connect the tool to existing systems, and respond when requirements change. Hosting, migration, failures, and maintenance belong in the comparison too.

These responsibilities explain why commercial software can remain valuable even as code becomes easier to produce. Customers may be paying for dependable service, shared infrastructure, support, and accountability.

Agents could eventually perform more of this work. Our evidence does not establish when they will do it reliably. The capability dates in the paper are an extrapolation, not a forecast of customer switching.

The practical question is which customer workflows become economical to build internally.

A narrow, well-understood task may face a credible build option before a system that coordinates many people, sensitive data, and complex integrations. Vendors can examine what customers use, what they can independently verify, and which continuing services they value.

The paper also discusses attempts to slow imitation by restricting documentation or adding friction to automated inspection. We found no evidence that these measures prevent substitution. They may also make products harder for legitimate customers to learn and integrate.

A more useful question is where a vendor can continue to create value as implementation becomes easier.

Our argument does not require every customer to become a programmer or every subscription to disappear.

A credible internal build option could change a renewal negotiation before it produces a measurable shift in aggregate spending. The customer may still buy, but the reasons for buying, and the price it will accept, could change.

The next research step is to follow specific workflows from building through verification, sustained use, maintenance, and the decision to buy or renew.

If customers can build more of what they need, what will they keep paying software companies to provide?

This article summarizes a preprint, which has not undergone journal peer review.

Ripon Chandra Malo, Zimeng Yu, and Tong Qiu. The Customer Is the Builder: How AI Coding Agents Are Rewriting the Economics of Software. University of Utah, 2026.