Generated Software: How Software is Eating Itself
In the latest installment of Warehouse Software's offsite, discover how software is being used to automate tasks in the software development process itself.
If you're just joining us, this series follows the journey of a brilliant product manager, you. You've steered the product strategy of a company, Warehouse Software Inc, through 3 decades of technology disruptions. But in 2026, the company faces its biggest test yet - the ascendance of AI. The CEO has called an offsite, and the team is grappling with the implication of AI and how the flagship product, Warehouse Tracker, should respond to the change.
Here are links to the rest of the series:
Moments That Modernized: Four Decades of Tech's Tectonic Shifts
The Economics of Abundance: What Do You Charge When Software is Free to Produce?
Reinvent or Relinquish: You Can't Sell Horseshoes to People Who Don't Own Horses
The CTO steps forward and loads a presentation onto the screen. Being an introvert, he prefers to gather his thoughts before speaking and finds that preparing a written presentation helps him stay focused.
"Before we delve into how AI can reshape software, we must first understand software itself," he begins.
Software turns atoms into bits
Customers buy warehouse management software because it boosts the efficiency and productivity of their warehouses. Our customer's job to be done is to receive and ship products, and our software reduces their costs to do this well.
So how does software accomplish this task? It has a neat little trick. It digitizes a physical task. Turning atoms into bits. This digital twin has valuable properties its physical counterpart lacks. It’s easy to scale, monitor, and tweak.
Take buying a book, which Amazon digitized in the 1990s. By transforming this process into software and bits, Amazon gained an edge over brick-and-mortar competitors. One website could serve the whole world, while Borders struggled to support a network of stores.
Software eats the world
In 2011, Marc Andreessen penned an op-ed declaring, “software is eating the world.” He argued software can do more than digitize processes; it can digitize entire products. Consider books. Amazon first transformed buying books, then launched Kindle, turning books themselves into bits and bytes. Once digitized, a book could beam anywhere instantly, cutting out bookstores, shelves, and bookmarks.
You might assume warehouse software is immune, moving real-world goods as we do. But some companies now sell digital art for electronic frames that update displays without swapping them physically. Facebook is betting we’ll trade the real world for a virtual “metaverse” where everything comes from bits, not atoms.
Automation turns variable costs into fixed costs
Automation possesses another superpower: transforming variable costs into (nearly) fixed costs (we'll ignore usage-based pricing, etc, for simplicity). Once an ebook is created or a website built, each additional sale or customer costs little. This fuels the scale and profit potential of digital companies. Companies can spread the initial investments — building a streaming service, or developing an app — across a vast customer base.
The world of atoms knows no such luxury. Each widget produced demands materials, manufacturing time, and money. Variable and marginal costs persist no matter the volume. Software liberates bits and bytes from these economic shackles, provided enough users can be found.
But software has a problem: diseconomy of scale.
While it has become easier to build, software still demands significant investment in product, design, management, and delivery. Furthermore, as software systems scale, diseconomies of scale emerge. Larger systems are harder to enhance and maintain; studies show maintenance costs scale disproportionately as the lines of code increase.
The software itself grows unwieldy to use. To counter this, we restrict new features, building only functionality benefitting the largest user segments. This inflexibility becomes software’s undoing.
Peering under the hood, most software shares basic functionality. A core data model enables operations according to business rules. We encode these rules and attributes in models, views, and controllers (others frameworks exist, but MVC is a common one).
Take our Warehouse Inventory Tracker. Its data model tracks packages and their arrival. Rules dictate that packages leaving the warehouse no longer occupy a location in the warehouse (duh!). On top of these models, we construct workflows using views and controllers. It all comes together in a feature like our inventory search module that lets users seek packages by ID or location.
It turns out most of the code in our software resides in the views and controllers. Ultimately, the data models and business rules are not remarkably different between our product and our competitors'. The distinction lies in how we package features. As we’ve moved upmarket, our product has developed more sophisticated and granular workflows, making the product harder for smaller warehouses to use. New companies have tried to capitalize on this by introducing solutions tailored to the lower end of the market.
The larger customers pay us to modify our packaging to suit their particular needs. Ideally, every customer would receive software tailored to their precise use case, but alas, that level of customization is too expensive currently. It is in this context that no-code and low-code platforms have found traction. Why pay for a rigid warehouse system that doesn’t fit when you can build your own using a no-code tool like Glide and Google Sheets? However, these tools can only take companies so far, often leaving the customer once again needing IT services to custom-create a solution or buy one from a vendor.
Ouroboros: software eats itself
The ancient ouroboros symbol of a serpent eating its own tail represents the cyclical nature of the world. We have reached a point where software is now similarly consuming itself. The power of automation is being applied to the software industry itself.
Generative AI can create fully functional software, not just lines of code. Software companies will provide models and services, and AI will assemble a specific workflow that precisely meets the feature requests of each client, like a bespoke suit.
Consider the early days of the commercial Internet. AOL built a walled garden, curating content and experiences for its customers. But when the open Internet took off, AOL could not compete. People wanted access to the full Web, not AOL’s packaged version of it. Similarly, in a world where AI can build software experiences, customers will no longer care about packaging and workflows. They will want the core services and data models so they can construct their own experiences.
We already see hints of this in the ChatGPT plugin system. Users create their own shopping experiences by asking for a recipe and directing ChatGPT to add the ingredients to an Instacart cart. Instacart’s own UI and workflows become irrelevant; ChatGPT dynamically taps Instacart's underlying APIs to deliver the exact experience users want.
How to stay out of reach of software's appetite
We can embrace this impending change by honing our skills at building foundational models and services. We have already been developing our application using microservices, but it is time to evaluate our APIs from the perspective of an AI workflow creator. Are we exposing the right services and building blocks so new and unique workflows can be strung together?
We should lead the way in rethinking how our application's user experience is structured. We must challenge ourselves to transition from a model where users navigate to features, to one where the features come to the user as needed.
This only scratches the surface of what we must do on the technical front. We will continue working on this approach after the offsite.
After the presentation, the CTO steps away from the front and takes his seat.
The CEO steps up and adjourns the meeting. "We'll meet back for the final session after lunch," he says.