Chris Loy.

The rise of industrial software

Part of AI coding and software
Previously:  System design assistants

Industrial

adj. (sense 3a)

Of or relating to productive work, trade, or manufacture, esp. mechanical industry or large-scale manufacturing; ( also) resulting from such industry.

Oxford English Dictionary

For most of its history, software has been closer to craft than manufacture: costly, slow, and dominated by the need for skills and experience. AI coding is changing that, by making available paths of production which are cheaper, faster, and increasingly disconnected from the expertise of humans.

I have written previously about how AI coding can be a trap for today’s practitioners, offering shortcuts to incomplete solutions at the expense of the understanding needed for sustainable development practices. But as we collectively address the shortcomings of our current toolset, it is clear that we are heading into a world in which the production of software is becoming increasingly automated.

What happens to software when its production undergoes an industrial revolution?

Software as a disposable commodity

Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively.

Industrialisation of production, in any field, seeks to address both of these limitations at once, by using automation of processes to reduce the reliance on human labour, both lowering costs and also allowing greater scale and elasticity of production. Such changes relegate the human role to oversight, quality control, and optimisation of the industrial process.

The first order effect of this change is a disruption in the supply chain of high quality, working products. Labour is disintermediated, barriers to entry are lowered, competition rises, and rate of change accelerates. All of these effects are starting to be in evidence today, with the traditional software industry grappling with the ramifications.

A second order effect of such industrialisation is to enable additional ways to produce low quality, low cost products at high scale. Examples from other fields include:

  • industrialisation of printing processes led to paperback genre fiction
  • industrialisation of agriculture led to ultraprocessed junk food
  • industrialisation of digital image sensors led to user-generated video

In the case of software, the industrialisation of production is giving rise to a new class of software artefact, which we might term disposable software: software created with no durable expectation of ownership, maintenance, or long-term understanding.

Where traditional software is high cost and high value, disposable software is low cost and low value.

Advocates might refer to this as vibe-coded software, and sceptics will invariably talk about AI slop. Regardless of its merits, it is clear that the economics of this class of software are quite different, as each software output has less economic value, due to its easy reproducibility. This lack of perceived value might tempt you to dismiss the trend as a passing fad, but this would be unwise. To understand why, we need to consider the historical precedents for commoditisation of previously scarce goods.

Jevons paradox and the addictive nature of slop

Jevons paradox is an old bit of economic theory that has been much quoted recently. The observation dates to the nineteenth century, noting that improved efficiency in coal consumption would lead to lower costs, fueling higher demand, and ultimately resulting in higher overall coal consumption.

Jevons paradox describes how increased efficiency can result in higher overall consumption.

This is relevant today, because we are seeing the same surge in demand for AI compute: as models become more efficient at token prediction, demand is surging and results in ever greater consumption. Will the same effect ripple through software development itself, with lower cost of effort driving higher consumption and output? History suggests it will.

Consider the industrialisation of agriculture. In the early twentieth century, scientific advances were expected to eradicate hunger and usher in an era of abundant, nourishing food. Instead, hunger and famine persist. In 2025, there are 318 million people experiencing acute hunger, even in countries with an agricultural surplus. Meanwhile, in the wealthiest nations, industrial food systems have produced abundance of a different kind: the United States has an adult obesity rate of 40% and a growing diabetes crisis. Ultraprocessed foods are widely recognised as harmful, yet the overwhelming majority of Americans consume them each day.

Industrial systems reliably create economic pressure toward excess, low quality goods. This is not because producers are careless, but because once production is cheap enough, junk is what maximises volume, margin, and reach. The result is not abundance of the best things, but overproduction of the most consumable ones. And consume them we do.

The economic pressure of industrialisation will drive adoption of disposable software.

Our appetite for AI slop is likely to be similarly insatiable. The adoption curve we’ve seen so far may pale beside what happens when disposable software production becomes truly mainstream. If the democratisation of software mirrors the impact of ubiquitous photo, video, and audio capture enabled by the smartphone, we may see user-generated software created, shared, and discarded at social-media scale. Should that happen, the feedback loops of novelty and reward will drive an explosion of software output that makes the past half-century of development look quaint by comparison.

Will traditional software survive?

Ultraprocessed foods are, of course, not the only game in town. There is a thriving and growing demand for healthy, sustainable production of foodstuffs, largely in response to the harmful effects of industrialisation. Is it possible that software might also resist mechanisation through the growth of an “organic software” movement? If we look at other sectors, we see that even those with the highest levels of industrialisation also still benefit from small-scale, human-led production as part of the spectrum of output.

For example, prior to industrialisation, clothing was largely produced by specialised artisans, often coordinated through guilds and manual labour, with resources gathered locally, and the expertise for creating durable fabrics accumulated over years, and frequently passed down in family lines. Industrialisation changed that completely, with raw materials being shipped intercontinentally, fabrics mass produced in factories, clothes assembled by machinery, all leading to today’s world of fast, disposable, exploitative fashion. And yet handcrafted clothes still exist: from tailored suits to knitted scarves, a place still exists for small-scale, slow production of textile goods, for reasons ranging from customisation of fit, signalling of wealth, durability of product, up to enjoyment of the craft as a pastime.

Might human written software become little more than a boutique industry?

So, might human-written software be confined to niches mirroring high fashion or homemade knitwear? That might have been the case were software a physical product, in which industrialisation could lead to mass production of reusable components. But software is an intangible good, and unlike other industrialised fields, it has a long history of component reuse that is intrinsic to the nature of the good itself. Innovation is not limited to better or cheaper versions of existing products, as with clothing, but also encompasses growth of the solution space, more akin to how the steam engine enabled reusable machine parts, enabled the production line, enabled the motor car, etc.

As such, the mechanism for technological progress in the history of software development has been not only industrialisation, but also innovation. Research and development is expensive, but offers the only path to greater value over time.

Innovation is the historical and future driver of increased value from software.

Innovation is fundamentally different to industrialisation, because it is not focused on more efficiently replicating what already exists today. It instead advances through finding and solving new problems, building on what came before, and delivering capabilities that could not previously have existed. Industrialisation then steps in and provides scale and commoditisation, providing a foundation upon which the next round of innovation can build. The interplay of these two forces is what we term progress.

The endless cycle of progress

Large language models are a steam engine moment for software. They collapse the cost of a class of work previously fully dependent on scarce human labour, and in doing so unlock an extraordinary acceleration in output.

But remember that the steam engine did not appear in a vacuum. Windmills and watermills preceded turbines by centuries. Mechanisation did not begin with coal and steel; it merely reached an inflection point at which automation, scale, and capital aligned to power economic transformation. Similarly, software has been industrialising for a long time: through reusable components (open source code), portability (containerisation, the cloud), democratisation (low-code / no-code tools), interoperability (API standards, package managers) and many other ways.

We are entering an industrial revolution for software, then, not as a moment of rupture, but one of huge acceleration. Industrialisation does not replace technological progress, but it will greatly accelerate both the absorption of new ideas and the commoditisation of new capabilities. In turn, innovation is more quickly unlocked, as the cost of building on top of novel technology drops more quickly. The cycle of progress continues, but in an era of mass automation, the wheel spins faster than ever before.

The cycle of progress is driven by innovation and industrialisation happening in tandem.

The open question, then, is not whether industrial software will dominate, but what that dominance does to the surrounding ecosystem. Previous industrial revolutions externalised their costs onto environments that seemed infinite until they weren't. Software ecosystems are no different: dependency chains, maintenance burdens, security surfaces that compound as output scales. Technical debt is the pollution of the digital world, invisible until it chokes the systems that depend on it. In an era of mass automation, we may find that the hardest problem is not production, but stewardship. Who maintains the software that no one owns?