In the age of AI, anyone can build an application for their specific need without ever looking at the code. So is traditional software dead? Far from it.
Software exists to solve problems, and much of the work is defining the problem precisely and then designing a solution that solves it well. Software companies have spent years doing exactly that, shaped by feedback from real users. Even if AI becomes good at writing requirements and maintaining code, why rebuild a solution that already works? Existing software carries years of experience with real problems.
So let’s start with the claim that “everyone can build a SaaS now,” and then look at what AI actually changes about software: not who builds it, but who operates it.
Building software takes more than code
Models keep getting better. Ask for something specific and they will build it, and build it well. The hard part is knowing what to ask for.
Take building your own ERP. You have to decide where it runs, how it handles exceptions, how it scales, how it stays secure, and what the UI should look like, which is hard to get right without real research. Then you have to maintain it, extend it, and adapt it as requirements change. Even with very good models, none of this is trivial. An app nobody designed, only generated, feels great in the first week; a year later it can easily be a liability.
For a small personal tool or a one-off task, building your own software makes sense. You know who will use it, and the requirements are narrow. The harder case is software that other people depend on every day and expect to keep working as their needs change.
Traditional software companies have answered these questions over years, and keep answering them, because they have the best validation mechanism there is: real users. Those answers become part of the product, including workflows and edge cases a new builder hasn’t encountered yet.
The main benefit of models as coders is speed. Being able to build anything matters less than shortening the loop between an idea, a working version, and feedback from real users. That speed helps existing software companies too: they can use it to test and improve what they already have.
A product still needs users
Building faster helps, but turning that software into a business raises a different question: who will use it? Software needs users, whether people or agents, to be viable. And that introduces a second bottleneck: distribution.
When everyone can build software, competition grows, the market noise becomes overwhelming, and even a well-designed, carefully thought-out product might not make it. Getting something built does not mean getting it adopted. Software remaining useful does not guarantee that today’s software companies or business models will remain successful.
This makes an existing user base a real advantage, but not a permanent moat. For traditional software companies, those customers represent trust, distribution, and years of feedback that competitors cannot copy overnight.
That advantage depends on adapting to a new kind of user: the agent. Products will need reliable APIs and agent-facing interfaces, including protocols such as the Model Context Protocol (MCP), permissions and approval flows designed for automation, and infrastructure able to handle many agents working at once. Companies that make their products easy and safe for agents to operate can strengthen their position. Companies that fail to adapt, however, leave an opening for competitors, regardless of how many customers they have today.
Agents as operators
The same thing that makes established software difficult to reproduce also makes it valuable to agents: it already contains years of knowledge about how work gets done. Its workflows, business rules, data structures, and handling of exceptions have been developed and refined through real-world use.
An agent doesn’t need to rebuild all that knowledge to benefit from it. Instead of building a new application from scratch, it can operate the software that already exists. The product provides the capabilities, while the agent understands what you want to achieve and coordinates those capabilities to get the work done.
Let’s return to the ERP example. Imagine asking an agent to replenish stock for next month. The agent could check expected demand, compare suppliers and prepare a purchase order. The ERP would provide stock records, purchasing rules and order history, and track the order once placed. The agent could use these capabilities without rebuilding the inventory system.
Coordinating that same purchase with accounting and delivery planning would extend this from operating one application to managing a workflow. The existing software becomes the foundation on which the agent can take on more of the work.
OpenClaw offers an example of what it looks like when agents can do more than answer questions. It runs on its own machine, communicates through the chat apps you already use, and remembers your projects across conversations. With the appropriate permissions, it can navigate websites, fill out forms, read and modify files, execute shell commands, and operate other tools. Skills and plugins extend its capabilities, and it can even create reusable skills from workflows it has learned. That is the shape of the thing: an agent that operates existing software, grows with the work you give it, and belongs to you.
But moving from a personal assistant to an enterprise operator is not simply a matter of giving an agent more access. Companies need clearly defined responsibilities, permissions limited to each agent’s role, human approval for consequential actions, audit trails, and reliable ways to handle exceptions, especially when many agents operate across the same systems.
OpenClaw Enterprise takes the concept a step further, bringing multi-tenancy, isolated agent workloads, scoped permissions, and governance to the OpenClaw model. These are the foundations for moving from personal assistants to agents that can take responsibility for processes across an organization.
A prediction for the future
My prediction is that, in the not-too-distant future, you will open an agentic app, connect it to your company’s software and data, and let it learn how the business operates. It will start with specific tasks, within the permissions and approval boundaries you set. As it proves reliable, you will delegate processes that span multiple systems. With enough context, it will begin identifying bottlenecks, suggesting improvements, and eventually proposing opportunities for expansion and longer-term strategies for growth.
OpenClaw helped popularize this model of agents that actively operate software. Its rapid rise brought the idea into the spotlight, and other projects are now following its lead, each taking the concept further in its own direction:
- Grok Bot is a team of always-on agents with their own cloud computer. Show a Bot a workflow once and it runs it as a routine; the team describes an ops Bot processing invoices from Gmail and an engineering Bot reproducing a bug, filing the ticket, and handing the fix to another Bot.
- Muse is Meta’s agent for billions of people, each running on its own secure VM with a separate Sentinel gating what reaches the internet. It takes a goal, builds a plan, and keeps working after you close the app.
- Hermes Agent, from Nous Research, is the other serious open-source contender: self-hosted, builds its own skills from problems it has solved, and runs scheduled reports and briefings unattended.
- OpenAI’s dots have their own cloud computer and plugins into over 4,000 apps. An early tester’s dot noticed an unbilled job, prepared the invoice, and sent it after approval. Specialist dots, now in preview, take on defined responsibilities like procurement and invoice processing inside a company.
These examples show individual tasks and workflows being handed to agents, not entire businesses being run autonomously. The next step is connecting these workflows into the way an entire company operates, with the responsibilities, permissions, and oversight discussed earlier.
As that responsibility grows, deciding what we want agents to achieve matters more, not less. People still define what improvement means: lower costs, faster delivery, better service, or something else. An agent can propose changes and carry them out within agreed limits, while people judge the results. The difficulty of defining the right problem remains, even when most of the execution can be delegated.
Software still matters in that future. It provides the records, rules, and tested capabilities the business depends on. What changes is how we use it: we describe what we want to achieve, and an agent coordinates the work across the tools we already have, building additional capabilities only where needed.
Top comments (0)