“Hey, check this out—look what I built!”
I hear some version of this sentence constantly. Building a website or web application has become so easy that nearly everyone I know in technology or the creative industries has something new to demonstrate.
This raises two related questions. If almost anyone can build software, what happens to the software-as-a-service industry? And if robots can perform more of the work humans currently do, what determines whether organizations will actually replace people with machines?
These are not separate questions. Both point to the same distinction: technical capability is not the same as practical adoption. When capability becomes abundant, value shifts toward trust, integration, judgment, and the ability to function within existing organizations.
Software: Building Is No Longer the Bottleneck
Consider the philosophical question people sometimes ask at gatherings: “If you had a genie who could give you anything, what would you ask for?”
Now pose that question to a company: If you could automate or improve any part of your organization, where would you begin? With the most resource-intensive processes? The most error-prone? The ones that create the greatest operational risk?

This is not a new question in industrial engineering. Traditionally, answering it required a time-consuming project: mapping processes, identifying inefficiencies, and designing ways to automate or optimize them. Many conventional businesses would not invest the necessary time or money.
I have seen this firsthand. My students once built a job-sequencing tool for a small shop that could have helped it schedule work more effectively, but the company did not adopt it.
More recently, my students built a functioning computerized maintenance management system (CMMS) to help our department manage laboratory equipment. When I asked the department chair whether she would be interested in implementing it, she replied, “Although the platform itself is impressive, I have some concerns regarding its long-term maintenance and practical usability within our department.”
Her response captured the problem precisely: building the tool was possible, but sustaining it and integrating it into the organization were harder.
Whatever the precise reason, the experience illustrated something important: a technically useful tool does not automatically create organizational value. Someone must trust it, learn it, integrate it into existing operations, and change established behavior around it.
AI changes the economics of building the tool, but it does not eliminate these other requirements.
People with deep knowledge of a particular industry can now create specialized software without all the resources once required to establish a software company. A domain expert who understands a problem intimately may be able to build a tool that fits the problem better than an existing generic product.
This creates opportunities for new entrants—but established SaaS companies have access to the same technology.
An incumbent can develop similar features while relying on advantages that a newcomer does not yet have: existing customers, recognizable branding, mature sales channels, integrations, technical support, security processes, and experience navigating procurement.
For many B2B products, therefore, the main bottleneck is no longer coding. It is adoption.
A new product must fit into existing workflows, work with legacy systems, survive security reviews, satisfy legal or regulatory requirements, and persuade several decision-makers that changing the current process is worth the risk. In safety-critical or highly regulated industries, technical capability is only one part of that decision.
Some organizations may also hesitate to adopt software produced through development processes they cannot audit. The issue is not that AI-generated code is inherently less secure than human-written code. Human-written software has never been free of defects. The real issue is whether the vendor can demonstrate careful review, testing, reliability, accountability, and long-term support.
Established SaaS companies often have an advantage here: not necessarily because their code is better, but because they have already built institutions around it.
This leads to a paradox. AI makes it easier to enter the software market, but it may also make it harder to stand out. When everyone can build, building itself becomes less valuable. Competition shifts toward identifying the right problem, reaching customers, earning their trust, and becoming embedded in their operations.
Robotics: Intelligence Is Not Enough
The robotics case appears more dramatic, but the underlying problem is similar.
AI tools are becoming capable of performing increasingly complex tasks in design, programming, engineering, mathematics, and scientific research. Connecting AI capabilities to reliable mechanical systems could produce remarkably capable assistants and workers.

But intelligence alone does not make a machine suitable for a workplace.
Organizations do not simply need intelligence. They need dependable performance within a particular role and environment. A physical robot must be safe, predictable, maintainable, legally accountable, and socially acceptable. Its value depends not only on what it can do in a controlled demonstration, but also on whether people can trust it in unpredictable situations.
In one sense, we already employ highly complex biological robots: human beings.
We know a great deal about human capabilities and limitations, and we have built extensive systems to manage both: education, training, supervision, healthcare, insurance, labor law, and workplace incentives. These systems are imperfect, but they are familiar. We understand many human failure modes, and our institutions have evolved around them.
Introducing unfamiliar machines creates a different set of technical, legal, and organizational risks. Who is responsible when a robot makes a harmful decision? How should it respond to a situation outside its training? How easily can people recognize that it has failed? Who repairs it, audits it, or overrides it?
A machine may outperform a human at a specific task while still being more difficult to employ within the larger system.
For this reason, robots are most promising where tasks are well-defined, repetitive, physically demanding, or dangerous. They can assist with manufacturing, cleaning, logistics, inspection, and carefully bounded medical procedures. Where work depends heavily on human interaction, contextual judgment, accountability, or trust, full replacement will be much harder.
This does not mean human workers are safe from disruption. It means that demonstrating a capability and deploying it responsibly are different achievements.
What Becomes Valuable?
When technical capability is scarce, the ability to build something provides a strong advantage. When that capability becomes widely available, the advantage moves elsewhere.
For software companies, value increasingly lies in domain knowledge, distribution, security, integration, customer relationships, and trust. For robotics, it lies in reliability, accountability, safety, and the ability to function within human institutions.
New companies can still win, particularly when they understand an overlooked problem better than incumbents or can move quickly within a specialized market. But “I built it” is no longer a sufficient strategy. The product must solve a problem that matters, and the organization must be willing and able to use it.

The same is true of intelligent machines. A robot may be able to perform the task, but that does not mean an organization is ready to give it the job.
AI is making capability abundant. It can help us create more software, designs, analyses, and machines in less time. But abundance does not eliminate the need for trust, judgment, integration, and responsibility. It makes those qualities more valuable.
AI can build the tool. It cannot, by itself, make an organization ready to use it.
Javad Seif
Pasadena, California
September 7, 2026
Comments
Loading comments…
Leave a comment