Brotzeit · Thoughts12 October 202614 min readVolker Schukai

Who owns the value of software

Who benefits when making software keeps getting cheaper.

A few hours. That is how long an agent in this thought experiment needs to build an application that used to take several weeks of development work. It works, it is tested and it runs reliably. The customer sees the result and asks a reasonable question: why should I still pay a lot of money for this? The software vendor points to the benefit. But the customer already has the next question: if my agent can deliver the same result, what do I still need you for?

That second question holds the economic upheaval. Software can keep creating enormous value while the companies that make it keep a smaller share of it. So the real question is: when making software costs less and less, who can still claim which share of the value it creates?

Even before generative AI, software was an unusual economic good. The first working version could be expensive, every further copy almost free. High prices were possible all the same. Customers paid for a solution that existed; competitors first had to carry the cost of building their own. AI may now make building a functionally comparable alternative drastically cheaper as well. That weakens an existing code base as protection against competition. The developer years invested remain historical costs. They oblige nobody to pay a matching price in the future.

How far this change has already gone is shown not by an impressive demo but only by measurement in everyday work. Three randomised field experiments with 4,867 developers in total found that an AI coding assistant led to about 26 percent more completed tasks. That is a considerable productivity gain. It means neither that complete products become cheaper by the same amount, nor that today's agents are limited to this effect. The study measures particular tools and working conditions, not a fixed limit of automation.¹

The paper "Writing Code vs. Shipping Code" shows why this distinction matters. The authors find strong gains in code changes but clearly smaller gains in shipped releases. On four software marketplaces they also observe more new applications without a matching rise in measured overall usage. The results come from an observational study: for the GitHub data the authors compare against matched comparison groups; the marketplace data are descriptive. They point to a current bottleneck: a larger amount of generated code only partly turns into additional software that is shipped and used.²

So the assumption of a few hours remains a thought experiment. For the economic question it is still useful. It forces us to think about a future in which today's difficulties shrink. Anyone who bases their whole business strategy on agents failing at testing, integration or maintenance for good is betting on a technical limit nobody has shown to last.

Costs are moving fast too. According to the OECD, its quality-adjusted price index for language models fell by almost 80 percent between January 2024 and April 2026. At the same time it points out that agents can generate considerable compute through heavy model use. The cost of reliably completed work therefore does not necessarily fall in the same proportion as model prices.³ Cheaper is a direction; free is a far stronger claim.

Even completely free production would not remove the benefit of an application. Suppose a piece of software saves a business 50,000 euros a year. That saving exists regardless of how long someone worked on the code. But if equivalent applications are offered for a few hundred euros, a vendor can hardly charge 20,000 euros for long. The benefit to the customer stays high while the achievable price falls. At first, the difference goes to the customer.

That is why the familiar line about selling results rather than programming hours is not enough of an answer. It describes what a customer is willing to pay for in principle. How much of that a particular vendor receives also depends on the alternatives. Even a problem solved brilliantly can be a bad business for the vendor if many competitors deliver the same reliably. Creating value and being able to profit from it are different things.

For users, such a development would often be welcome. Small businesses could get applications that never paid off before. Rare requirements would no longer necessarily fail because the market is too small. A business could have a process adapted instead of permanently building its organisation around the limits of a standard product. More economic benefit could arise even though software vendors earn less revenue per application. The state of the software industry would then be an incomplete measure of the social success of software.

For vendors, this means tougher competition. With agents, a small team may be able to serve a market that used to need a larger organisation. But the same opportunity is open to other small teams. The low barrier to entry helps the founder today and their next competitor tomorrow. Anyone who merely offers the same features faster has an advantage that may be short-lived.

Lasting revenue then depends more on what stays scarce beyond the easily reproduced feature. That can be a hard-to-reach customer base, a network built over time or the ability to introduce software into a particular business. Reliability has a price too: a customer needs to know who is reachable when something breaks, who organises a recovery and who understands the consequences of a change. AI can make this work cheaper. As long as getting it reliably takes effort, there is a market for it.

Still, expertise, data and trust should not be declared impregnable walls either. Domain analysis can be partly automated. Data loses some of its binding effect when it can easily be moved. Trust in a vendor can fall when a competitor demonstrably delivers better results. A sustainable position must therefore stand up to the customer's real alternatives. The claim that complex software simply needs people does not yet explain a price that can be achieved for long.

Vendors are already trying to tie their billing to completed work. Intercom charges 0.99 US dollars for certain outcomes of its agent Fin, such as a support request resolved according to its own rules. The definition matters: a conversation the customer leaves after an answer without asking for further help can also count as resolved.⁴ An outcome price ties payment more closely to usage. It removes neither the question of whether the customer values the result the same way, nor the competition for the lowest price.

With such models, software increasingly competes for budgets that used to pay for human work. That can open up new revenue. Whoever reliably completes a task sells a different service than someone who merely provides a tool for it. At the same time, customers can compare their savings across several vendors. Whether the productivity gain ends up with the vendor or with the client remains a question of bargaining power.

Another possibility is that a larger share of revenue flows to the providers of the technical foundations. Many applications could depend on a few model, cloud or distribution platforms. Then numerous new products emerge while important sources of revenue concentrate with the operators of that infrastructure. This is a possible scenario, not a technical inevitability. Interchangeable models, open interfaces and easy data export would strengthen the bargaining position of users and smaller vendors. High switching costs work in the other direction.

Employment does not follow a simple formula of progress. If, in a simplified model, the human effort per comparable application halves, demand would have to double to keep the volume of work the same. New demand is likely, because lower costs can make additional applications economical. Whether it will be large enough remains open. More software, higher profits and fewer required working hours can all happen at once.

This tension is especially visible in India. The label "low-wage country" hides the differences between simple outsourced tasks, highly specialised development and internationally active technology groups. Even so, the advantage of lower personnel costs is central to part of the outsourcing business. If the same task can be done with far fewer human hours, the absolute saving from the cheaper location shrinks. Coordination effort and closeness to the customer can then weigh more heavily.

That does not mean work automatically moves back to Europe or North America. Indian developers can use agents too. Comparing a German team with AI to an Indian team without AI would leave out the most important adjustment. Vendors in India have existing customer relationships and operational experience. How much of that they can turn into new services matters more for their future than where the next block of code is written.

The available industry data so far show growth. In February 2026, Nasscom estimated revenue of the broad Indian technology industry for fiscal year FY26 at 315 billion US dollars, 6.1 percent more than the year before. Employment was expected to grow by 2.3 percent. The figures come from the industry association and cover, besides IT services, business process services, engineering and research services, software products and hardware. They show neither a collapse of the industry nor that the transition is going smoothly for every employee.⁵

AI itself can also become business for Indian service providers. In October 2026, TCS reported annualised AI revenue of 3.1 billion US dollars, which according to the company was more than ten percent of total revenue.⁶ The figure describes the AI activities as the company defines them. It does not say how much of it is additional business or which existing services it replaces. But it shows that established providers can earn money from the shift.

For India as a society, little is decided by this. An IT industry can grow revenue and profits and at the same time need fewer new people. A company sees that as productivity progress. For a graduate whose first job never materialises, the same process looks different. A country's economic future therefore cannot be read from the quarterly figures of its largest employers alone.

In 2025 the World Bank reported for South Asia that, since the release of ChatGPT, job postings in occupations that are particularly exposed to AI and easy to replace had fallen by around 20 percent relative to other occupations. That is a statement about job ads in one region, not a measurement of jobs destroyed in India alone.⁷ It draws attention to a change that can be less visible than a large wave of layoffs: companies simply do not hire certain people in the first place.

A study by the Stanford Digital Economy Lab, updated in August 2026, fits this picture. In the US payroll data analysed, employment of 22- to 25-year-olds in AI-exposed occupations was 19 percent below the path of less exposed peers of the same age. The gap arose mainly from fewer hires. The authors explicitly describe this as a descriptive finding, not causal proof of an AI effect; with additional controls the differences become partly smaller.⁸

If simple development, testing and support tasks are the ones that disappear, that also affects how experience is built. Those were the tasks on which newcomers learned before taking on more responsibility. Companies then have to find other ways to train the next generation. The call for further training remains sensible, but it does not answer how many jobs will exist for the newly acquired skills. A successful transition for companies can coincide with a difficult transition for a whole generation.

At the same time, AI opens up new opportunities for countries like India. In October 2026 the World Bank described additional opportunities for South Asian suppliers through their links to global value chains and through the use of AI. It stresses the importance of skills, infrastructure and better conditions for adoption in companies.⁹ Whether such opportunities reach many people depends on how broadly these conditions are created and who gets access to the new work.

The question of the value of software thus becomes a question of distribution. Customers can gain through lower prices. Employees can become more productive and earn more, provided their skills stay in demand and they share in the gains. Companies can open up additional markets. Platform operators can take a share of each of these activities. None of these developments follows merely from a model producing better code.

For software companies it therefore becomes harder to justify their value by the size of their code base or the number of developers they employ. What they deliver has to stay convincing for the customer even when the next technical alternative is cheaply available. For economic policy, the corresponding question is whether competition, training and access to infrastructure are shaped so that the productivity gains arrive broadly. Technology does not decide this distribution.

The few hours from the beginning can therefore be worth a great deal. They can save a business thousands of working hours, open a new market to a small vendor or make a previously unaffordable application possible. How much of that ends up with the vendor is decided by the customer's alternatives and the dependencies on the way to the finished result. A society can grow richer through software while parts of its software industry earn less. The demanding question is under which conditions this additional prosperity also reaches those whose former work the agents take over.

Auf Deutsch lesenMore from ThoughtsAll entries