Software is Eating the Work
Since Orosius’s fifth-century History Against the Pagans, thinkers from Hegel to Marx have viewed history as an ineluctable progression of stages.
The history of enterprise software deployment is now entering a new stage, driven by the falling cost of building software. As this cost falls, the structure of the market changes.
Each of these stages are defined by the relationship between the business, the work, the software, and the software provider. In this next stage, software will eat the work - and organisations will differentiate by the way they respond to that change.
The first stage of enterprise software deployment was pre-Windows. Every enterprise that had software built it themselves; software was not yet something that could be packaged and sold. Most work still resisted software definition; the economy was not yet etched in silicon.
The second stage of software, in the 1990s, was about standardisation. Systems became good enough to serve complex and scaled workflows to many customers, but they were rigid and opinionated. Businesses wanted this software because it was better than anything they could build themselves - but they would have to change how they worked to fit around it.
The shift is laid out clearly in Softwar, the 2003 Larry Ellison biography:
There was something reckless in all of this. Ellison was challenging customers to share his vision and, in doing so, change the way they operated their businesses. He was daring them not to touch the software he wanted them to buy from Oracle:
"We don't think our customers should try to finish our software. It's too hard. We're the world's biggest employer of engineers from MIT and CalTech, and mathematicians from Harvard and Stanford, and even we have a hell of a hard time finishing our software. Customers shouldn't try do it for us."
He was challenging the enterprise computing industry's basic assumptions:
"IBM says that what you need to do when you buy that Siebel system is modify it so it fits your business. So you modify it, and you modify SAP and you modify i2 and you modify PeopleSoft. You modify and enhance all this incredibly complex software. When you finish, your company is the only company in the world that is running this unique software configuration. I don't care if this is the way everyone does it; we're going to try a completely different approach.”
Ellison’s calculus is explicitly about production costs: you need an army of CalTech engineers to build good software, and so each piece of software needs to serve as many customers as possible.
The relative inflexibility of these Stage 2 systems enabled the SaaS boom: it was possible to identify a niche ICP with homogeneous requirements, and build a rigid system matching those requirements. If you could identify niches and hire CalTech PhDs, you had immense pricing power.
But businesses that didn’t fit into the ICP of a vertical SaaS category faced a divergence between IT systems and business reality. They couldn’t build great software themselves; they hated their ERP, but couldn’t find anything better. Humans bridged the gap, inventing (often tacit) processes to deal with the inflexibility of their systems.
This divergence led to the third stage of enterprise software in the late 2010s: the return of custom software. Rather than changing business processes to match the software, why not design software so that it can match the business?
This return to the pre-Ellison era was enabled above all by the falling cost of software development. Twenty years on, the Caltech calculus was no longer true. Startups like Retool and Zapier enabled business users to build their own workflows; companies like Palantir enabled custom software at enterprise scale.
Palantir presents an interesting case study. Palantir’s original Gotham product was Stage 2 software: a versioned desktop app, each release named after an element and commemorated with a T-shirt. But in the late 2010s, the company developed Foundry, the archetypal Stage 3 product, which empowered forward-deployed engineers (FDEs) to build custom software for businesses with needs that were not well served by vertical SaaS or the main ERPs.
Palantir’s most important commercial customer is BP, which signed a 10-year deal in 2014. BP had a business problem which could not be solved by off-the-shelf software.
BP needed a unified view of their entire business, from production through to trading, so that traders could make decisions based on expected production, and producers could adjust targets based on expected prices. Software solves this problem - but there are only five integrated oil companies (ExxonMobil, Chevron, Shell, Total, and BP), and so the TAM doesn’t support a SaaS solution. Nor could BP reshape their business to fit the main ERPs on the market: custom software was needed. This need created Foundry.
What’s particularly interesting here is that BP was solving an established problem. As Christopher Leonard’s book Kochland chronicles, Koch Industries built internal software in the 1990s and early 2000s to pass data back and forth between pumps across America and their trading desks in Wichita, using data from one part of the business to inform the other.
Deep analysis was at the heart of Koch's trading strategy. [Cris] Franklin, for example, was hired into the trading unit after working in Koch's pipeline division [in the 1990s]. He had impressed his bosses there by developing a software program that could help Koch run its hypercomplex network of pipelines and natural gas processing plants. Franklin's program synthesized enormous amounts of data about pipeline flows and gauge pressures to simulate how the system could ship the most gas. When he started trading interest rate swaps, he used the same approach.
…
By collecting and analyzing reams of this data, Koch could reverse engineer a picture of oil shipments and flows that was granular in its specificity. Koch could learn exactly what its competitors were refining, how much they were refining, and on what day they refined it.
…
There were not yet electronic exchanges that showed a visible price of natural gas, and government data on sales were irregular and relatively slow to come… Koch's pipelines and origination teams were an information-generating machine. The United Gas Pipe Line system, which was renamed Koch Gateway, included 120 connections with other pipeline systems, each one a node that could yield information about natural gas prices.
Leonard’s suggestion that this was “insider” trading is straightforwardly false. The real takeaway from this story is that Koch’s engineers solved a problem in the 1990s and 2000s with Stage 1 software; in the 2010s, Palantir solved the same problem for BP, and productised their custom software. A tool originally built to model oil pipelines can be used (by me!) to model an org chart for a construction company.
P.W. Anderson’s marvellously concise 1973 paper More is Different can be summarised as follows: every few orders of magnitude, you need a new science. Chemistry is not just applied physics. In the same way, the falling cost of software development pushed enterprise software from Stage 2 to 3 - ironically, bringing it back closer to Stage 1.
Over the last twelve months, with the development of inference scaling and CLI coding tools, the cost to build software has fallen immensely. It will fall further still.
These tools both reduce production costs and improve software quality. It’s not just cost-out; these tools can perform tasks that previously could only be done by humans.
This means we’re entering a new fourth stage of enterprise software, in which building software is no longer the primary challenge. Instead, businesses have to deal with the consequences of software eating the work.
Stage 4 is about designing systems that will fully automate tasks currently done by humans, in a way that is truly new. Humans need to be taken out of the loop, made into orchestrators and inspectors. Work needs to be replatformed off humans, and onto AI systems. To adapt Marx’s line, engineers have hitherto only defined the work in various ways: the point now is to do it.
What does the business need in place to trust an AI system to handle cases end-to-end? How do we acclimatise our customers to interacting with our AI agents? Do we need to buy some sort of insurance product? How do we take the human out of the loop without sacrificing quality or losing unique human contributions? How does this change create space for humans to do the work they are most uniquely suited for? What new opportunities can we now take advantage of?
As the cost of building software approaches zero, custom builds become easier. Scoping workflows and managing organisational change becomes key.
In other words, it’s about rollout: difficult, painful rollout. Layoffs, reorganisations, process change. People at every turn saying “but we’ve always done it this way”, confronted by the fact that there is no longer an “it” to do.
Just as engineers no longer write code, but manage agents that do it for them, so too will businesses need to reckon with the fact that their analysts no longer have work to do, even though their managers still have work to oversee.
Software development is a good that can be substituted for “rollout”. If you build better software, it’s easier to get people to use it. Forward deployed engineering is explicitly about making this trade; we’re seeing more of it because, as software development cost has come down, it’s become a better trade. This was my job: find all the ways in which users hate their software, and change the software in response.
When you look at a chart of FDE job postings, you should see the Jevons Paradox in action: when demand is elastic and substitution is possible, a fall in unit cost can increase both quantity consumed and total expenditure - the cheaper input captures a larger share of the bundle. Software development came to make up a greater share of the cost of enterprise software deployment.
The Jevons Paradox requires elastic demand. But demand isn't infinitely elastic - at some point, you approach satiation. If each marginal unit of build is less valuable than the last, when you've solved most problems worth solving with custom software, demand becomes inelastic. And when demand is inelastic, further price drops reduce total expenditure on that input.
In Stage 4, when build costs fall even further, the share of software development cost in enterprise deployment cost will fall. Claude Code will eat the Jevons Paradox: more is different. But that doesn’t mean we’ll see less software development, because, this is only true on the individual project level. I think we’ll see:
Custom software development cost as a % of enterprise deployment cost down
Total cost of each enterprise deployment (at a given level of capability) down
Total number of enterprise software deployments up
Total spend on enterprise software deployment up
In Stage 4, companies will win based on the skill with which they manage this shift. Software is the easy bit - how do you use it to lever up the business? How do you take the reasoning that exists around Stage 2 and 3 software systems, and put it into the software?
Category winners in the real economy will not need software providers as much as they need rollout providers: companies that are world class at figuring out how to replace human work with AI labour. To take a Palantir analogy, the value shifts from the delta, who build the custom software, to the enterprise lead, who figures how to get it into the organisation in a way that maximises value.
American businesses need the tools to build Stage 4 software, but more importantly, they also need the expertise to roll it out. For the right business, the upside opportunity from transformation created by Stage 4 software transcends anything Koch and BP could have hoped for.
With thanks to Jack Soslow, Sara Figel, Owen Brooks, Aditya Rajan, Andrew Ziperski, Alex Mackenzie, Sid Jha, Coen Armstrong, and Rohan Tandon for feedback on this piece.