When Echo Exceeds Voice

Generative AI will end the software business as we know it

In the two decades I've been involved in supply chain software I've seen several instances where changes to a base layer of a tech stack propagate to 2nd order impacts above them. For example, in the cloud computing wave the technical innovations to safely and easily share infrastructure led to novel business models to pay for just the minutes of compute, which led in turn to novel (but compute-heavy) algorithms being unlocked, which led to better optimization for the supply chains that are the majority of the physical economy. The echo of the technical change reverberated louder than the original voice that announced it.

But Generative AI does this at a scale and speed that is hard to overstate. I could say simply that Generative AI is thought and since thought permeates all software (and most back office work of any sort) its impact will be nearly a total revolution. But I think it's worth going into the specifics of how GenAI changes the business of software (this article), and from that groundwork I'll later write about how the logistics software space itself will change, and finally how such a change will permeate actual logistics operations. I'll push today's article forward through three opinions:

1. Software development faces three key challenges: accidental complexities of coding, coordination overhead with large teams, and the essential difficulty of forming good product opinions. Generative AI relaxes all three by: enabling natural language programming, reducing team sizes needed for large projects, and enhancing product opinion validation.

2. The cost structure of software development will shift from fixed human labor costs to variable & significantly lower costs. This changes the engine of profitability for SaaS companies and also the likelihood that enterprises just build their own software.

3. These forces together are shifting SaaS towards different business models than those prevailing today.

What makes software hard to develop?

In the seminal engineering article (later book) Mythical Man Month, Frederick P. Brooks Jr. outlined three hindrances to software development. Software is hard for essential reasons, for reasons that are accidental to the current ways & means, and because large teams are needed to implement large ideas. I believe Generative AI radically reduces each, as I'll explain in turn.

The accidental

Accidents are those difficulties in software writing that we face today but which need not exist forever. Chief among these accidental difficulties is precise coding. Humans are not accustomed to perfection, and machines are intolerant of errors. But notice that the degree to which software development demands inhuman perfection has changed over time, i.e. at any given moment the cumbersomeness of software writing is accidental rather than inherent. Punch card instruction entry, for example, was just the easiest way we had available for engineers of a certain period.This is why we call these sorts of difficulties the accidental. They need not have existed at all and could be eradicated at any time by sustaining innovations.

Generative AI is already eroding the biggest accidental aspect of software development: that it occurs in “code” at all rather than natural human languages. It should be clear that any software can be expressed as human natural language. The design for software almost always passes through a human natural language phase, and any software code could be restated into natural language. A natural language version would be much more verbose. But the conciseness of code is desirable largely because code is itself challenging to read, write, and maintain. With such a challenging medium, the less the better.

Since 2023, we've seen the emergence of software written “in english”. As someone near the frontline of this technology wave I think the cutting edge (as of March 2025) is not to escape code entirely and especially not for complex software. But there is a radical shift from code-then-review towards review-only, because generation of code is within sight for many use cases.

The coordination

In the software start-up scene one continually hears someone assert that they favor “talent density”, i.e. they prefer a small team of first-class engineers, rather than a much larger team of median-talent. So would we all. The best team is a team of one: constrained only by that person's intellect and stamina. And yet, how does a small team pursue software projects of considerable size? Facebook, Google, SAP, or any other large software company employs their thousands of engineers not because they are naive to the benefits of small teams with talent density but because the scale of their desired code is not achievable by them. And large programming projects suffer problems different in kind from small ones, due to the coordination of labor.

Coordination makes software development hard for two reasons. The first, a minor one, is that coordination taxes the available time of the team. Software developed with 100 engineers will already set aside perhaps a third of its time in some form of coordination (stand-ups, weekly's, sprint planning, retrospective, 1-1s, architectural reviews, and so forth). These coordination time taxes grow super-linear to headcount unless the leadership applies astute org design principles such as Team Topologies, async collaboration and so forth.

But the second, and much more serious, issue with coordinating larger teams is conceptual integrity. The most pernicious and subtle bugs are born from mismatched assumptions of what the software ought to be. Many software development failures concern exactly those aspects that were never quite specified, and hence rely on each engineer's concept of the product.

Software embodies interlocking concepts: data points and their relationships, priorities, permissions, identity, algorithms, and so forth. This remains always abstract, in that the conceptual construct is the same under many different implementations (i.e. a database write is conceptually identical even when done through different tech stacks). And that complexity of concepts cannot be compressed: the best way to explain code is the code itself. Anything else imposes trade-offs. One can explain code in natural language more verbosely but with less precision and more effort to keep track of the details. Even with such trade-offs we simply cannot compress software descriptions enough for them to be retold in normal human interactions (such as a 60 minute meeting), in the same way that we cannot convey a large novel in order to discuss it. Those who would discuss must first have internalised the material and then refer to it more or less obliquely, hoping their reference was clear.

From this irreducible complexity derives the challenge of coordination. Conceptual errors of one author are hard enough to eliminate, but large teams must maintain a shared conceptual understanding of immensely complex concepts. This creates ceilings beyond which team sizes simply cease to make sense, even when using the best org design and architectural practices to minimise need for coordination.

Generative AI attacks this problem in the most direct way: it reduces the headcount needed to achieve a given level of software. In examples in my team we find that it delivers something like 100x the velocity of a human. While people are still teamed-up to create software alongside such Generative AI that 100x velocity may be reduced. But the scale of software a team of seven can produce is surely an order of magnitude larger with GenAI than without. Generative AI also can be dedicated to the second order aspects of conceptual integrity, such as checking all work for issues, seeking and eliminating unstated assumptions or vague designs, tutoring new team members until their concept sufficiently reflects the intended concept, and so forth. This suggests to me that Generative AI both reduces the count of humans to coordinate (for a given size of software development) but also improves the likelihood of conceptual integrity between them.

The essential

I believe that great software takes a problem of the world, develops a theory of how to best tackle it, and then embodies that theory into a thing one can get buy and use with ease. For a software creator this model has an obvious challenge: the incompleteness & inconsistencies of our ideas. Nor are our opinions often very good.

Since the 2010s the field of product management emerged to address this risky business of forming an opinion. In the tradition of thinkers like Marty Cagan, product managers concern themselves with three major risks of their opinions as they harden into product: is this product concept desirable to its intended audience, is the cost & revenue structure economically viable, and does it comply with company policies and laws?

Generative AI can improve on nearly all product management techniques. It can be tuned to embody taste, even surprisingly good taste. It can listen attentively to customer interviews and run them at a limitless scale. And it can simulate A/B tests for many products or help plan them for others. Compared to the other aspects that make software hardware I suspect the essential difficulty of forming a good and coherent opinion to embody as software will remain the domain of the best creative humans. But they will be massively assisted by Generative AI, like a general with a support staff to handle preparation and follow-through.

What typifies SaaS business models?

Software is expensive to develop

Software may be difficult to develop, but that does not necessarily mean it would also be expensive to create. But in truth the causality works exactly like that: humans find it hard to make software and humans are most of the cost to make it. By the year 2000, labor costs accounted for at least 80% of total software creation costs, with the rest divided between hardware, infrastructure, real estate, and related machine costs. Cloud computing drove down the non-labor costs so that today labor typically exceeds 90% of software costs and very nearly 100% of costs during the initial R&D phase.

We should expect these cost drivers to change drastically as Generative AI comes into software development for two reasons:

1. Generative AI can displace much of the work done by humans in software development & serving. In effect, software development requires thought and machines, and until now only humans could deliver the thinking. Non-human thinking is becoming available.

2. Generative AI's costs are not just lower than humans but also differ structurally in important ways.

In terms of human work displacement, I believe we are already at the level where Generative AI (once correctly structured and harnessed) can replace the junior-to-mid level designers, developers, Cloud Ops, Dev Ops, product managers, and various other roles needed to create software. To be clear, I do not mean basic chatting or in-application assistance available already from all major software vendors (Gemini, Copilots, etc). These provide ~10% productivity gains in the task they relate to but make no improvement to the inter-task aspects of a worker's day nor do they radically change the mechanics of how a human works. They are a form of advanced auto-complete, itself useful but not revolutionary. Instead, I'm talking here about complex software that includes Generative AI and intends to displace humans from a role entirely, not just from a task within the role. In the world of cruise control I'm referring to full self driving. This level of displacement can exist already, it just isn’t available off the shelf. And I believe such AI workers are able to deliver above-median performance in the software development roles when compared to humans with less than two years experience. They likely outperform the 90th percentile of humans with less than a year's experience. I believe in time the AI workers will overtake nearly all median-performing humans in software creation, regardless of experience. Whether AI workers can outperform virtuoso-level humans in software creation (the top 2% for example) is unclear to me, but by definition most companies simply do not have such people to be displaced anyway.

Perhaps you disagree that humans can now or in the future be displaced entirely from software creating roles. In another article I'll explain why I am convinced, but for now just humor me. AI workers that displace human workers bring with them an awesomely different cost structure. Human workers are a fixed cost: they are hired on salaries, paid whether they work or not on a given day, and often difficult to scale up or down. AI workers are a variable cost: they offer a coin-operated black box of thought-work. If we want double the code written, we pay about twice as much, and so forth. The moment code writing stops, costs also stop. It also must be said that AI workers costs are substantially lower than human workers. Based on the work I am a part of, I believe this tends towards 1%, i.e. a software creation task that would require $100,000 in the past will cost $1,000 in the coming years. To be clear, I mean not just coding but the entirety of software creation labor: meeting with prospective customers, evaluating markets, designing user experiences, evaluating compliance expectations, and so forth.

Not only are AI workers less expensive and variable in their costs, they are also parallelizable. Even the leading technology companies such as Apple understand what a rare resource their top humans are. Steve Jobs once remarked to Marc Benioff that they do one real innovative product at a time and the A team (including Steve of course) focus on it. With AI workers there simply is no difference between one instantiation vs another. This combines with their lower costs to lead to a different style of software development. I would imagine software development to look much more like combinatorial optimization, meaning for any given mission we generate not one solution but dozens or hundreds of them in the understanding that some trial-and-error will help us uncover improvements. The degree to which this happens likely depends on the riskiness and portfolio of unconfirmed assumptions. But it again has implications for software creation cost structures because it provides a means to fluidly trade costs against risk of failure. Today, software development is expensive in part because successful developments must payback investments in failed software projects. Even conservative software development teams (such as a small team within a company doing minor adjustments to business systems) experience total write-offs of their work occasionally. This should happen less in the future because of the ability to generate variations in software that permute on key assumptions rather than gambling on the assumption being correct in the only version of software actually created.

Taken together this leads us to a new paradigm: myriad versions of software produced on the fly by ultra-cheap AI workers. It addresses the two key drivers for why software is expensive to build today: people and risk of failure.

SaaS is profitable

Even if software is expensive to build, it is a great business to be in: SaaS companies are highly profitable. But why should they be especially profitable? Unlike most business models, software achieves economies of scale very quickly. This was true with license & ship software, because each copy of the installable CD was nearly free to make. It was true of single-instance single-tenant software because now in addition to code the vendor could share some of the infrastructure & data center staff. And it really comes to the forefront in single-instance multi-tenant SaaS because everything about the software is shared: code, infrastructure, data, etc.

These “economies of share” create a compass for the SaaS leadership: get as many customers as possible on the smallest code base possible.

And yet, in B2B software there are always demands to adapt to the needs of large customers. SaaS vendors don’t want to screw up the magic and add custom code for these customers, and yet something must be done to meet their diverse needs. This is where configuration and professional services enter the picture. Configurations make the software more complex but keep that complexity above the level of code and in the realm of non-technical staff to invoke or adjust. Professional services either convince the customer to use less exotic configurations or design & test these exotic configurations to ensure they work. Configurations like this are the bane of SaaS companies: they slow down sales, they increase cost of sale, and they enlarge the code base.

SaaS with configurations makes good sense in a world where making code is more expensive than cost of sale. And until now that was always true. Engineers, product managers, and designers were a fixed cost resource. Software was arduous and expensive to build. But what if software creation becomes lower than cost of sale? What if a company was selling a CRM and the cost to make the CRM was $1k while the cost of sale was $10k? Wouldn’t we shift to a world where the vendor simply engineers-to-order the software rather than tries to fit requirements into configurations or convince the prospective customer to change their requirements? This trades the cost to create software for cost of sale, i.e. sell by saying “yes” to requests and just make the software as requested. This, in brief, is how I see generative AI cost reduction playing out in software markets. It's not that B2B SaaS vendors will make more or better products and then sell them like today. Instead they will return to a model like (though not the same as) the 1980s where all software was custom built while still leveraging shared data, network, and virtualized infrastructure. Something like Custom Software as a Service (CSaaS?) is the new business model to watch for.

Most enterprises buy vs. build, for now

In the USA, there is a trend for software to split into components served by specialist companies. For example, virtually no software development team would make its own authentication service (i.e. how a user logs in to the application). This has been abstracted out into a component that one buys off-the-shelf from a specialist service provider. Why so? I suspect labor cost is the driver. US engineers are among the most expensive labor one can buy, and as a result the software market has embraced division of labor and specialization as a way to bring economies of scale to counter such costs. Why spend $100k to build an authentication component when it is available as a service for $25 per month, for example.

Europe has less of this, and I believe it's no surprise that Europe has lower labor costs by about 1/3 to 1/2. In such a world it still makes sense to use instead of build, but the search and evaluation costs start to look more significant. The illiquid labor market also plays a role, i.e. staff who are hired cannot be let go easily so they will be kept busy.

China has a minimal component software development culture, and I believe this is directly because of low engineer costs. There may be contributions from a lower trust culture or rule of law in disputes.

Why I raise this is that one should expect that rapidly falling engineering costs lead to more inhouse development, rather than usage of specialised components. The search for a supplier, testing, and contracting will look heavy and slow in comparison to just building what one needs. Especially in light of costs falling to levels that simply mean little to the buyer.

What is the future of SaaS?

I've tried here to map from the seemingly narrow technical advancements in next-word prediction (i.e. what we call Large Language Models) to far reaching second order impacts on the SaaS business model. I outline them as follows:

1. Software is expensive because it is hard for humans to create.

2. Software is hard to create for three reasons: coding demands inhuman precision, there is a paucity of superior opinions about how to solve key problems, and big software requires coordinated actions & concepts among a large group of people. All three are being radically eased by the introduction of Generative AI.

3. Despite its cost, software creation was profitable for SaaS companies because they achieve high operating leverage. To avoid code bloating that would ruin the profitability, B2B SaaS companies added configurability and also fielded solution consultants to either (a) convince prospects the SaaS configurability meets their needs, or (b) convinced prospects to adapt to the software rather than the reverse. At the heart of this approach is the fact that R&D is much higher than cost of sale for a single account. If R&D costs fell well below cost of sale we would expect an approach where sales staff just asked what the prospect needed and that software was created bespoke for them.

4. SaaS companies will not be alone in being able to generate software at a thousandth of the current costs. As these costs fall, enterprises will increasingly see the sourcing & procurement, supplier management, and supply chain risk associated with SaaS as heavy relative to the cost of making their own software inhouse.

So, what does the future hold for SaaS as a business? A few safe harbours come to my mind for the next generation of SaaS leaders.

Process mastery

TSMC altered the chip industry by decoupling design from production, and achieved both economies of scale and process power in their domain. I suspect something like this will occur in software development, i.e. we will see a value-chain split between design and production in a way that has not been popular so far in software. In such an outcome there could emerge one or several significant software companies whose specialty is to make what you asked for rather than to sell what we dreamed up.

Brand

Just because great software can be created by a start-up in a garage doesn’t mean enterprises want them as critical suppliers. Brand, particularly where it indicates reliability, seems likely to grow in importance in a world flooded by new offerings.

Data

Even if you can generate any software you want, some solutions depend on knowing real data about the world. Not only would a SaaS vendor with such data be able to differentiate, the principle of Commoditize the Complement tells us it may be one of the only places where differentiated value can sustain.